对话管理框架与DeepSeek构建法律多轮问答系统

简介一套面向法律科技产品经理、NLP算法工程师与方案架构师的DeepSeek法律智能助手对话系统构建方案共554页、50个大章节完整梳理了从需求拆解到模型落地的全过程。方案以DeepSeek对话管理框架为主线围绕法律多轮咨询场景重点解决上下文理解、专业词汇库构建、法律实体与意图识别等关键技术难点并覆盖模型训练、微调、蒸馏部署与轻量化落地的完整链路。内容涵盖法律实体识别模型选型、数据标注规范、训练参数设置、微调与蒸馏等多个实操环节既便于系统化学习也可作为项目方案模板复用。资源为单个PDF文档大小14.38MB目录层级清晰支持章节跳转与书签大纲快速定位文件内容图表与文字显示完整。目前已有108人学习下载对正在规划法律领域对话系统或希望复用DeepSeek技术栈的读者具有较高参考价值。1. 当用户说“我被辞退了”为什么对话管理比模型选型更决定法律助手的生死用户输入“我被公司辞退了怎么办”时一个裸调 DeepSeek 接口的助手会立刻生成一篇四百字的劳动法科普但真实法律咨询根本不是这样运转的。这个用户可能入职十年可能试用期刚三天可能手里有录音和微信记录也可能连公司全称都说不清楚。事实不完整的时候回答写得越专业误导概率越高。标题里“对话管理框架 多轮上下文理解 精准应答生成”这条主线本质上说的是先有能力记住用户说过什么、判断还缺什么、决定何时追问、何时检索、何时给结论再谈模型生成。做这套方案时我在最初版本里也走过直接堆 prompt 的弯路后来才明白那 554 页的厚度主要花在了状态迁移和边界条件上。这篇笔记沿着对话管理设计、DeepSeek API 接入、生成参数、落地坑点逐层拆解适合正在做法律问答、政务咨询、智能客服这类高价值多轮场景的团队参考。2. 法律咨询为什么不能裸调大模型对话管理框架解决的三件事2.1 法律咨询的多轮不是客服闲聊而是“事实拼图”商品客服的多轮对话目标是快速定位订单号、问题类型和售后诉求三个槽位填满就能转人工。法律咨询的逻辑完全不同用户作为非专业人士不知道律师判断一个纠纷需要哪些信息。他说“公司让我走人”背后缺的可能是入职时间、劳动合同签订情况、辞退是否书面通知、解除理由是裁员还是过失、离职前十二个月平均工资、是否已经申请仲裁。这一串事实不会出现在第一句话里要靠系统在对话中一轮一轮“钓”出来。我一直在用的做法是针对劳动争议、合同纠纷、婚姻家事、交通事故这四类最高频的案件各预定义一份关键事实槽位清单每轮用户输入先做一次槽位匹配与更新只有关键槽位满足最低集合时才允许进入“检索 生成答复”阶段。这套机制保证了用户把事实藏到第几句状态层都能跨轮拼起来。追问节奏也要单独设计一次性把缺失槽位全部问完用户大概率直接流失。我的排序原则是决策优先级优先影响结论方向的槽位先问。比如劳动争议里“有没有签劳动合同”直接决定双倍工资条款是否适用就要排在“加班费具体金额”之前。2.2 对话管理框架的三大件状态追踪、策略决策、生成出口不管用什么框架名字一套能落地的多轮对话管理都有三个明确组件。第一个是对话状态追踪Dialog State TrackingDST维护“当前已知事实”的结构化表示。传统方案里叫槽位填充在 LLM 方案里可以做成一个结构化 JSON 状态对象。我更推荐把槽位抽取的主要逻辑放在规则层正则和关键词规则先扫一遍能确定的实体拿不准的再请 DeepSeek 做二次确认。纯粹让大模型自由发挥来更新状态实体错配率会高到影响结论这个后面避坑章会专门讲。第二个是对话策略模块输入是状态输出是下一步动作追问缺失槽位、触发法律条文检索、直接生成答复、或者建议转人工律师。这个模块我用确定性规则而不是模型决策。法律咨询的业务责任太重系统为什么问这个问题、为什么给这个结论每一步都要可追溯。如果整个决策链都是黑匣子出了问题没法追责也没法跟业务方解释。第三个是生成出口NLG在这个方案里就是 DeepSeek它把结构化状态翻译成自然、温和、有法条引用的答复。生成出口必须能看到完整状态而不能只看当前这一句话这正是标题里“上下文理解”的真正落点。2.3 LLM、Agent、对话管理框架的区别DeepSeek 负责哪一层很多团队会问DeepSeek 那么强我写一段 system prompt 让它扮演律师还要不要对话管理这个问题恰好把 LLM 和 Agent 这两个概念分开了。LLM 就是 DeepSeek 这类大语言模型本身做的事情是根据输入上下文预测下一个 token它不保留记忆每次请求都是无状态的也不会主动去查数据库除非通过工具调用接口被外部代码驱动。Agent 则是在 LLM 外面包上记忆、规划和工具调用循环让它能拆解任务、调用检索、观察结果再继续。对话管理框架是更贴近业务的一层它规定了 Agent 每一步能做什么、不能做什么、状态往哪里迁移。一句话总结DeepSeek 负责“想”对话管理框架负责“管”。在标题这套方案里DeepSeek 承担两块职责。第一块是理解把“公司让我走人”解析为劳动纠纷、单方解除的意图输出槽位候选值第二块是生成追问话术、法条摘要、最终结论的规范化表述。对话管理框架负责决定这一轮该不该调 DeepSeek、拿什么上下文调、结果拿去干什么。把 DeepSeek 当受约束的执行器而不是自由的决策器这是从 Agent 式自由对话收敛到可控多轮系统的关键选择。对比一下不同方案在几个维度上的表现维度裸 LLM ChatReAct Agent对话管理框架 LLM多轮状态保持靠拼历史消息易遗忘靠 memory深度有限显式结构槽位跨轮不丢追问逻辑模型自由发挥模型自主决定不稳定规则决策可审计检索触发无看模型是否主动调工具槽位齐整时才触发责任追溯不可查部分可查全链路可复现选择 DeepSeek 作为生成核心理由也很直接中英文混用的法律术语加用户口语场景下表现均衡长上下文窗口给的宽松API 又是 OpenAI 兼容形态和自研对话管理框架对接的工程量很小。生成参数怎么设放到第四章细讲。3. 搭一个能跑的基线状态槽位 追问规则 DeepSeek API 组装3.1 最小可运行系统的五个模块搭第一版时不用把系统设计得太复杂五个模块就够了。一是入口预处理做用户消息的清洗和意图粗分类二是状态更新器把新事实写进槽位三是策略引擎根据槽位完整度判断下一步动作四是 RAG 检索器从法律知识库召回相关法条五是生成器调用 DeepSeek API 输出答复。一次完整对话的流程是这样用户回答追问后状态更新器解析槽位并回填策略引擎检查是否满足生成条件。不满足就再抛一个追问话术满足了就触发 RAG 检索把对话历史、槽位摘要、检索条文拼成 messages 发给 DeepSeek最后校验输出里的引用来源是否真实存在于知识库通过才返回用户。这个流程最核心的一点是检索和生成之间隔着一个策略判断而不是每轮都检索。后面讲 RAG 多轮对话怎么设计时还会再强调。3.2 槽位模型用 dataclass 把案件事实结构定死from dataclasses import dataclass, field from typing import Optional, Dict, List from enum import Enum class CaseType(str, Enum): LABOR 劳动争议 CONTRACT 合同纠纷 FAMILY 婚姻家事 TRAFFIC 交通事故 dataclass class CaseFacts: 法律咨询核心事实槽位显式定义杜绝命名漂移 case_type: Optional[CaseType] None # 用户身份在劳动争议里是劳动者还是用人单位 user_role: Optional[str] None # 对方主体公司全称或个人姓名 opposite_party: str # 关键时间点入职日、辞退日、合同到期日等 key_dates: Dict[str, str] field(default_factorydict) # 书面证据列表合同、工资流水、解除通知书等 evidence_list: List[str] field(default_factorylist) # 用户最终诉求要求赔偿金 / 恢复劳动关系 / 离职证明 demand: str # 压缩后的事实摘要供 LLM 上下文使用 facts_summary: str def is_ready(self, required: List[str]) - bool: 检查必填槽位是否齐全 mapping { role: lambda: self.user_role is not None, party: lambda: len(self.opposite_party) 0, date: lambda: len(self.key_dates) 0, evidence: lambda: len(self.evidence_list) 0, demand: lambda: len(self.demand) 0, } return all(mapping[item]() for item in required)这段代码的价值有三个。字段名就是槽位的唯一标识不会出现同一个事实在三个地方叫不同名字的情况is_ready()把“能不能生成答复”收敛成一个函数策略引擎直接调它做判断facts_summary字段专门存跨轮摘要第四节组装 DeepSeek 上下文时要反复用到。槽位设计上要强调用枚举而不是自由字符串CaseType把案件类型卡死在四个类别里后续意图分类和策略路由都基于这个枚举逻辑很干净。边界场景像合同纠纷和劳动争议交叉时就让状态更新器算置信度拿不准的交给 DeepSeek 做二次确认。3.3 状态更新与追问策略规则层做判断LLM 做补充状态更新的核心问题是把用户自然语言变成结构化槽位值。第一版建议用“规则抽取 LLM 兜底”的双通道不要一上来就让大模型接管全部槽位解析。import re LABOR_PATTERNS { evidence: [ r劳动合同, r劳务合同, r工资流水, r考勤记录, r解除通知, r录音, r聊天记录, r工作群 ], demand: [ r赔偿, r补偿, r恢复劳动关系, r离职证明, r加班费 ], } def extract_slots(user_input: str, facts: CaseFacts) - CaseFacts: 从原始输入抽取槽位并更新 facts 对象纯函数风格便于测试 for key, patterns in LABOR_PATTERNS.items(): for pat in patterns: if re.search(pat, user_input): if key evidence and pat not in facts.evidence_list: facts.evidence_list.append(pat) elif key demand: # 同一句话可能提到多个诉求这里先记录最高优先级的一个 if 赔偿 in pat or 补偿 in pat: facts.demand 要求经济赔偿/补偿 elif 恢复 in pat: facts.demand 要求恢复劳动关系 break return facts规则抽取的优势是零成本、完全可控但覆盖不了“他们不让我上班了但工资照发这算啥”这种隐含表态。所以规则只负责确定性的槽位其余未知槽位会在策略引擎里打一个“未完全确认”标记让 DeepSeek 在下一轮生成追问话术时顺手补抽一次。这样拆的好处是DeepSeek 抽错槽位影响被限制在二次确认阶段不会直接污染主状态。追问策略上用最短依赖路径规则每轮只追问一个对结论影响最大的缺失槽位。优先级表来自业务经验比如劳动争议里缺失 user_role 和 key_dates 时优先追问日期因为角色通常能从用户话里推出来日期漏了就很难追。追问话术也要带个性化前缀“您提到公司上个月通知您离职能补充一下正式入职时间吗这个时间点直接关系到经济补偿的年限计算。”这比干巴巴的“请补充入职时间”体验好得多。3.4 调 DeepSeek API组装多轮上下文的 OpenAI 兼容写法from openai import OpenAI client OpenAI( api_keyYOUR_DEEPSEEK_API_KEY, base_urlhttps://api.deepseek.com/v1 # DeepSeek 开放平台的 OpenAI 兼容端点 ) def build_messages(facts: CaseFacts, history: List[dict], retrieved_laws: str) - List[dict]: 把槽位摘要、最近 N 轮历史、法条检索结果组装成 messages system_prompt ( 你是一名法律咨询助手。回答必须基于用户提供的案件事实和检索条文。\n 规则\n 1. 不能编造法条检索结果里没有的内容不能引用。\n 2. 给出的结论先用口语解释再附法条依据。\n 3. 信息不足时只指出缺失信息不要臆测。\n f当前已知案件事实{facts.facts_summary} ) messages [{role: system, content: system_prompt}] messages.extend(history[-6:]) # 滑窗保留最近 6 轮原始对话 messages.append({ role: user, content: f参考法条\n{retrieved_laws}\n\n请根据以上事实和法条回答用户最新问题。 }) return messages def generate_answer(facts: CaseFacts, history: List[dict], retrieved_laws: str) - str: messages build_messages(facts, history, retrieved_laws) resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.2, top_p0.7, max_tokens1500, streamFalse ) return resp.choices[0].message.content这里几个参数值得重点说明。滑窗只取最后 6 轮对话是因为 DeepSeek 上下文窗口虽大但法律咨询里有大量来回确认的废话轮次全塞进去既费 token又容易让模型被无关表述带偏。槽位摘要facts_summary承载被丢掉的早期事实这才能做到不被窗口裁剪影响结论一致性。temperature 设 0.2法律回答要求对错分明0.1 到 0.3 是安全区间再往上就开始出现“可能、也许、也有观点认为”这类没有信息量的措辞。top_p 固定在 0.7和 temperature 配合收窄候选词域。max_tokens给 1500 是因为中文法律答复正常在 800 到 1200 字留出引用来源和解释的余量。3.5 法律 RAG 多轮对话怎么设计切片入库、检索时机、混合召回法律 RAG 和通用知识问答的差别在入库阶段就开始了。法律文本不能按固定字符数切块会产生一个条文被切断、嵌入语义落在两半的情况导致检索命中条号但内容对不上。我的做法是直接按“条”切分把条号作为元信息保留def split_law_doc(law_text: str, law_name: str) - List[dict]: 按「条」切分法律条文保留法名和条号作为结构化字段 chunks [] pattern re.compile(r第[一二三四五六七八九十百零]条) matches list(pattern.finditer(law_text)) for i, m in enumerate(matches): end matches[i 1].start() if i 1 len(matches) else len(law_text) article_no m.group().strip(第条) content law_text[m.end():end].strip() chunks.append({law: law_name, article: article_no, text: content}) return chunks检索时机上不要在用户每轮输入都检索多轮对话里大量轮次是确认信息、纠正口误这些轮次检索完全是浪费。把检索动作绑定在策略引擎的“生成答复”节点上并且用facts.facts_summary而不是用户原始消息做查询。原因很直接用户第 4 轮说“对我就是那个意思”单独拿去向量检索什么也查不到拼上槽位摘要“2022 年入职2024 年 10 月被公司以优化为由辞退”检索质量立刻不一样。混合召回也是一个值得加的增强条号和法名先走关键词精确匹配语义向量召回排在后面因为用户经常会说“劳动法”而正确法名是“劳动合同法”关键词召回能抓住这种拼写相关。向量库选型上bge-m3 和 text2vec 系列在法律文本的中文表现都够用量大之后优先考虑带 HNSW 索引的库召回延迟能压到百毫秒量级。4. 精准应答生成的三个关键配置上下文不是越长越好4.1 系统提示词的三层结构角色约束、行为边界、输出格式法律生成的系统提示词不能当作文写要当规则写。经过多版调优我沉淀下来一个三段式模板稳定性和可维护性都不错。你是「XX法律智能助手」的应答引擎。 一、角色约束你的用户是法律素养一般的普通民众回答要用口语化、 分步骤的方式解释专业术语出现时要紧跟一句大白话解释。 二、行为约束 1. 只能引用对话中提供的【参考法条】不得使用外部记忆中的法律条文。 2. 如果【参考法条】无法支撑结论直接说明为什么不能依据该条回答。 3. 涉及金额、期限、程序节点的表述必须精确到条号禁止使用“大概”“可能涉及”等模糊措辞。 4. 对话中已有的案件事实以【当前已知事实】为准不得复用已被用户推翻的说法。 三、输出格式仅要求完整答复时启用 第一段结论50 字以内。 第二段事实依据结合实际已确认事实。 第三段法条引用按《法》第X条逐条列出。 第四段下一步建议包含风险提示。提示词的三层作用各不相同。角色约束解决的是语言风格问题防止回复过于生硬或过于学术行为约束里的四条是法律助手的生命线分别压住编造法条、硬套法条、模糊表述和内部矛盾四个风险输出格式约束让你能在代码里可靠地做后处理解析。这里有一个经验提示词总长度控制在 800 到 900 字以内规则超过十条模型会选择性失明更细的约束应该放到外围校验代码里去做而不是在提示词里堆砌。行为约束第四条“不得复用已被推翻的说法”要和对话管理框架里的槽位版本控制配合才成立这一点第五章有详述。4.2 生成参数配置法律场景的确定性优先法律回答不追求文采追求结论和引用都站得住。围绕生成参数整理了一个可以直接照抄的取值表参数推荐取值取值理由翻车表现temperature0.1 到 0.3输出贴近源事实避免无意义发散调到 0.7 以上出现“一般建议”“可酌情考虑”等骑墙措辞top_p0.6 到 0.7配合 temperature 收窄候选词域单独拉到 0.95 后条号周边出现多余语气词max_tokens1200 到 2000法律答复通常 800 到 1500 字设小后正文被截断引用来源丢在末尾presence_penalty0法条引用需要原样重复不能做去重惩罚设为正数后模型批量改写法条文本校验必挂temperature 和 top_p 是两套分布干预机制建议固定 top_p 去调 temperature不要同时猛调。实际调法是用 0.3 温度跑一遍评估集如果幻觉偏高就降到 0.1如果重复病句明显就回到 0.2。至于“temperature 大于零可能导致随机”的纠结点经验是 0.2 附近完全不会出现明显不稳定反而回避了全零温度带来的机械重复问题。参数调优不是玄学固定评估集跑完对比再上你的版本。4.3 多轮上下文裁剪事实进摘要语气进滑窗多轮上下文最常见的错误是把整段聊天记录全塞进 messages。DeepSeek 上下文窗口再大也会有三个问题token 成本随轮次线性上涨模型注意力被早期废话稀释直接切头又会丢关键事实。我的标准做法是双通道并存滑窗保留最近 6 轮原始对话用于语气连贯结构化的facts_summary承载全部已确认事实两者并行作为上下文输入。def roll_summary(facts: CaseFacts, new_utterance: str) - str: 每轮对话后调用抽取增量事实更新压缩摘要 extracted extract_slots(new_utterance, facts) if extracted.key_dates: facts.key_dates.update(extracted.key_dates) if extracted.evidence_list: # 用集合去重避免同一证据重复入摘要 facts.evidence_list list(set(facts.evidence_list extracted.evidence_list)) summary_items [] if facts.key_dates.get(hire_date): summary_items.append(f入职时间{facts.key_dates[hire_date]}) if facts.key_dates.get(termination_date): summary_items.append(f辞退时间{facts.key_dates[termination_date]}) if facts.evidence_list: summary_items.append(f已举证{、.join(facts.evidence_list)}) if facts.demand: summary_items.append(f用户诉求{facts.demand}) facts.facts_summary .join(summary_items) return facts.facts_summary这里的关键限制是摘要里只放对法律结论有影响的事实维度时间、主体、证据、诉求。用户情绪表达比如“我非常生气”“公司太欺负人了”不进摘要它不属于事实槽位。这样跑下来20 轮对话能压缩到 100 字以内的结构化事实即使 LLM 输入滑窗只保留 6 轮结论依然前后一致。上下文理解能力就是通过这套机制落地的而不是靠模型自己消化长篇聊天记录。5. 多轮法律咨询落地避坑五个我踩实的坑这个项目最容易翻车的位置按出现频次排序分别是工具调用协议、上下文超长、法条时效性幻觉、槽位被覆盖、追问策略太刚。下面每一条按现象、原因、解决展开都是线上环境真实踩过的。5.1 “messages tool calls need immediate results”报错工具调用结果必须紧跟原消息现象对话跑了几轮之后RAG 检索返回结果程序把检索结果插入消息列表再调 DeepSeek API直接收到一条报错提示 tool calls 需要立即返回结果。用户侧表现为答不上来日志侧是一条 400 协议错误。原因DeepSeek 的 OpenAI 兼容工具调用遵循一条严格协议当模型返回带tool_calls的 assistant 消息后消息列表中该消息的下一条必须是roletool的结果消息中间不能再夹任何 user 或 assistant 消息。多轮对话框架里常见的失误是在组装历史消息时把上一轮的检索结果拼到了历史列表的靠前位置导致 assistant 的 tool_call 消息和对应的 tool 消息之间隔着其他轮次内容协议层直接判定非法。解决把工具调用结果和原消息打包加入 messages顺序强制为 assistant 消息在前、tool 结果紧跟在后再追加用户新输入。if assistant_msg.tool_calls: # 先追加带 tool_calls 的 assistant 消息 messages.append(assistant_msg) for tool_call in assistant_msg.tool_calls: messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(retrieved_result, ensure_asciiFalse) }) # 此处不能插入任何 user/assistant 消息否则协议报错 messages.append({role: user, content: user_input})这条顺序一旦颠倒必炸。我的习惯是在组装函数里写一个断言加完 tool 消息后检查 messages[-1][role] tool不满足直接抛异常宁可在开发期暴露问题也不要在线上让用户等一个永远不来的回复。5.2 检索结果把上下文撑爆API 直接超长报错现象RAG 一次召回了 5 篇判决书每篇 3000 字拼接后直接超过模型上下文限制API 返回长度超限整个轮次失败。原因法律原文动辄几百字到几千字向量库 top_k 设置过大又没做切片和截断半个上下文窗口被同一条检索结果吃掉。另一个隐蔽问题是没有对拼接后的retrieved_laws做长度预算模型输入和输出共用上下文空间输入占满了输出就没有足够位置。解决三级收敛。第一级在入库阶段按“条”切分已经能压掉大部分冗余。第二级把 top_k 从 5 降到 3并且给拼接后的 reference 文本设置硬上限。第三级超过 1200 字时用抽取式摘要把每条结果压缩成一句带条号的关键句而不是硬塞原文。实际体感是法律答复不需要整本法条用户场景对应的几个款目足够了把整本返回反而是噪声。5.3 新旧法条引用幻觉模型会自动补充一个“看起来合理”的法条现象系统在回答中引用了已经废止的法律或者张冠李戴的条号比如把民法典第 502 条的内容说成第 503 条。普通用户分辨不出来但如果对面是实务律师信任感直接归零这个产品就废了。原因LLM 的参数记忆停留在训练截止日期新颁布的司法解释它没学过旧法废止它也未必知道。当 RAG 检索结果无法支持当前问题时模型不会承认不知道它会用参数记忆里的近似知识补一个合理的答案这就是幻觉的根源。解决做三层拦截少一层都守不住。第一层RAG 知识库上线前做一轮现行有效性清洗把废止法条物理移出向量库彻底断绝模型“从库里捞到旧法”的可能。第二层提示词里显式声明“只能引用参考法条中的内容”这一步把幻觉归因到模型可控范围内。第三层生成之后做代码校验解析输出中的《法》第X条和本次检索结果对比不一致就强制重答或者直接丢弃。这个方法组合用下来引用幻觉率压到了可忽略的水平代价是多一次解析和重试。5.4 用户中途改口槽位被覆盖导致前后矛盾现象用户第一轮说“公司以试用期不合格辞退我”系统确认了辞退理由为考核不合格。第 7 轮用户又说“其实他们从没跟我签过劳动合同”。状态层无脑覆盖之后后面的赔偿计算走了双倍工资路线和上一轮“试用期辞退是否合法”的答复结论直接打架。原因无差别槽位覆盖造成的状况。多轮对话里的“当前陈述”和“历史确认事实”没有分开存储新来的表述把旧值覆盖掉系统失去了发现矛盾的机会。解决给每个槽位加版本和来源轮次新值进来先和旧值比对冲突时进入人工确认模式而不是静默覆盖。dataclass class SlotValue: value: str round_no: int # 来源轮次用于排查和回溯 confirmed: bool False # 是否已经过用户确认真实性 def update_slot(facts: dict, slot: str, new_val: str, round_no: int) - dict: 槽位更新冲突值不直接覆盖先进入二次确认 old facts.get(slot) if old is not None and old.value ! new_val and old.confirmed: return { need_confirm: True, question: f您前面提到是{old.value}这次说的是{new_val}请确认哪个是准确的 } facts[slot] SlotValue(valuenew_val, round_noround_no, confirmedFalse) return {need_confirm: False}这种做法的代价是多一轮对话但避免了结论前后打脸。对法律场景来说用户大多不会反感这种谨慎确认反而会觉得系统真的在跟踪前面说过的话。5.5 追问策略太刚用户明确要结论系统还在死磕槽位现象系统检测到缺槽位连续追问入职时间和工资流水。用户回一句“我不想再回答了你就按现有情况说大概能赔多少”策略引擎依然按照规则返回“信息不完整无法回答”。用户直接流失。原因策略规则把槽位补全当成了终极目标而不是把解决问题当目标。部分用户的核心诉求不是精确计算赔偿金而是先要一个大方向比如“这事我占不占理”“要不要去仲裁”。规则引擎缺少一个低槽位覆盖率下的兜底出口。解决给策略引擎增加“最小结论模式”分支。当用户明确表达“先给结论”的意图且已确认槽位数超过生成必需项的 50% 时直接走生成通道但在生成提示词中明确标注“以下回答基于不完整事实部分结论存在不确定性”并把缺失事实列为列表附在回答末尾。更进一步的做法是这条分支同时展示转人工律师的入口信息不足以支撑结论时不硬撑。对机器人来说承认不确定性不是能力弱而是对用户负责。6. 进阶把评估闭环搭起来让多轮对话越跑越准6.1 考虑本地部署时量化取舍要更谨慎对话系统跑通后数据合规往往是挡在最前面的一道门槛。法律咨询里用户会报出身份证号、工资流水金额、公司全称很多政企项目要求这些数据不能出内网。常见做法是把 DeepSeek 的蒸馏模型部署到本地用 vLLM 拉起一个 OpenAI 兼容服务前面代码里的base_url从官方端点换成http://localhost:8000/v1其余逻辑基本零改动。值得提醒的是量化部署会损害模型对条号的记忆能力这一点会在长回答里暴露得很明显。所以本地部署方案里我会把 RAG 的权重压得更重让模型尽量做基于检索的复述和解释而不是从参数里回忆条文。6.2 用 DeepSeek 评 DeepSeek五维自动评估把回归风险拦在合入前对话系统的改动风险大多不在单轮回答而在多轮一致性和追问效率。我的做法是建一个 100 条脱敏真实对话的评估集把标准答案和模型输出拼进一个结构化评估提示词交给 DeepSeek 从五个维度打分事实准确性、法条引用一致性、多轮一致性、追问效率、语气合规性。评估结果和人工标注的相关性非常高已经可以在开发流程里当拦截线用。每次改槽位规则、系统提示词或 RAG 切片逻辑就跑一遍评估集均分下跌超过一个阈值就不允许合入主分支。这个方法让我在一轮改动里及时抓住过“槽位版本控制导致多轮一致性下降”的回退问题省下的返工时间远超构建评估集的成本。这套评估集也承担着知识库更新后的回归验证职责。法律是动态变化的每次有新的司法解释或者地方规定生效知识库更新之后先跑评估重点看法条引用一致性这个维度是否发生了漂移。我现在每个交付版本都强制带上这一步最终从源头上把上线前夜才暴露问题的概率压到最低。希望这套方案里的状态设计、参数取值和避坑记录能帮你少走几次弯路。希望帮到你。本文还有配套的精品资源点击获取