4月底時，知識星球里有個關于在 RAG 流程中，如何實現基于 Bad Cases（負面案例）的合同審查和合同生成（基于合同模板）的提問，算是一個很有代表性的進階 RAG 應用方向，這篇針對其中的合同審查場景來做些介紹和演示。

注：“整體文檔理解”（Bad Cases 分析）和“結構化對象檢索”（模板匹配）

合同審查場景里，利用歷史上的“壞案例”（Bad Cases，包含合同原文和審查結果）來輔助新合同的審查，而不僅僅依賴預設規則是個很實際的業務需求。但標準 RAG 主要召回與問題語義相似的片段，確實很難讓 LLM 理解一個 Bad Cases 的整體情況和參考價值。直接將整個 Bad Cases 作為知識源，又面臨上下文窗口限制和召回不精確（可能只匹配了表面相似性，而非關鍵問題點）的挑戰。 

結合我過去幾個月一些相關項目中的實踐經驗，這篇基于 Dify 工作流和設計的樣例數據，向各位展示一個可快速上手的解決方案示例。

以下，enjoy:

1、現代合同審查工具及其局限性

正式開始介紹前，我們先來回顧下，在沒有 LLM 和 RAG 技術普及之前，市場上常見合同審查工具以及其背后的規則引擎做法。

來源：https://www.yun88.com/product/4413.html

1.1核心做法

知識庫構建與規則編碼：

傳統規則引擎主要來自法律專業知識、行業慣例和公司自身的風險策略等方面，并且需要人工持續維護和更新。具體來說，通常來說包括：完整性檢查、風險模式識別、一致性與準確性、合規性檢查、量化指標監控等維度。

來源：自制

其次，需要將這些知識轉化為一系列明確的、可執行的規則。例如：“合同必須包含‘爭議解決’條款。” 、“‘責任限制’條款的上限不得低于合同總金額的 X%?！?、“若合同類型為‘保密協議’，則保密期限不得少于 N 年?！?等。最后將這些規則用特定的語法（如正則表達式、關鍵詞匹配、邏輯判斷式）編碼到規則引擎中。 

自動化掃描與標記：

有了上述規則庫之后，在實際使用時需要通過工具讀取合同文本（通常使用 OCR 處理掃描件），規則引擎逐條或并行匹配合同內容與規則庫中的規則，標記出違反規則、缺失條款、與標準范本不一致或存在預警關鍵詞的地方。輸出一般則是高亮顯示問題條款、生成風險提示列表、給出初步的風險等級評分等。

來源：https://idp.jxdinfo.com/

1.2局限性

語義理解的缺失：

規則引擎的主要實現邏輯是基于關鍵詞、句式結構等表面特征進行匹配，很難理解語言的細微差別、上下文含義或真實意圖。另外，對于規則庫中沒有預設到的措辭或條款變體，即使意思相同，也可能漏報或誤報。 例如一個條款單獨看可能沒問題，但與其他條款結合起來就可能產生風險。

僵化與維護成本高：

其次，這種人工驅動的規則庫需要持續、大量的更新和維護，成本高且容易滯后。尤其是為了覆蓋更多場景，規則數量會急劇增加，導致規則間的沖突、管理復雜度會逐漸失控。 

用戶體驗與解釋性：

傳統方法輸出一般是一堆“規則違反”列表，缺乏對風險的深入解釋和業務影響的分析，以及具體的、有針對性的修改建議，這點對于用戶而言也是顯然不夠友好。

2、通用規則 vs Bad Cases

梳理了傳統規則引擎的實現邏輯和局限性，這里接著介紹下這篇要展示的工作流編排邏輯。

2.1優勢互補

首先需要說明的是，這兩者在合同審查中都非常重要，但扮演著不同且互補的角色。 通用規則 (上文說的傳統規則引擎)作用是基礎框架與合規性檢查，它更像一個“體檢表”，用于快速判斷合同在結構上是否完整，核心條款是否缺失，以及是否存在一些基礎的、普遍適用的法律或商業實踐要求未被滿足。通用規則也是審查的基石和起點，保證了合同的“骨架”基本正確。

而上文一直提到的負面案例 (Bad Cases)主要作用則是審查的深度和經驗的體現?；蛘邠Q句話說，是具體風險場景的警示。在真實業務合同中的某些條款的缺失、模糊或不當設計是如何導致實際問題的（如爭議、損失、敗訴等）。Bad Cases 往往與特定的合同類型、行業背景或業務邏輯緊密相關，使得風險分析更具針對性。 

