法律咨询Agent的核心不是简单为法律场景套一个聊天窗口，而是把合同审查和判例检索拆成可复用、可监管的处理链路。合同文本通常很长，条款之间逻辑关联强；判例文书既有结构化字段，也有大量说理内容。两者如果都只交给通用大模型一次性处理，容易出现遗漏、幻觉和不可追溯问题。一个更可靠的做法是让Agent分别完成文档解析、要素抽取、风险匹配、混合检索、结果生成和来源校验。
一、合同审查Agent：从条款抽取到风险识别
合同审查的第一步是条款切分和要素抽取。合同往往包含标题、鉴于条款、正文条款、签署页等结构，正文条款又常以“第X条”或“一、二、三”作为起始。如果不做切分直接整篇送入大模型，一方面会撞上上下文长度限制，另一方面模型容易忽略靠后条款中的关键细节。因此更稳妥的做法是先按条款标题或编号切分，再对每个条款单独进行要素抽取。要素通常包括合同主体、金额、付款期限、交付条件、违约责任、解除条件、保密义务和争议解决方式。
条款级抽取可以使用规则加模型的混合方式。金额、日期、百分比等字段用正则表达式就能获得较高准确率，但像“违约金不超过合同总金额的百分之二十”这种表述，还需要语义理解才能正确归入违约金条款。大模型可以做少量样本的结构化抽取，但必须约束返回格式，例如要求返回JSON，并且对缺失字段明确标注null，而不是自由发挥。抽取完成后，系统把结果与风险规则库进行匹配。规则库可以包括付款周期超过60天、单方解除权过宽、违约金比例过高等常见问题。每个风险点都对应等级、解释和修改建议，避免只提示风险但给不出修改方向。
import json
from openai import OpenAI
client = OpenAI()
def extract_clause_risks(clause_text):
prompt = (
"你是合同审查助手。请从以下条款中抽取要素并判断风险。\n"
"输出JSON格式：{\"parties\": [], \"amount\": null, \"deadline\": null, \"risk\": \"\", \"suggestion\": \"\"}\n"
"条款：\n" + clause_text
)
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
temperature=0.1,
response_format={"type": "json_object"}
)
return json.loads(resp.choices[0].message.content)
clause = "乙方应在收到货物后90日内支付全部货款，逾期每日按未付金额的千分之五支付违约金。"
print(extract_clause_risks(clause))
风险识别的结果不能只停留在“存在风险”这个层面，还需要给出可解释的依据。较好的做法是把匹配到的规则、抽取出的要素以及参考条款一起展示给用户。如果合同某一条款被判定为“违约责任不对等”，系统可以同时展示同类合同中相对公平的条款表述，并说明调整建议。这样律师或法务人员可以在较短时间内完成复核，而不是再去手动检索相似条款。对于高风险合同，还应该保留人工确认步骤，避免自动生成的意见被直接当作最终结论。
二、判例检索：混合检索与法律语义匹配
判例检索与普通网页搜索最大的不同在于，法律概念存在大量同义表达，而案号、法条编号又需要精确匹配。只靠关键词检索，用户输入“买卖合同中逾期付款怎么办”时，很难命中写有“买受人未按约定时间支付价款”的判例；只靠向量语义检索，又可能召回语义相近但法律争点完全不同的内容。因此生产环境通常采用BM25关键词检索与向量语义检索并行的混合方案，再用交叉编码器对候选结果做精细排序。
构建判例索引时需要对裁判文书做结构化拆分。完整的裁判文书包含当事人信息、案件事实、本院认为、裁判结果等部分，其中“本院认为”部分对法律争点的判断最为关键，但案件事实和裁判结果也有检索价值。一般会把文书按照自然段切分，并为每个片段保存案号、法院、裁判日期、案由、法条引用等元数据。用户查询进来后，可以先用一个轻量级意图分类器判断用户是想找相似案例、查具体案号，还是检索某条法条下的裁判观点，再决定关键词与向量的权重比例。
from rank_bm25 import BM25Okapi
import numpy as np
from sentence_transformers import SentenceTransformer, CrossEncoder
import faiss
bge = SentenceTransformer("BAAI/bge-large-zh-v1.5")
reranker = CrossEncoder("BAAI/bge-reranker-large")
def build_index(docs):
tokenized = [doc["text"].split() for doc in docs]
bm25 = BM25Okapi(tokenized)
vectors = bge.encode([doc["text"] for doc in docs], normalize_embeddings=True)
dim = vectors.shape[1]
index = faiss.IndexFlatIP(dim)
index.add(vectors)
return bm25, index
def hybrid_search(query, bm25, index, docs, top_k=20):
tokenized_query = query.split()
bm25_scores = bm25.get_scores(tokenized_query)
q_vector = bge.encode([query], normalize_embeddings=True)
_, vec_idx = index.search(q_vector, top_k)
candidates = set(vec_idx[0].tolist()) | set(np.argsort(bm25_scores)[-top_k:].tolist())
pairs = [(query, docs[i]["text"]) for i in candidates]
scores = reranker.predict(pairs)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [docs[i] for i, _ in ranked[:10]]
法律领域的向量表示往往需要专门微调。通用中文向量模型对“连带责任”“表见代理”“除斥期间”等专业术语的区分能力可能不够稳定，导致语义检索召回一些仅表面相关的文书。可以基于裁判文书构建对比学习样本，把同一案由、相似争点的片段作为正样本，把不同案由或无关争点的片段作为负样本，对基础向量模型做领域适配。也可以引入法律知识图谱，把案由、法条、争议焦点作为结构化特征，在召回阶段增加过滤或加权，进一步提升检索精度。
三、幻觉控制与数据合规
判例检索Agent最容易出现的问题是生成虚构案号。大模型在回答法律问题时，如果被要求引用判例但候选集中没有完全匹配的案例，它可能会编造一个看起来合理的案号。这种错误对法律咨询场景影响很严重。因此输出层必须做强约束：只允许从检索结果中摘取案号，检索不到就直接回答“未检索到直接匹配的判例”。同时在代码里增加校验环节，把模型输出中的案号与候选集案号做比对，不在集合内的案号直接标记为不可用。
合同审查和判例检索都涉及敏感数据。合同里可能有身份证号、手机号、银行账号、具体金额和商业秘密，裁判文书中也可能包含个人隐私信息。如果使用外部大模型API，需要先做数据脱敏，例如用命名实体识别模型把个人信息替换为占位符。更严格的环境下可以采用本地化部署，让文档解析、向量化、检索和生成都在内网完成。数据合规还要求记录每一次处理日志，便于追溯某个条款判断或判例引用来自哪个数据源。
def build_legal_answer_prompt(query, retrieved_cases):
case_lines = []
for idx, case in enumerate(retrieved_cases, start=1):
case_lines.append(f"[{idx}] 案号: {case['case_id']}\n法院: {case['court']}\n要旨: {case['summary']}")
joined = "\n".join(case_lines)
return f"""你是法律研究助手。只根据下面提供的判例回答问题，不要使用任何外部知识。
如果判例中没有相关内容，请回答：未检索到直接匹配的判例。
必须引用判例编号，例如 [1]。
判例如下：
{joined}
用户问题：{query}"""
工程架构上，法律咨询Agent适合采用流水线设计。文档解析、条款切分、要素抽取、向量化、检索、重排、生成和校验分别拆成独立模块，通过消息队列连接。合同审查可以按条款并行处理，提升大批量合同的处理速度；判例检索可以离线完成文书入库和索引构建，在线只处理查询与重排。前端展示方面，合同审查结果可以做条款高亮和修订对比，判例检索结果可以展示案号、法院、裁判要旨和原文链接，让用户能快速回到原始文书核实。
四、效果评估与持续迭代
法律咨询Agent上线后需要建立持续评估机制。合同审查可以评估要素抽取的准确率和召回率，以及风险识别的精确率。判例检索除了看召回率和NDCG之外，还要关注引用准确率，也就是模型输出的案号是否真实存在、是否与论点相关。另一个重要指标是用户采纳率，它反映系统给出的修改建议和检索结果是否真正被律师或法务人员采用，这比单纯的离线分数更接近业务价值。
每次生产环境中的用户反馈都可以作为新的标注样本。例如律师对某条风险判断做了修改，可以记录修改前后差异，用于微调抽取模型或更新规则库。判例检索中被用户点击或确认的案例可以作为正样本，被忽略的案例可以作为负样本，用来优化重排模型。整个系统需要具备数据回流能力，让模型和规则库随着业务使用不断迭代，而不是上线后保持固定不变。只有把合同审查与判例检索都做成可评估、可追溯、可反馈的闭环，法律咨询Agent才能在真实业务中持续产生价值。