引言法律AI的特殊性——从“辅助”到“可担责”法律行业是AI落地的“高难度模式”。与客服、营销等场景不同法律AI的每一个输出都可能影响合同效力、诉讼策略甚至当事人权益。2025年杭州互联网法院审结了全国首例因生成式AI模型“幻觉”引发的侵权纠纷案这为法律行业敲响了警钟——AI的“不靠谱”在法律场景中可能直接导致法律责任。法律AI系统的核心挑战可以概括为三个层次挑战具体表现后果数据泄露客户隐私、案件涉密数据上传云端侵害客户权益、影响案件公正审理内容失真幻觉AI生成看似合理却与事实相悖的内容可能导致客户损失、案件败诉职业责任模糊责任归属不清“谁使用、谁负责”原则难落地职业伦理风险、追责困难构建法律/合规场景下的AI系统必须从“能回答问题”升级为“能负责任地回答”——可追溯、可验证、可审计。本文将从法律文本的特殊处理、可信RAG架构、输出约束与审计三个维度给出可落地的技术方案。一、法律文本的特殊性结构化意识是关键1.1 为什么通用RAG在法律场景失效标准RAG系统按固定token长度切分文本这在法律文本场景中会严重破坏文档的语义结构。以欧盟《人工智能法案》为例第六条Article 6的分类规则引用附件三Annex III的高风险名单而附件三又触发分布于第九至十四条的义务。固定长度切分会切断这种“法条-附件-义务”的层级依赖关系导致检索时遗漏关键上下文。1.2 法律结构感知的分块解决方案是基于法律文档结构的智能分块——按章Chapter、节Section、条Article、附件Annex边界切分保留每个块承载的法律逻辑。# legal_chunker.py - 法律文档结构化分块importrefromtypingimportList,Dict,AnyfromdataclassesimportdataclassdataclassclassLegalChunk:法律文档块保留结构元数据content:strchunk_type:str# article | annex | recital | chapterhierarchy:List[str]# [Chapter 1, Article 6, Paragraph 3]metadata:Dict[str,Any]classLegalStructureChunker: 法律文档结构化分块器 核心原则 1. 按法律文档的层级结构章→节→条→款进行分块 2. 每个块保留完整的层级路径 3. 跨块引用关系通过metadata追踪 def__init__(self):# 法律文档结构模式可扩展self.article_patternre.compile(r^(?:第[一二三四五六七八九十百千万]条|Article\s\d|§\s*\d)\s(.*?)$,re.MULTILINE)self.chapter_patternre.compile(r^(?:第[一二三四五六七八九十百千万]章|Chapter\s\d)\s(.*?)$,re.MULTILINE)self.annex_patternre.compile(r^(?:附件|Annex|Appendix)\s[A-Z]?\d*\s*(?:——)?\s*(.*?)$,re.MULTILINE)defchunk_document(self,text:str)-List[LegalChunk]: 对法律文档进行结构化分块 chunks[]current_hierarchy[]linestext.split(\n)current_block[]current_typetextforlineinlines:# 检测章节标题ifself.chapter_pattern.match(line):# 保存之前的块ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))current_block[]current_hierarchy.append(line.strip())current_typechaptercurrent_block.append(line)# 检测条款elifself.article_pattern.match(line):ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))current_block[]current_typearticlecurrent_block.append(line)# 检测附件elifself.annex_pattern.match(line):ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))current_block[]current_typeannexcurrent_block.append(line)else:current_block.append(line)# 保存最后一个块ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))returnchunksdef_create_chunk(self,content:str,chunk_type:str,hierarchy:List[str])-LegalChunk:创建法律块对象returnLegalChunk(contentcontent.strip(),chunk_typechunk_type,hierarchyhierarchy,metadata{hierarchy_path: → .join(hierarchy),chunk_length:len(content)})效果说明与固定长度分块相比结构感知分块可将跨条款引用场景的检索准确率提升15-25%。二、可信RAG让每个回答都有“法条支撑”2.1 自查询路由Self-Query Routing法律检索的一个关键问题是“附件三”和“第六条”在语义空间上非常接近都是法律文本、同一语域但它们的法律后果完全不同。纯语义检索会将两者混淆。解决方案是自查询路由——先用规则检测用户问题中是否包含明确的法律引用“Article 6”、“附件三”、“第X条”如果有直接应用metadata过滤后再进行向量检索消除这类错误。# self_query_router.py - 自查询路由importrefromtypingimportDict,Any,Tuple,OptionalclassSelfQueryRouter: 自查询路由检测法律引用应用元数据过滤 为什么需要法律文本中“Annex III”和“Article 6”语义相似 但法律后果完全不同。路由层在向量检索之前介入先过滤再检索。 def__init__(self):# 法律引用模式self.patterns{article:re.compile(r(?:Article|第)(?:\s*)(\d)(?:[.-]?\s*\d)?,re.IGNORECASE),annex:re.compile(r(?:Annex|附件)(?:\s*)([A-Z]?\d*),re.IGNORECASE),recital:re.compile(r(?:Recital|序言)(?:\s*)(\d),re.IGNORECASE),chapter:re.compile(r(?:Chapter|第[一二三四五六七八九十]章),re.IGNORECASE)}defroute(self,query:str)-Tuple[str,Dict[str,Any]]: 路由决策返回检索模式和过滤条件 Returns: (route_type, filter_metadata) route_type: metadata_filtered | full_vector detected_refsself._detect_references(query)ifdetected_refs:# 存在明确法律引用 → 使用metadata过滤检索returnmetadata_filtered,{filters:detected_refs,strategy:exact_reference_first}# 无明确引用 → 标准向量检索returnfull_vector,{}def_detect_references(self,query:str)-Dict[str,list]:检测所有法律引用refs{articles:[],annexes:[],recitals:[]}article_matchself.patterns[article].findall(query)ifarticle_match:refs[articles][int(a)forainarticle_match]annex_matchself.patterns[annex].findall(query)ifannex_match:refs[annexes]annex_match recital_matchself.patterns[recital].findall(query)ifrecital_match:refs[recitals][int(r)forrinrecital_match]returnrefs2.2 动态Token预算法律问题的复杂度差异很大——“第6条是什么”和“我的AI系统是否属于高风险”所需的上下文量完全不同。固定上下文窗口要么浪费token要么上下文不足。动态Token预算根据查询复杂度自动调整上下文窗口6K-10K Token查询中包含多个法律引用时使用更大的预算。# dynamic_token_budget.py - 动态Token预算fromtypingimportDict,AnyclassDynamicTokenBudget: 动态Token预算根据查询复杂度调整上下文窗口 策略 1. 简单查询单一法条引用→ 较小窗口6K 2. 复杂查询跨条款交叉引用→ 较大窗口10K 3. 同时根据检索结果数量动态调整 def__init__(self,min_tokens:int6000,max_tokens:int10000):self.min_tokensmin_tokens self.max_tokensmax_tokensdefcompute_budget(self,query:str,num_retrieved:int)-int: 计算当前查询应该使用的Token预算 # 1. 基于查询复杂度complexity_scoreself._compute_complexity(query)# 2. 基于检索结果数量retrieval_factormin(num_retrieved/10,1.0)# 3. 综合计算budgetself.min_tokens((self.max_tokens-self.min_tokens)*(0.3*complexity_score0.7*retrieval_factor))# 4. 法律特殊场景包含“高风险”、“合规”等关键词时增大预算high_risk_keywords[高风险,违规,处罚,制裁,compliance,high-risk]ifany(kwinquery.lower()forkwinhigh_risk_keywords):budgetmin(budget*1.2,self.max_tokens)returnint(budget)def_compute_complexity(self,query:str)-float:计算查询复杂度0-1# 检测法律引用数量importre refsre.findall(r(?:Article|第|Annex|附件|§)\s*\d,query)ref_countlen(refs)# 检测“和”、“与”、“vs”等连接词表明交叉引用has_cross_refany(kwinqueryforkwin[和,与,vs,and,versus])# 计算复杂度分数scoremin(ref_count*0.15,0.6)ifhas_cross_ref:score0.2iflen(query)100:score0.2returnmin(score,1.0)三、可信输出引用、审计与合规架构3.1 带引用的结构化输出法律AI系统必须追溯答案来源——每个结论都要关联到具体的法条、条款和依据。以下是一个带引用的输出结构设计# trusted_output.py - 可信输出结构fromtypingimportList,Dict,Any,Optionalfromdataclassesimportdataclass,fielddataclassclassLegalReference:法律引用信息source_type:str# article | annex | case | regulationcitation:str# Article 6(2)content_snippet:strfull_text:Optional[str]Nonerelevance_score:float0.0dataclassclassRiskAssessment:风险评估卡片clause_content:str# 被评估的条款内容risk_level:str# high | medium | lowrisk_reason:str# 风险原因说明references:List[LegalReference]# 法律依据recommended_action:str# 修改建议dataclassclassTrustedLegalOutput:可信法律输出answer:str# 自然语言回答risk_assessments:List[RiskAssessment]# 风险卡片references:List[LegalReference]# 所有引用confidence:float# 0-1基于检索质量和引用覆盖audit_id:str# 审计追踪IDgeneration_metadata:Dict[str,Any]# 路由信息、Token消耗等classLegalOutputBuilder:构建可信的法律输出defbuild(self,raw_answer:str,retrieved_chunks:List[Dict],risk_data:List[Dict])-TrustedLegalOutput: 从原始LLM输出构建结构化可信输出 # 提取引用referencesself._extract_references(retrieved_chunks)# 构建风险卡片assessments[]foriteminrisk_data:assessments.append(RiskAssessment(clause_contentitem.get(clause,),risk_levelitem.get(level,medium),risk_reasonitem.get(reason,),referencesself._match_references(item.get(citation_ids,[]),references),recommended_actionitem.get(suggestion,)))# 计算置信度基于引用覆盖度和检索分数confidenceself._compute_confidence(retrieved_chunks)returnTrustedLegalOutput(answerraw_answer,risk_assessmentsassessments,referencesreferences,confidenceconfidence,audit_idself._generate_audit_id(),generation_metadata{retrieved_chunk_count:len(retrieved_chunks),reference_count:len(references)})def_extract_references(self,chunks:List[Dict])-List[LegalReference]:从检索块中提取引用信息references[]forchunkinchunks:metadatachunk.get(metadata,{})ifmetadata.get(article_number):references.append(LegalReference(source_typearticle,citationfArticle{metadata[article_number]},content_snippetchunk.get(content,)[:200],relevance_scorechunk.get(score,0.0)))returnreferencesdef_compute_confidence(self,chunks:List[Dict])-float:计算输出置信度ifnotchunks:return0.0avg_scoresum(c.get(score,0)forcinchunks)/len(chunks)# 至少需要3个高质量块high_qualitysum(1forcinchunksifc.get(score,0)0.7)coverage_factormin(high_quality/3,1.0)returnmin(avg_score*0.6coverage_factor*0.4,1.0)def_generate_audit_id(self)-str:importuuidreturnfLEGAL_AUDIT_{uuid.uuid4().hex[:12].upper()}3.2 合规治理regulated-ai-governance在实际生产环境中法律合规AI系统还需要框架级的权限控制。regulated-ai-governance库为CrewAI、AutoGen、LangChain等主流Agent框架提供了政策执行层——在任何Action执行前进行授权检查并生成合规审计记录。# governance_integration.py - 法律合规治理集成fromregulated_ai_governance.integrations.langchainimportGovernanceCallbackHandlerfromregulated_ai_governance.regulations.hipaaimportmake_hipaa_treating_provider_policy# 创建法律合规政策适用于处理敏感法律数据policymake_hipaa_treating_provider_policy(escalate_external_share_tolegal_compliance_officer)# 包装工具调用governance_handlerGovernanceCallbackHandler(policypolicy,regulationHIPAA,# 或 GDPR, GLBAactor_iduser_legal_001,audit_sinklambdarec:write_to_compliance_log(rec),block_on_escalationTrue,)# 在LangChain Agent中使用agentAgent(tools[governance_handler.wrap_tool(my_legal_tool)],...)# 每次调用自动产生审计记录# {regulation: HIPAA, action: read_contract,# permitted: True, actor: user_legal_001, timestamp: ...}四、完整闭环从检测到审计结合法律合规AI助手在金融机构的落地经验和开源的Contract Compliance Agent架构法律AI系统的完整可信链路应包含以下环节# legal_ai_pipeline.py - 完整法律AI可信链路fromtypingimportDict,Any,ListimportuuidfromdatetimeimportdatetimeclassLegalAIPipeline: 法律AI完整可信链路 五个环节 1. 结构化分块保留法律层级 2. 路由法律引用检测 → 元数据过滤检索 3. 动态Token预算 4. 输出构建引用 风险卡片 5. 审计登记全链路可追溯 def__init__(self,chunker:LegalStructureChunker,router:SelfQueryRouter,budget:DynamicTokenBudget,output_builder:LegalOutputBuilder):self.chunkerchunker self.routerrouter self.budgetbudget self.output_builderoutput_builder self.audit_log[]defprocess(self,document:str,user_query:str,user_id:str)-TrustedLegalOutput:处理法律文本分析请求audit_idfAUDIT_{uuid.uuid4().hex[:8]}# 1. 结构化分块chunksself.chunker.chunk_document(document)# 2. 路由决策检测法律引用route_type,filtersself.router.route(user_query)# 3. 检索略实际实现中调用向量检索retrievedself._retrieve_with_filters(user_query,filters,chunks)# 4. 动态Token预算budgetself.budget.compute_budget(user_query,len(retrieved))# 5. LLM生成略raw_answerself._generate_answer(user_query,retrieved,budget)# 6. 构建可信输出outputself.output_builder.build(raw_answer,retrieved,[])# 7. 审计登记self._audit(audit_id,user_id,route_type,output)returnoutputdef_audit(self,audit_id:str,user_id:str,route_type:str,output:TrustedLegalOutput):登记审计记录record{audit_id:audit_id,user_id:user_id,timestamp:datetime.now().isoformat(),route_type:route_type,confidence:output.confidence,reference_count:len(output.references),risk_count:len(output.risk_assessments)}self.audit_log.append(record)# 实际生产环境持久化到数据库# db.compliance_logs.insert(record)defget_audit_trail(self,user_id:str)-List[Dict]:获取用户审计追踪return[rforrinself.audit_logifr[user_id]user_id]结语法律AI系统的“信条”构建法律/合规场景下的AI辅助系统核心原则可以归结为三条辅助而非替代最高人民法院已明确“辅助审判”原则——AI的辅助结果仅作为参考最终决策权永远属于人。可追溯是底线每个答案都必须有“法条支撑”每个操作都必须有“审计记录”。德恒律师事务所的指引明确指出所有AI生成内容应标记“由AI生成请务必人工审核”。隐私保护是前提法律数据的敏感性决定了“本地部署优先”原则。将敏感数据上传至第三方云平台的风险远大于收益。法律AI的工程化本质上是将AI从“能回答”升级为“能负责任地回答”。这需要结构感知的分块、自查询路由、带引用的可信输出和全链路审计四个层面的协同。当所有这些机制运转起来AI才能真正成为法律工作者的“可信助手”而非“不可靠的风险源”。
构建法律/合规场景下的AI辅助系统：文本处理与可信输出
引言法律AI的特殊性——从“辅助”到“可担责”法律行业是AI落地的“高难度模式”。与客服、营销等场景不同法律AI的每一个输出都可能影响合同效力、诉讼策略甚至当事人权益。2025年杭州互联网法院审结了全国首例因生成式AI模型“幻觉”引发的侵权纠纷案这为法律行业敲响了警钟——AI的“不靠谱”在法律场景中可能直接导致法律责任。法律AI系统的核心挑战可以概括为三个层次挑战具体表现后果数据泄露客户隐私、案件涉密数据上传云端侵害客户权益、影响案件公正审理内容失真幻觉AI生成看似合理却与事实相悖的内容可能导致客户损失、案件败诉职业责任模糊责任归属不清“谁使用、谁负责”原则难落地职业伦理风险、追责困难构建法律/合规场景下的AI系统必须从“能回答问题”升级为“能负责任地回答”——可追溯、可验证、可审计。本文将从法律文本的特殊处理、可信RAG架构、输出约束与审计三个维度给出可落地的技术方案。一、法律文本的特殊性结构化意识是关键1.1 为什么通用RAG在法律场景失效标准RAG系统按固定token长度切分文本这在法律文本场景中会严重破坏文档的语义结构。以欧盟《人工智能法案》为例第六条Article 6的分类规则引用附件三Annex III的高风险名单而附件三又触发分布于第九至十四条的义务。固定长度切分会切断这种“法条-附件-义务”的层级依赖关系导致检索时遗漏关键上下文。1.2 法律结构感知的分块解决方案是基于法律文档结构的智能分块——按章Chapter、节Section、条Article、附件Annex边界切分保留每个块承载的法律逻辑。# legal_chunker.py - 法律文档结构化分块importrefromtypingimportList,Dict,AnyfromdataclassesimportdataclassdataclassclassLegalChunk:法律文档块保留结构元数据content:strchunk_type:str# article | annex | recital | chapterhierarchy:List[str]# [Chapter 1, Article 6, Paragraph 3]metadata:Dict[str,Any]classLegalStructureChunker: 法律文档结构化分块器 核心原则 1. 按法律文档的层级结构章→节→条→款进行分块 2. 每个块保留完整的层级路径 3. 跨块引用关系通过metadata追踪 def__init__(self):# 法律文档结构模式可扩展self.article_patternre.compile(r^(?:第[一二三四五六七八九十百千万]条|Article\s\d|§\s*\d)\s(.*?)$,re.MULTILINE)self.chapter_patternre.compile(r^(?:第[一二三四五六七八九十百千万]章|Chapter\s\d)\s(.*?)$,re.MULTILINE)self.annex_patternre.compile(r^(?:附件|Annex|Appendix)\s[A-Z]?\d*\s*(?:——)?\s*(.*?)$,re.MULTILINE)defchunk_document(self,text:str)-List[LegalChunk]: 对法律文档进行结构化分块 chunks[]current_hierarchy[]linestext.split(\n)current_block[]current_typetextforlineinlines:# 检测章节标题ifself.chapter_pattern.match(line):# 保存之前的块ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))current_block[]current_hierarchy.append(line.strip())current_typechaptercurrent_block.append(line)# 检测条款elifself.article_pattern.match(line):ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))current_block[]current_typearticlecurrent_block.append(line)# 检测附件elifself.annex_pattern.match(line):ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))current_block[]current_typeannexcurrent_block.append(line)else:current_block.append(line)# 保存最后一个块ifcurrent_block:chunks.append(self._create_chunk(\n.join(current_block),current_type,current_hierarchy.copy()))returnchunksdef_create_chunk(self,content:str,chunk_type:str,hierarchy:List[str])-LegalChunk:创建法律块对象returnLegalChunk(contentcontent.strip(),chunk_typechunk_type,hierarchyhierarchy,metadata{hierarchy_path: → .join(hierarchy),chunk_length:len(content)})效果说明与固定长度分块相比结构感知分块可将跨条款引用场景的检索准确率提升15-25%。二、可信RAG让每个回答都有“法条支撑”2.1 自查询路由Self-Query Routing法律检索的一个关键问题是“附件三”和“第六条”在语义空间上非常接近都是法律文本、同一语域但它们的法律后果完全不同。纯语义检索会将两者混淆。解决方案是自查询路由——先用规则检测用户问题中是否包含明确的法律引用“Article 6”、“附件三”、“第X条”如果有直接应用metadata过滤后再进行向量检索消除这类错误。# self_query_router.py - 自查询路由importrefromtypingimportDict,Any,Tuple,OptionalclassSelfQueryRouter: 自查询路由检测法律引用应用元数据过滤 为什么需要法律文本中“Annex III”和“Article 6”语义相似 但法律后果完全不同。路由层在向量检索之前介入先过滤再检索。 def__init__(self):# 法律引用模式self.patterns{article:re.compile(r(?:Article|第)(?:\s*)(\d)(?:[.-]?\s*\d)?,re.IGNORECASE),annex:re.compile(r(?:Annex|附件)(?:\s*)([A-Z]?\d*),re.IGNORECASE),recital:re.compile(r(?:Recital|序言)(?:\s*)(\d),re.IGNORECASE),chapter:re.compile(r(?:Chapter|第[一二三四五六七八九十]章),re.IGNORECASE)}defroute(self,query:str)-Tuple[str,Dict[str,Any]]: 路由决策返回检索模式和过滤条件 Returns: (route_type, filter_metadata) route_type: metadata_filtered | full_vector detected_refsself._detect_references(query)ifdetected_refs:# 存在明确法律引用 → 使用metadata过滤检索returnmetadata_filtered,{filters:detected_refs,strategy:exact_reference_first}# 无明确引用 → 标准向量检索returnfull_vector,{}def_detect_references(self,query:str)-Dict[str,list]:检测所有法律引用refs{articles:[],annexes:[],recitals:[]}article_matchself.patterns[article].findall(query)ifarticle_match:refs[articles][int(a)forainarticle_match]annex_matchself.patterns[annex].findall(query)ifannex_match:refs[annexes]annex_match recital_matchself.patterns[recital].findall(query)ifrecital_match:refs[recitals][int(r)forrinrecital_match]returnrefs2.2 动态Token预算法律问题的复杂度差异很大——“第6条是什么”和“我的AI系统是否属于高风险”所需的上下文量完全不同。固定上下文窗口要么浪费token要么上下文不足。动态Token预算根据查询复杂度自动调整上下文窗口6K-10K Token查询中包含多个法律引用时使用更大的预算。# dynamic_token_budget.py - 动态Token预算fromtypingimportDict,AnyclassDynamicTokenBudget: 动态Token预算根据查询复杂度调整上下文窗口 策略 1. 简单查询单一法条引用→ 较小窗口6K 2. 复杂查询跨条款交叉引用→ 较大窗口10K 3. 同时根据检索结果数量动态调整 def__init__(self,min_tokens:int6000,max_tokens:int10000):self.min_tokensmin_tokens self.max_tokensmax_tokensdefcompute_budget(self,query:str,num_retrieved:int)-int: 计算当前查询应该使用的Token预算 # 1. 基于查询复杂度complexity_scoreself._compute_complexity(query)# 2. 基于检索结果数量retrieval_factormin(num_retrieved/10,1.0)# 3. 综合计算budgetself.min_tokens((self.max_tokens-self.min_tokens)*(0.3*complexity_score0.7*retrieval_factor))# 4. 法律特殊场景包含“高风险”、“合规”等关键词时增大预算high_risk_keywords[高风险,违规,处罚,制裁,compliance,high-risk]ifany(kwinquery.lower()forkwinhigh_risk_keywords):budgetmin(budget*1.2,self.max_tokens)returnint(budget)def_compute_complexity(self,query:str)-float:计算查询复杂度0-1# 检测法律引用数量importre refsre.findall(r(?:Article|第|Annex|附件|§)\s*\d,query)ref_countlen(refs)# 检测“和”、“与”、“vs”等连接词表明交叉引用has_cross_refany(kwinqueryforkwin[和,与,vs,and,versus])# 计算复杂度分数scoremin(ref_count*0.15,0.6)ifhas_cross_ref:score0.2iflen(query)100:score0.2returnmin(score,1.0)三、可信输出引用、审计与合规架构3.1 带引用的结构化输出法律AI系统必须追溯答案来源——每个结论都要关联到具体的法条、条款和依据。以下是一个带引用的输出结构设计# trusted_output.py - 可信输出结构fromtypingimportList,Dict,Any,Optionalfromdataclassesimportdataclass,fielddataclassclassLegalReference:法律引用信息source_type:str# article | annex | case | regulationcitation:str# Article 6(2)content_snippet:strfull_text:Optional[str]Nonerelevance_score:float0.0dataclassclassRiskAssessment:风险评估卡片clause_content:str# 被评估的条款内容risk_level:str# high | medium | lowrisk_reason:str# 风险原因说明references:List[LegalReference]# 法律依据recommended_action:str# 修改建议dataclassclassTrustedLegalOutput:可信法律输出answer:str# 自然语言回答risk_assessments:List[RiskAssessment]# 风险卡片references:List[LegalReference]# 所有引用confidence:float# 0-1基于检索质量和引用覆盖audit_id:str# 审计追踪IDgeneration_metadata:Dict[str,Any]# 路由信息、Token消耗等classLegalOutputBuilder:构建可信的法律输出defbuild(self,raw_answer:str,retrieved_chunks:List[Dict],risk_data:List[Dict])-TrustedLegalOutput: 从原始LLM输出构建结构化可信输出 # 提取引用referencesself._extract_references(retrieved_chunks)# 构建风险卡片assessments[]foriteminrisk_data:assessments.append(RiskAssessment(clause_contentitem.get(clause,),risk_levelitem.get(level,medium),risk_reasonitem.get(reason,),referencesself._match_references(item.get(citation_ids,[]),references),recommended_actionitem.get(suggestion,)))# 计算置信度基于引用覆盖度和检索分数confidenceself._compute_confidence(retrieved_chunks)returnTrustedLegalOutput(answerraw_answer,risk_assessmentsassessments,referencesreferences,confidenceconfidence,audit_idself._generate_audit_id(),generation_metadata{retrieved_chunk_count:len(retrieved_chunks),reference_count:len(references)})def_extract_references(self,chunks:List[Dict])-List[LegalReference]:从检索块中提取引用信息references[]forchunkinchunks:metadatachunk.get(metadata,{})ifmetadata.get(article_number):references.append(LegalReference(source_typearticle,citationfArticle{metadata[article_number]},content_snippetchunk.get(content,)[:200],relevance_scorechunk.get(score,0.0)))returnreferencesdef_compute_confidence(self,chunks:List[Dict])-float:计算输出置信度ifnotchunks:return0.0avg_scoresum(c.get(score,0)forcinchunks)/len(chunks)# 至少需要3个高质量块high_qualitysum(1forcinchunksifc.get(score,0)0.7)coverage_factormin(high_quality/3,1.0)returnmin(avg_score*0.6coverage_factor*0.4,1.0)def_generate_audit_id(self)-str:importuuidreturnfLEGAL_AUDIT_{uuid.uuid4().hex[:12].upper()}3.2 合规治理regulated-ai-governance在实际生产环境中法律合规AI系统还需要框架级的权限控制。regulated-ai-governance库为CrewAI、AutoGen、LangChain等主流Agent框架提供了政策执行层——在任何Action执行前进行授权检查并生成合规审计记录。# governance_integration.py - 法律合规治理集成fromregulated_ai_governance.integrations.langchainimportGovernanceCallbackHandlerfromregulated_ai_governance.regulations.hipaaimportmake_hipaa_treating_provider_policy# 创建法律合规政策适用于处理敏感法律数据policymake_hipaa_treating_provider_policy(escalate_external_share_tolegal_compliance_officer)# 包装工具调用governance_handlerGovernanceCallbackHandler(policypolicy,regulationHIPAA,# 或 GDPR, GLBAactor_iduser_legal_001,audit_sinklambdarec:write_to_compliance_log(rec),block_on_escalationTrue,)# 在LangChain Agent中使用agentAgent(tools[governance_handler.wrap_tool(my_legal_tool)],...)# 每次调用自动产生审计记录# {regulation: HIPAA, action: read_contract,# permitted: True, actor: user_legal_001, timestamp: ...}四、完整闭环从检测到审计结合法律合规AI助手在金融机构的落地经验和开源的Contract Compliance Agent架构法律AI系统的完整可信链路应包含以下环节# legal_ai_pipeline.py - 完整法律AI可信链路fromtypingimportDict,Any,ListimportuuidfromdatetimeimportdatetimeclassLegalAIPipeline: 法律AI完整可信链路 五个环节 1. 结构化分块保留法律层级 2. 路由法律引用检测 → 元数据过滤检索 3. 动态Token预算 4. 输出构建引用 风险卡片 5. 审计登记全链路可追溯 def__init__(self,chunker:LegalStructureChunker,router:SelfQueryRouter,budget:DynamicTokenBudget,output_builder:LegalOutputBuilder):self.chunkerchunker self.routerrouter self.budgetbudget self.output_builderoutput_builder self.audit_log[]defprocess(self,document:str,user_query:str,user_id:str)-TrustedLegalOutput:处理法律文本分析请求audit_idfAUDIT_{uuid.uuid4().hex[:8]}# 1. 结构化分块chunksself.chunker.chunk_document(document)# 2. 路由决策检测法律引用route_type,filtersself.router.route(user_query)# 3. 检索略实际实现中调用向量检索retrievedself._retrieve_with_filters(user_query,filters,chunks)# 4. 动态Token预算budgetself.budget.compute_budget(user_query,len(retrieved))# 5. LLM生成略raw_answerself._generate_answer(user_query,retrieved,budget)# 6. 构建可信输出outputself.output_builder.build(raw_answer,retrieved,[])# 7. 审计登记self._audit(audit_id,user_id,route_type,output)returnoutputdef_audit(self,audit_id:str,user_id:str,route_type:str,output:TrustedLegalOutput):登记审计记录record{audit_id:audit_id,user_id:user_id,timestamp:datetime.now().isoformat(),route_type:route_type,confidence:output.confidence,reference_count:len(output.references),risk_count:len(output.risk_assessments)}self.audit_log.append(record)# 实际生产环境持久化到数据库# db.compliance_logs.insert(record)defget_audit_trail(self,user_id:str)-List[Dict]:获取用户审计追踪return[rforrinself.audit_logifr[user_id]user_id]结语法律AI系统的“信条”构建法律/合规场景下的AI辅助系统核心原则可以归结为三条辅助而非替代最高人民法院已明确“辅助审判”原则——AI的辅助结果仅作为参考最终决策权永远属于人。可追溯是底线每个答案都必须有“法条支撑”每个操作都必须有“审计记录”。德恒律师事务所的指引明确指出所有AI生成内容应标记“由AI生成请务必人工审核”。隐私保护是前提法律数据的敏感性决定了“本地部署优先”原则。将敏感数据上传至第三方云平台的风险远大于收益。法律AI的工程化本质上是将AI从“能回答”升级为“能负责任地回答”。这需要结构感知的分块、自查询路由、带引用的可信输出和全链路审计四个层面的协同。当所有这些机制运转起来AI才能真正成为法律工作者的“可信助手”而非“不可靠的风险源”。
