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

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

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

結(jié)合我過去幾個月一些相關(guān)項目中的實踐經(jīng)驗，這篇基于 Dify 工作流和設(shè)計的樣例數(shù)據(jù)，向各位展示一個可快速上手的解決方案示例。

以下，enjoy:

1、現(xiàn)代合同審查工具及其局限性

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

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

1.1核心做法

知識庫構(gòu)建與規(guī)則編碼：

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

來源：自制

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

自動化掃描與標記：

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

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

1.2局限性

語義理解的缺失：

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

僵化與維護成本高：

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

用戶體驗與解釋性：

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

2、通用規(guī)則 vs Bad Cases

梳理了傳統(tǒng)規(guī)則引擎的實現(xiàn)邏輯和局限性，這里接著介紹下這篇要展示的工作流編排邏輯。

2.1優(yōu)勢互補

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

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

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

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

2.2Bad Cases 召回策略

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

問題條款相似性:

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

合同類型:

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

業(yè)務(wù)場景相似性:

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

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

3、樣例數(shù)據(jù)解析

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

3.1合同類型的多樣性：

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

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

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

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

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

覆蓋常見的合同類型和風(fēng)險領(lǐng)域

BC001: 軟件開發(fā)服務(wù)合同 - 驗收、違約責(zé)任、爭議解決。

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

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

BC004: 產(chǎn)品采購合同 - 質(zhì)量標準、驗收期、責(zé)任限制。

BC005: 咨詢服務(wù)合同 - 付款條件、成果交付、知識產(chǎn)權(quán)、終止條款。

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

結(jié)構(gòu)化的風(fēng)險總結(jié)

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

此外，這些案例中暴露的問題，如定義模糊、權(quán)利義務(wù)不對等、缺少關(guān)鍵保護、責(zé)任限制不合理等，都是合同審查中非常經(jīng)典和常見的風(fēng)險類型，具有很好的代表性。

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

4、工作流編排邏輯

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

4.1輸入收集與預(yù)處理

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

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

工作流觸發(fā)的輸入頁面

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

4.2初步風(fēng)險識別

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

4.3相似案例檢索與分析

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

4.4綜合審查與報告生成

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

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

5、運行結(jié)果展示

6、三點優(yōu)化方向參考

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

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

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

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

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

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

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

7、RAG 進階方向探討

RAG 的進階應(yīng)用，不僅僅是簡單的信息檢索和問答，是利用 RAG 作為核心能力之一，結(jié)合更復(fù)雜的邏輯、多步驟處理、外部工具調(diào)用、模型間的協(xié)作，來完成更復(fù)雜的任務(wù)或驅(qū)動更智能的交互。