简介：一套面向法律科技产品经理、NLP算法工程师与方案架构师的DeepSeek法律智能助手对话系统构建方案，共554页、50个大章节，完整梳理了从需求拆解到模型落地的全过程。方案以DeepSeek对话管理框架为主线，围绕法律多轮咨询场景，重点解决上下文理解、专业词汇库构建、法律实体与意图识别等关键技术难点，并覆盖模型训练、微调、蒸馏部署与轻量化落地的完整链路。内容涵盖法律实体识别模型选型、数据标注规范、训练参数设置、微调与蒸馏等多个实操环节，既便于系统化学习，也可作为项目方案模板复用。资源为单个PDF文档，大小14.38MB，目录层级清晰，支持章节跳转与书签大纲快速定位，文件内容图表与文字显示完整。目前已有108人学习下载，对正在规划法律领域对话系统或希望复用DeepSeek技术栈的读者具有较高参考价值。
1. 当用户说“我被辞退了”：为什么对话管理比模型选型更决定法律助手的生死
用户输入“我被公司辞退了，怎么办”时，一个裸调 DeepSeek 接口的助手会立刻生成一篇四百字的劳动法科普，但真实法律咨询根本不是这样运转的。这个用户可能入职十年，可能试用期刚三天，可能手里有录音和微信记录，也可能连公司全称都说不清楚。事实不完整的时候，回答写得越专业，误导概率越高。标题里“对话管理框架 + 多轮上下文理解 + 精准应答生成”这条主线，本质上说的是：先有能力记住用户说过什么、判断还缺什么、决定何时追问、何时检索、何时给结论，再谈模型生成。做这套方案时，我在最初版本里也走过直接堆 prompt 的弯路，后来才明白那 554 页的厚度主要花在了状态迁移和边界条件上。这篇笔记沿着对话管理设计、DeepSeek API 接入、生成参数、落地坑点逐层拆解，适合正在做法律问答、政务咨询、智能客服这类高价值多轮场景的团队参考。
2. 法律咨询为什么不能裸调大模型：对话管理框架解决的三件事
2.1 法律咨询的多轮不是客服闲聊，而是“事实拼图”
商品客服的多轮对话，目标是快速定位订单号、问题类型和售后诉求，三个槽位填满就能转人工。法律咨询的逻辑完全不同：用户作为非专业人士，不知道律师判断一个纠纷需要哪些信息。他说“公司让我走人”，背后缺的可能是入职时间、劳动合同签订情况、辞退是否书面通知、解除理由是裁员还是过失、离职前十二个月平均工资、是否已经申请仲裁。这一串事实不会出现在第一句话里，要靠系统在对话中一轮一轮“钓”出来。
我一直在用的做法是：针对劳动争议、合同纠纷、婚姻家事、交通事故这四类最高频的案件，各预定义一份关键事实槽位清单，每轮用户输入先做一次槽位匹配与更新，只有关键槽位满足最低集合时才允许进入“检索 + 生成答复”阶段。这套机制保证了用户把事实藏到第几句，状态层都能跨轮拼起来。追问节奏也要单独设计，一次性把缺失槽位全部问完，用户大概率直接流失。我的排序原则是决策优先级优先，影响结论方向的槽位先问。比如劳动争议里，“有没有签劳动合同”直接决定双倍工资条款是否适用，就要排在“加班费具体金额”之前。
2.2 对话管理框架的三大件：状态追踪、策略决策、生成出口
不管用什么框架名字，一套能落地的多轮对话管理都有三个明确组件。第一个是对话状态追踪（Dialog State Tracking，DST），维护“当前已知事实”的结构化表示。传统方案里叫槽位填充，在 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 Chat | ReAct 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_factory=dict) # 书面证据列表：合同、工资流水、解除通知书等 evidence_list: List[str] = field(default_factory=list) # 用户最终诉求：要求赔偿金 / 恢复劳动关系 / 离职证明 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_key="YOUR_DEEPSEEK_API_KEY", base_url="https://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( model="deepseek-chat", messages=messages, temperature=0.2, top_p=0.7, max_tokens=1500, stream=False ) 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 生成参数配置：法律场景的确定性优先
法律回答不追求文采，追求结论和引用都站得住。围绕生成参数，整理了一个可以直接照抄的取值表：
| 参数 | 推荐取值 | 取值理由 | 翻车表现 |
|---|---|---|---|
| temperature | 0.1 到 0.3 | 输出贴近源事实，避免无意义发散 | 调到 0.7 以上出现“一般建议”“可酌情考虑”等骑墙措辞 |
| top_p | 0.6 到 0.7 | 配合 temperature 收窄候选词域 | 单独拉到 0.95 后条号周边出现多余语气词 |
| max_tokens | 1200 到 2000 | 法律答复通常 800 到 1500 字 | 设小后正文被截断，引用来源丢在末尾 |
| presence_penalty | 0 | 法条引用需要原样重复，不能做去重惩罚 | 设为正数后模型批量改写法条文本，校验必挂 |
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 消息后，消息列表中该消息的下一条必须是role=tool的结果消息，中间不能再夹任何 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_ascii=False) }) # 此处不能插入任何 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(value=new_val, round_no=round_no, confirmed=False) 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 切片逻辑，就跑一遍评估集，均分下跌超过一个阈值就不允许合入主分支。这个方法让我在一轮改动里及时抓住过“槽位版本控制导致多轮一致性下降”的回退问题，省下的返工时间远超构建评估集的成本。
这套评估集也承担着知识库更新后的回归验证职责。法律是动态变化的，每次有新的司法解释或者地方规定生效，知识库更新之后先跑评估，重点看法条引用一致性这个维度是否发生了漂移。我现在每个交付版本都强制带上这一步，最终从源头上把上线前夜才暴露问题的概率压到最低。
希望这套方案里的状态设计、参数取值和避坑记录，能帮你少走几次弯路。希望帮到你。
本文还有配套的精品资源，点击获取