總結來說， 通用規則更像是“靜態的知識庫”，告訴你“應該是什么樣的”。 而 Bad Cases 是“動態的經驗庫”，告訴你“曾經發生過什么問題，為什么會發生，后果如何”。 在審查中，通常會先用通用規則進行一遍“掃描”，確保基礎項沒有問題。然后，針對合同的特定類型、交易背景以及在初步掃描中發現的潛在疑點，去 Bad Cases 庫中尋找相似情境，以進行更深入、更具針對性的風險評估和條款優化。 

兩者哪個更重要？ 它們都重要，缺一不可，是相輔相成的。如果只看通用規則，審查可能流于表面，無法預見復雜風險；如果只看 Bad Cases，可能會缺乏系統性，遺漏一些基礎但關鍵的問題。

2.2Bad Cases 召回策略

進一步來說，在 Dify（或類似）工作流匯總召回 Bad Cases 時，為了確保相關性和有效性，可以考慮以下優先級順序： 

問題條款相似性:

如果新合同中的某個條款的措辭、結構或潛在邏輯缺陷，與某個 Bad Case 中明確指出并導致問題的條款高度相似，那么這個 Bad Case 的參考價值是最大的。無論合同類型或行業是否完全一致，相似的問題條款往往意味著相似的風險邏輯。 例如: 新合同的驗收條款約定“甲方收到乙方交付物后，如無書面異議，則視為驗收合格”，這與某個 Bad Case 中因此類“默認合格”條款引發爭議高度相關。 

合同類型:

這點不言自明，相同類型的合同往往具有相似的交易結構、核心目標和常見的風險領域。例如，軟件開發合同通常會關注知識產權、交付驗收、維護責任等，而租賃合同則更關注租賃物狀況、租金支付、違約責任等。因此，來自同一合同類型的 Bad Case 更可能觸及與當前審查合同直接相關的議題。 例如: 審查一份新的“軟件外包開發合同”時，來自歷史“軟件開發服務合同”的 Bad Case 通常比來自“房屋租賃合同”的 Bad Case 更具參考性。 

業務場景相似性:

行業特性和具體的業務場景會顯著影響合同條款的風險權重和解釋。某些在某個行業是標準做法的條款，在另一個行業可能就是重大風險。業務場景決定了合同履行的具體環境和可能的矛盾點。 例如: 一份涉及處理大量個人敏感數據的市場推廣合同，在召回 Bad Case 時，與數據合規、隱私保護相關的案例（即使合同類型略有差異，但如果行業同為互聯網廣告或涉及用戶數據處理）可能比一個不涉及敏感數據的普通服務合同的 Bad Case 更重要。

總結來說,首先看“問題像不像”：條款本身是否存在已知的風險模式？ 其次看“合同大類像不像”：是不是同一類型的法律關系和交易框架？ 再看“具體環境像不像”：行業慣例、業務流程是否會讓這個風險更加突出或具有不同的表現形式？ 在理想情況下，工作流能夠綜合評估這些因素，并根據匹配度給出一個加權排序的 Bad Case 列表。例如，一個與當前新合同條款高度相似、合同類型一致且行業背景也相近的 Bad Case，這樣參考價值無疑是最高的。

3、樣例數據解析

下文工作流演示中所采用的樣例數據包括：3 份典型的待審查合同、5 份負面案例（Bad Cases），以及 1 套基礎的審查規則。除了因為保密協議無法直接使用接觸的商業項目資料外，通過模擬數據其實可以更有針對性地設計合同條款和潛在風險點，從而清晰地展示工作流在識別、分析和處理這些特定問題時的核心邏輯和能力。這比使用結構復雜、包含大量無關信息的真實合同更能突出重點。

3.1合同類型的多樣性：

NC001: 軟件外包開發合同：這是常見的技術服務類合同，涉及項目范圍、交付、驗收、知識產權等多個關鍵點，能充分測試工作流對復雜業務邏輯的理解。

NC002: 單向保密協議 (接收方視角)：這類合同專注于信息保密，條款相對聚焦，但對定義的準確性、義務的合理性要求很高。從“接收方視角”出發，可以測試工作流是否能識別出對單方不利的潛在風險。

NC003: 市場推廣服務合同：這類合同通常包含效果承諾（KPI）、成果歸屬等，能測試工作流對服務效果衡量、知識產權轉移等方面的審查能力。

三份合同里經過設計都預埋了些對應場景中一些典型風險點，這些新合同中的條款，很多都能直接或間接地與 Basic_rules.md 中的通用規則以及 Bade cases 文件夾中案例的風險點對應起來，便于工作流進行參照和匹配。

3.2負面案例 (Bad Case 1-5) 的設計

覆蓋常見的合同類型和風險領域

BC001: 軟件開發服務合同 - 驗收、違約責任、爭議解決。

BC002: 保密協議 (NDA) - 保密范圍、期限、違約責任。

BC003: 房屋租賃合同 - 交付標準、押金、提前終止、續租。

BC004: 產品采購合同 - 質量標準、驗收期、責任限制。

BC005: 咨詢服務合同 - 付款條件、成果交付、知識產權、終止條款。

這種多樣性確保了工作流的知識庫具有一定的廣度。

結構化的風險總結

每個 Bad Case 都清晰地列出了 identified_risks, problematic_clauses_summary, 和 suggestion_or_lesson。這種結構化信息非常適合 LLM 進行學習和提取，能夠讓工作流更準確地理解歷史風險的上下文和解決方案。

此外，這些案例中暴露的問題，如定義模糊、權利義務不對等、缺少關鍵保護、責任限制不合理等，都是合同審查中非常經典和常見的風險類型，具有很好的代表性。

通過這種設計，當新的待審查合同進入工作流時，通用規則（Basic_rules.md）提供了普適性的檢查清單。新合同中的潛在風險點，可以通過與 Bad Cases 中的 keywords_for_retrieval 和 identified_risks 進行匹配，快速找到相似的歷史案例。Bad Cases 中的 suggestion_or_lesson 可以為新合同的審查報告提供具體的修改方向和風險警示。

4、工作流編排邏輯

這個工作流實現了一個多階段的合同審查流程，具體來說分為以下四個部分：

4.1輸入收集與預處理

收集用戶提供的合同文件、特定關注點、合同類型和通用審查規則，提取并轉換合同文本。

每個Bad Cases上傳時不要做任何切片處理

工作流觸發的輸入頁面

注：“合同文本提取”節點輸出的是包含單個字符串的列表'合同內容'，而后續 LLM 或 Template 節點可能期望的是純字符串合同內容。最初我忽略了這種細微的類型差異，導致 Prompt 渲染異常或 LLM 理解偏差，后來增加 Template 節點進行顯式數據類型轉換。

4.2初步風險識別

使用 LLM 對合同文本進行初步分析，快速識別潛在風險點。

4.3相似案例檢索與分析

根據初步風險和合同類型，從知識庫中檢索相關的歷史風險案例 (bad cases)，并由另一個 LLM 提取這些案例的關鍵風險點。

4.4綜合審查與報告生成

將新合同文本、初步風險分析、相關歷史案例風險、通用審查規則以及用戶特定關注點整合起來，形成一個詳細的提示，交由一個強大的 LLM 進行深度審查，并生成結構化的合同審查報告。

注：即便所有輸入信息都正確傳遞給了最終的審查 LLM，它也可能因為 Prompt 不夠優化而無法產出高質量的、有針對性的報告。解決方案是優先使用大參數的高階 LLM，其次是盡可能設計結構化、任務明確、信息聚焦的最終 Prompt。

5、運行結果展示

6、三點優化方向參考

感興趣的推薦從輸入信息質量深化（Bad Case 處理）、輸出結果行動性增強（修改建議）和系統整體智能與用戶體驗提升（迭代與反饋）三點著手。

6.1通過 Loop 節點對召回的 Bad Cases 進行逐一分析

當前的 Bad Case 風險點總結是將所有召回的 Bad Cases 結果作為一個整體交由單個 LLM 調用進行處理，要求其“對于輸入文本中明確存在的每一個案例”進行總結。 可以考慮換成引入一個 Loop（循環）節點。 循環的輸入是召回的 Bad Case 列表，每次迭代處理一個 Bad Case，進行更細致的關聯性分析。

6.2引入“條款級風險定位與具體修改建議生成”能力

當前工作流的輸出是一份“合同審查報告”，其中包含修改建議，但工作流本身不能直接生成可用的、具體的條款修改文本。 可以考慮調整“新合同的審核”節點的 LLM 提示詞，明確要求其不僅識別風險，還要定位到新合同中的具體問題條款編號和原文，進而針對識別出的每一個主要風險點，嘗試生成 1-2 個具體的、可操作的條款修改建議文本。 

6.3建立迭代式審查與用戶反饋機制

當前工作流是一個單向的處理流程，用戶輸入合同，得到一份審查報告。在輸出審查報告后，如果能允許用戶選擇報告中的某個風險點，然后觸發一個新的、更聚焦的 LLM 調用，針對該點進行更深入的解釋、提供更多替代修改方案、或分析特定修改方案的利弊，會更助于得到一個更加理想的結果。（這點類似 OpenAI、Gemini 的 Deep Research 的交互邏輯。）

7、RAG 進階方向探討

RAG 的進階應用，不僅僅是簡單的信息檢索和問答，是利用 RAG 作為核心能力之一，結合更復雜的邏輯、多步驟處理、外部工具調用、模型間的協作，來完成更復雜的任務或驅動更智能的交互。