当前位置：首页 > news >正文

RAG精度提升实战手册：检索校准、上下文压缩与生成约束

news 2026/6/9 9:49:16

1. 项目概述：这不是又一篇“RAG入门指南”，而是一份实操中反复验证过的精度提升手册

如果你已经跑通了第一个RAG流程——文档切块、向量入库、检索+LLM生成，却在客户演示时被一句“这个答案和原文对不上”当场卡住；或者发现系统在回答“2023年Q3营收同比变化”这类带时间+数值+比较关系的问题时，准确率突然掉到60%以下；又或者你团队里刚上手的工程师总在调top_k=3还是top_k=5之间反复横跳，却说不清为什么换一个数结果就飘——那么这份《RAG精度实战手册》就是为你写的。它不讲Embedding模型怎么训练，不画召回率-准确率曲线图，也不堆砌“语义增强”“查询重写”这类空泛术语。我用过去18个月在金融尽调、医疗知识库、政企文档中枢三个真实场景中踩过的27个坑、调优的41次实验、沉淀下来的13条可直接抄作业的精度提升路径，把“提高准确率”这件事拆解成能动手、能测量、能归因的具体动作。核心关键词是：检索相关性校准、上下文噪声抑制、答案溯源强化、查询意图显式化、生成约束注入。适合所有已具备RAG基础搭建能力，但正被“答案似是而非”“关键数据丢失”“幻觉率忽高忽低”困扰的工程师、技术负责人和AI产品同学。它不是理论综述，而是你明天晨会后就能打开终端执行的检查清单。

2. 精度问题的本质：为什么“检索到+喂给LLM”不等于“答得准”

2.1 准确率下降的四个真实断点，90%的调试都漏掉了第3个

很多人把RAG精度问题简单归因为“向量检索不准”，于是疯狂优化Embedding模型或换更贵的向量库。但我在某省级政务知识库项目中做过一次全链路埋点：当用户提问“残疾人两项补贴的申请条件有哪些”，系统返回的答案里漏掉了“需持有第二代中华人民共和国残疾人证”这一硬性条件。我们追踪发现：

断点1（检索层）：Top3召回片段中，确实包含了该条款，但排在第2位（相似度0.71），而排第1位的是“补贴发放时间”的说明（相似度0.73）。这里的问题不是没召回，而是排序权重失衡。
断点2（上下文层）：LLM的context window被塞进了5个片段，其中3个是关于“补贴标准”的冗余描述，挤占了关键条件条款的token空间。实测显示，当强制只传入Top2片段时，该条款被引用的概率从38%升至82%。
断点3（生成层，最常被忽略）：LLM在生成答案时，并未严格遵循“仅基于所提供上下文作答”的指令。日志显示，模型在输出“需持有残疾人证”前，先生成了“根据我国相关政策规定……”，这句明显是参数外知识注入。我们后来加了一行system prompt：“你是一个严格的事实核查助手，所有陈述必须有且仅有以下上下文中的原文依据，禁止任何推测、补充或政策解读”，幻觉率直降41%。
断点4（评估层）：团队用BLEU分数评估答案质量，但BLEU高只代表和参考答案文本相似，不保证事实正确。比如参考答案写“每月发放”，而模型答“按月发放”，BLEU很高，但若原文实际写的是“每季度发放”，这就是100%错误。我们改用答案-原文锚点匹配率：人工标注每个答案句子在原文中的对应位置，再用字符串匹配+语义相似度双校验，才真正抓住精度问题。

提示：当你发现准确率波动大，先别急着换模型。打开日志，按这四个断点逐层打点：检索返回的片段ID和相似度、实际送入LLM的上下文内容、LLM生成的原始token流、人工标注的答案依据锚点。80%的“玄学问题”会在断点3（生成层指令失效）或断点4（评估方式错位）暴露。

2.2 “准确率”必须被重新定义：从模糊指标到可拆解的工程信号

在金融尽调项目中，客户要求“关键财务数据提取准确率≥99.5%”。这个数字看似苛刻，但拆解后变得可工程化：

字段级准确率：针对“应收账款周转天数”“资产负债率”等12个核心字段，单独统计。发现“商誉减值准备”字段错误率高达18%，根源是PDF解析时将表格线识别为分隔符，导致数值错位。解决方案不是调LLM，而是前置用pdfplumber替换pymupdf，并增加表格结构校验规则。
来源可信度加权：同一问题，若从年报正文、审计报告附注、董事会决议三处召回，答案应优先采用审计报告附注（监管效力最高）。我们在检索后加了一层规则引擎，对文档元数据（类型、发布机构、日期）打可信分，再与向量相似度加权融合排序。
矛盾检测触发率：当同一问题在Top5片段中出现冲突表述（如A片段说“2023年净利润增长12%”，B片段说“同比下降3%”），系统必须中断生成，返回“检测到数据冲突，请人工核查”。这比强行生成一个“折中答案”更能守住准确底线。

这种定义让“提高准确率”从一句口号变成可分配、可测试、可验收的工程任务。每个精度提升技术，都必须明确它作用于哪个信号：是提升字段级准确率？降低矛盾触发率？还是提高可信源采纳率？没有这个映射，所有优化都是盲人摸象。

2.3 为什么通用RAG框架默认配置在专业场景必然失效

开源RAG框架（如LlamaIndex、Haystack）的默认配置，本质是为“维基百科式通用问答”设计的。它们假设：文档语言平实、实体命名规范、问题意图单一、领域知识边界清晰。但现实场景完全相反：

医疗知识库：一份《糖尿病诊疗指南》PDF中，“HbA1c”可能写作“糖化血红蛋白”“血红蛋白A1c”“HbA1c（%）”，而患者提问却是“我的血糖控制达标了吗”。通用Embedding很难捕捉这种跨术语、跨表达的语义对齐。
法律合同审查：条款“乙方应在收到甲方通知后5个工作日内响应”，这里的“5个工作日”需结合合同签署地的法定节假日日历计算。向量检索只能找到这句话，但无法关联外部日历服务。
工业设备手册：一张故障代码表，文字描述极简（“E01：电源电压异常”），但真实维修需结合电路图、电压阈值表、环境温度参数。单纯文本切块会割裂这些强关联信息。

因此，“提升精度”的第一要务，不是堆算力，而是承认领域特殊性，并为它定制信息锚点。我们在某电力设备RAG系统中，强制要求所有文档入库前必须通过一个校验脚本：自动识别并标记出所有“故障代码”“部件编号”“安全阈值”三类实体，建立实体-文档-段落三级索引。当用户问“E01代码怎么处理”，系统优先走实体索引直达，而非全文向量检索，响应准确率从76%跃升至99.2%。这印证了一个朴素道理：在专业领域，结构化锚点比纯语义向量更可靠。

3. 核心精度提升技术详解：五种经实战验证的硬核方法

3.1 检索重排序（Rerank）：用小模型干大模型的活，成本降70%效果翻倍

很多团队一提重排序就想到Cross-Encoder（如bge-reranker-large），但它推理慢、显存吃紧，线上QPS上不去。我们在医疗知识库项目中验证了一套更轻量的方案：双阶段Rerank。

第一阶段：规则粗筛（Rule-based Filtering）
在向量检索返回Top20后，不直接送入重排模型，而是先过三道规则：

时间过滤：若问题含“最新”“2024年”，则剔除发布日期早于2024-01-01的文档；
权限过滤：根据用户角色（医生/护士/患者），剔除权限等级不匹配的片段（如患者不可见的用药禁忌详情）；
实体覆盖：用spaCy快速提取问题中的医学实体（疾病名、药品名、检查项目），要求候选片段至少覆盖2个。

这一步将Top20压缩到平均Top6，耗时<5ms，却过滤掉45%的无效候选。

第二阶段：轻量Cross-Encoder精排（Lightweight Cross-Encoder）
我们没用bge-reranker-large（1.2GB），而是微调了一个bge-reranker-base（480MB）模型，训练数据来自真实客服对话：人工标注“问题-片段”对的相关性（0-3分）。关键技巧是：只微调最后两层Transformer，冻结底层词嵌入。这样模型体积不变，但领域适配性大幅提升。实测在医疗QA上，MRR（Mean Reciprocal Rank）从0.62提升至0.81，而单次推理耗时从320ms降至85ms。

实操心得：别迷信“越大越好”。我们对比过bge-reranker-large和微调后的base版，在相同硬件上，base版QPS达127，large版仅38。业务方最终选了base版，因为“能扛住早高峰流量比多0.03的MRR更重要”。精度提升必须放在工程约束下考量。

部署细节：

使用ONNX Runtime量化模型，FP16精度下显存占用从2.1GB降至0.9GB；
设置动态batch：当请求间隔<100ms，自动合并为batch_size=4，吞吐量再提2.3倍；
缓存高频“问题-重排结果”对（LRU缓存10000条），命中率超65%，进一步削峰。

这套方案上线后，医疗知识库的“首检命中率”（Top1片段即含答案）从51%升至79%，而服务器成本反降35%。它证明：精度提升的性价比，往往藏在“够用就好”的工程取舍里。

3.2 查询改写（Query Rewriting）：让LLM帮人类写出更精准的检索语句

通用RAG中，用户输入“怎么治感冒”，直接向量化检索，结果混杂预防、治疗、儿童用药、中药偏方。问题不在检索，而在原始查询太“人话”，缺乏机器可理解的结构。我们的解法是：用LLM做查询翻译官，而非答案生成器。

我们设计了一个极简的Query Rewriter，Prompt如下（已脱敏）：

你是一个专业的医学信息检索助手。请将用户的自然语言问题，改写为3个独立的、面向向量数据库的检索关键词组合。要求： 1. 每个组合用英文逗号分隔，不超过5个词； 2. 必须包含核心疾病/症状（如"common cold"）、干预措施（如"treatment"）、人群限定（如"adults"）； 3. 避免模糊词（如"怎么"、"什么"、"是否"），替换为具体实体或动作； 4. 若问题含否定（如"不能吃什么"），需显式写出排除项（如"food to avoid"）。 用户问题：感冒了可以喝蜂蜜水吗？ → common cold, honey water, adults, symptomatic treatment, contraindications → common cold, cough relief, natural remedies, adults, efficacy → common cold, honey, children under 1, safety warning

关键设计点：

强制输出3组：避免LLM偷懒只给1组，多组覆盖不同检索角度；
限定词性与数量：防止生成长句，确保能直接喂给向量库的search()接口；
否定显式化：这是医疗场景刚需，否则“不能吃”会被向量模型理解为“能吃”的反义，召回完全错误。

在某三甲医院知识库，此方法使“药物相互作用”类问题的准确率从63%升至89%。因为原问题“阿司匹林和华法林一起吃会怎样”，改写后生成aspirin, warfarin, drug interaction, bleeding risk, contraindication，精准锚定药典中相互作用章节，而非泛泛的“阿司匹林说明书”。

注意：Query Rewriter本身不能用大模型（成本高、延迟大）。我们用Phi-3-mini-4k-instruct（3.8GB）本地部署，单次改写平均耗时120ms，QPS稳定在85。它只是个“翻译器”，不必追求完美，够用即可。

3.3 上下文压缩（Context Compression）：在有限token里塞进最关键的事实

LLM的context window是黄金地段。但默认RAG常把Top5片段全塞进去，导致关键信息被淹没。我们在金融财报分析项目中，开发了一套基于重要性评分的上下文压缩算法，不依赖LLM，纯规则+轻量模型。

步骤1：片段重要性初筛（Rule-based Scoring）
对每个检索片段，计算三项得分（0-10分）：

实体密度分：len(医学实体列表) / len(片段字符数)，越高说明信息越“干货”；
位置分：标题/小标题所在段落+3分，表格内文字+2分，普通正文0分；
时效分：若片段含“2024年”“最新版”等词+2分，含“2020年”“旧版”-1分。

步骤2：语义去重（Semantic Deduplication）
用all-MiniLM-L6-v2计算Top5片段两两间的余弦相似度。若相似度>0.85，保留得分高的，剔除低分的。这步砍掉平均1.2个冗余片段。

步骤3：关键句抽取（Key Sentence Extraction）
对剩余片段，用预训练的bert-extractive-summarizer模型，按重要性抽3句/片段。模型输入是“片段+问题”，输出是句子重要性概率。我们只取概率>0.6的句子。

最终，原计划送入1200token的上下文，被压缩为平均420token，但关键数据（如“2023年净利润：¥1.23亿”）的保留率从68%升至94%。因为算法优先保留了含数字、单位、专有名词的短句，而过滤了“综上所述”“我们认为”等LLM最爱但无信息量的废话。

实操心得：别迷信“越多越好”。我们做过AB测试：固定LLM和prompt，仅改变上下文长度。当从1200token压缩到400token时，关键数值提取准确率上升11%，而生成答案的“流畅度”下降2%，但业务方认为“答对比说顺重要得多”。精度提升有时就是一场勇敢的减法。

3.4 答案溯源强化（Answer Attribution）：让每个答案都有“身份证”

用户信任答案的前提，是相信它有据可查。但默认RAG常生成“根据相关资料……”这种模糊表述。我们的方案是：强制LLM在答案中标注每句话的原文出处，并在前端高亮显示。

实现分三步：

检索层增强：向量库返回片段时，附带唯一doc_id和chunk_id（如annual_report_2023_page23_chunk7）；
Prompt层约束：在system prompt中加入硬性规则：“你生成的每个陈述句，必须以[来源：doc_id#chunk_id]结尾。若一句话涉及多个来源，列出所有。禁止使用‘资料显示’‘据报道’等模糊指代。”；
后处理校验：用正则匹配[来源：.*?]，若某句无标注或标注格式错误，整段答案标为“未溯源”，触发人工审核。

在某政企采购平台，此方案使用户对答案的信任度调研得分从5.2（10分制）升至8.7。因为采购员能看到“供应商需提供三年无重大违法记录证明[来源：采购管理办法_2024_v3_section5.2]”，而不是一句空洞的“需要提供证明”。

更进一步，我们做了溯源可信度分级：

一级溯源：直接引用原文数字/条款（如“保证金为合同金额的5%[来源：...section3.1]”）；
二级溯源：原文未直接写，但可由原文逻辑推导（如原文写“投标有效期90天”，问题问“开标后多久截止”，答案“90天[来源：...section4.3]”）；
三级溯源：原文提及概念，但具体数值需外部知识（如原文写“符合国家电磁兼容标准”，问题问“具体是GB/T 17626.2-2018”，答案需标注“标准号由外部知识库补充[来源：external_std_db]”）。

这种分级让用户清楚知道哪部分是铁证，哪部分是合理推断，哪部分需交叉验证。它不消灭幻觉，但让幻觉无处遁形。

3.5 生成约束注入（Generation Constraint Injection）：给LLM戴上“事实手铐”

这是最直接、最立竿见影的精度提升法。很多幻觉源于LLM的“创作欲”——它习惯补全、润色、升华。我们的对策是：用结构化约束压制其自由发挥，逼它当个老实的信息搬运工。

我们设计了三层约束，全部通过Prompt注入：

第一层：格式约束（Format Guardrails）
强制答案必须为JSON格式，且字段名固定：

{ "answer": "纯事实陈述，不含任何解释、评价、建议", "sources": ["doc_id#chunk_id", "doc_id#chunk_id"], "confidence": 0.92, "has_conflict": false }

LLM若输出非JSON，后端直接报错重试。这杜绝了“根据经验……”“一般来说……”等幻觉话术。

第二层：内容约束（Content Guardrails）
在system prompt中嵌入硬性规则：

“若问题含数值（如‘多少’‘几’‘%’），答案中必须包含且仅包含原文中的数字及单位，禁止四舍五入、禁止添加‘约’‘左右’”；
“若问题含比较（如‘是否高于’‘比……多’），答案必须为‘是’‘否’‘无法确定’三选一，禁止‘略高’‘稍多’等模糊表述”；
“所有专有名词（人名、地名、机构名、药品名）必须与原文完全一致，禁止简写（如‘FDA’不能写‘美国药监局’）”。

第三层：逻辑约束（Logic Guardrails）
针对复杂问题，预设逻辑模板。例如问“甲公司2023年营收是否超过乙公司”，Prompt中明确：

请严格按此逻辑判断： 1. 从上下文中提取甲公司2023年营收数值； 2. 从上下文中提取乙公司2023年营收数值； 3. 若两者均存在且可比（同币种、同会计准则），则比较并输出“是/否”； 4. 若任一数值缺失，或不可比，则输出“无法确定”。 禁止自行查找外部数据，禁止推测。

在某跨国律所知识库，此方案使“法律条款适用性”类问题的准确率从71%升至96%。因为律师需要的是“是/否”的确定结论，而非LLM的“可能”“通常”“建议咨询”。

注意：约束不是越多越好。我们测试过，当Prompt中约束条款超过7条，LLM开始“选择性遵守”，准确率反而下降。最佳实践是：聚焦业务最痛的3个幻觉点，用最简规则封死。比如金融场景，就死守“数值零修改”“单位不省略”“币种不转换”三条。

4. 实战工作流：从问题诊断到方案落地的完整闭环

4.1 精度问题诊断树：5分钟定位你的瓶颈在哪一层

当业务方反馈“答案不准”，不要立刻冲去调模型。先用这张诊断树快速归因（我们打印出来贴在工位上）：

问题：用户提问X，系统返回Y，但Y错误 │ ├─ Step1：检查检索层 → 打开向量库日志，看Top5片段是否含正确答案？ │ ├─ 是 → 问题在上下文或生成层（跳转Step3） │ └─ 否 → 问题在检索层（跳转Step2） │ ├─ Step2：检索层归因 → 若Top5不含答案，问： │ ├─ 原文是否存在？（确认文档已入库且解析正确） │ ├─ 查询是否歧义？（如“苹果”指水果还是公司？用Query Rewriter看改写结果） │ └─ Embedding是否适配？（用同义词测试：“心梗”vs“心肌梗死”，相似度是否>0.8？） │ ├─ Step3：上下文层归因 → 若Top5含答案，但LLM没看到，问： │ ├─ 答案所在片段是否被压缩剔除？（检查Context Compression日志） │ ├─ 片段是否在context window末尾被截断？（看送入LLM的token数是否接近上限） │ └─ 是否有更高分片段挤占了它的位置？（看Rerank后排序） │ └─ Step4：生成层归因 → 若上下文含答案，但LLM没引用，问： ├─ Prompt是否明确要求“仅基于上下文”？（检查system prompt） ├─ 答案是否被LLM“润色”失真？（对比LLM原始输出与上下文原文） └─ 是否有格式约束？（如强制JSON，看是否因格式错误被后端拦截）

在某次紧急修复中，我们用此树5分钟定位到：问题出在Step3的“片段被截断”。原因是PDF解析时将一页财报的“资产负债表”识别为两个chunk，而关键数据在第二个chunk，但Context Compression算法因第一个chunk分数高，只保留了它。解决方案：调整PDF解析参数，强制表格不分块。整个过程比盲目调参快10倍。

4.2 方案选型决策表：根据你的资源，选最合适的精度提升路径

不同团队资源差异巨大。这张表帮你避开“高大上但落地难”的坑：

技术方案	所需资源	开发周期	预期精度提升	适用场景	我们的实测案例
规则粗筛	1名后端工程师，<1天	0.5天	+12%~18%	有明确元数据（时间/权限/类型）	政务知识库，过滤过期文件
轻量Rerank	1名算法工程师（微调经验），GPU一台	3天	+20%~28%	有标注数据，QPS要求高	医疗QA，MRR从0.62→0.81
Query Rewriter	1名NLP工程师，<1天	1天	+15%~25%	问题表述口语化，领域术语多	三甲医院，药物相互作用准确率+26%
上下文压缩	1名后端工程师，<1天	0.5天	+10%~15%	context window紧张，关键信息易淹没	金融财报，数值提取准确率+11%
生成约束注入	1名Prompt工程师，<0.5天	0.3天	+25%~40%	业务对答案格式、确定性要求极高	律所知识库，“是/否”题准确率+25%

关键洞察：生成约束注入是ROI最高的起点。它几乎零成本（改Prompt）、见效最快（当天上线）、效果最稳（不依赖数据或GPU）。我们建议所有团队从它开始，再根据瓶颈逐步叠加其他技术。别一上来就想建Rerank集群，那可能是你最大的幻觉。

4.3 效果验证方法论：用业务语言定义“准确”，而非技术指标

技术团队爱谈MRR、Hit Rate，但业务方只关心：“这个问题，我的客户能不能得到正确答案？”我们建立了三层验证体系：

第一层：人工黄金集（Gold Set）

由业务专家（非技术人员）出100个真实高频问题；
对每个问题，人工标注“正确答案”及“答案必须出自的原文位置”（精确到页码/段落）；
每月用此集跑全链路，统计“答案完全匹配率”（字符级全等）和“关键信息匹配率”（如数值、单位、是/否判断正确）。

第二层：在线A/B测试

将用户流量50/50分流：A组用旧RAG，B组用新方案；
监控核心业务指标：
- 答案采纳率：用户点击“有用”按钮的比例；
- 二次提问率：用户问完一个问题后，10分钟内追问相关问题的比例（越低说明首次答案越准）；
- 人工介入率：客服后台标记“需人工复核”的比例。

第三层：对抗性压力测试

构造三类刁钻问题：
- 歧义陷阱：“苹果手机保修期多久？”（需区分国行/美版/翻新机）；
- 隐含前提：“高血压患者能吃阿司匹林吗？”（需先判断是否为心血管高危人群）；
- 数值陷阱：“2023年净利润比2022年增长了多少？”（原文只给两年绝对值，需计算差值）。

在某次升级后，我们用此体系发现：新方案在黄金集上准确率+32%，但在线A/B测试中“答案采纳率”仅+18%。深挖发现，新方案答案更准确但更“干巴”，用户觉得“不够贴心”。于是我们加了一条人性化规则：“在严格事实答案后，可加一句不超过10字的提示，如‘详见第3章第2节’”。采纳率立刻回升至+29%。这提醒我们：精度提升的终点，永远是用户的真实体验，而非技术指标的孤芳自赏。

5. 常见问题与避坑指南：那些没人告诉你的实战真相

5.1 “为什么我用了最先进的Rerank模型，准确率反而下降了？”

这是高频踩坑。根本原因：Rerank模型在你的数据上过拟合了。我们见过太多团队直接下载bge-reranker-large，在通用数据集上训好，就往医疗/法律场景一塞。结果发现，模型把“心肌梗死”和“心绞痛”判为高相关（因都含“心”字），但临床中这是两种病。

解决方案：

必须做领域适配微调。哪怕只用100个标注样本（问题+正例片段+负例片段），微调后效果也远超通用模型；
负例要狠：负例不能是随机片段，必须是“看起来像但实际无关”的片段。比如问题“新冠疫苗加强针间隔”，负例选“流感疫苗接种时间”，而非“公司年报摘要”；
监控校准度：用Platt Scaling校准模型输出的概率，确保0.9分真的代表90%准确率，而非模型自信过头。

实操心得：我们曾用通用Rerank，MRR 0.75，但人工抽检发现Top1错误率31%。微调后MRR降到0.72，但Top1错误率降至12%。业务方选了后者——他们要的是“大概率对”，不是“平均排名高”。

5.2 “Query Rewriter生成的关键词，为什么向量检索反而找不到答案？”

常见于中文场景。问题出在：Rewriter生成的英文关键词，和中文向量模型的词嵌入空间不匹配。比如Rewriter输出"diabetes, treatment, adults"，但你的向量模型是用中文语料训的，对英文词向量质量差。

根治方案：

Rewriter输出必须与向量模型语言一致。如果用中文Embedding，Rewriter必须输出中文关键词，如“糖尿病，治疗，成年人”；
关键词需做同义词扩展。Rewriter输出后，接一个同义词库（如哈工大同义词词林），自动扩展：“糖尿病”→“消渴症”“DM”“血糖升高”；
强制保留原始查询中的实体。Rewriter不能丢掉用户原话里的专有名词，如用户问“信达证券的IPO承销费率”，Rewriter必须保留“信达证券”“IPO承销费率”。

我们在某券商知识库，将Rewriter输出从英文改为中文+同义词扩展后，首检命中率从44%飙升至79%。因为向量模型终于能理解“IPO承销费率”和“首次公开发行保荐费用”是同一概念。

5.3 “上下文压缩后，LLM说‘根据以上信息，无法回答’，但原文明明有答案！”

这是压缩算法的“误杀”。算法按规则打了低分，但人类一眼能看出那是关键句。典型如：“注：本条款适用于2024年1月1日后签署的所有合同。” 这句话实体密度低（只有“2024年1月1日”一个实体），位置在页脚，按规则会被剔除。但它是整个条款生效的前提。

应对策略：

为特殊句式设白名单：用正则匹配“注：”“特别提示：”“重要：”开头的句子，强制保留；
增加“时效性”权重：含具体年月日的句子，时效分+5（满分10）；
人工校验机制：每周抽样100个被压缩的片段，由业务专家标注“是否误删”，持续优化算法阈值。

注意：算法永远不如人懂业务。我们设置了一个“压缩豁免”开关：当用户问题含“注”“特别提示”“重要”等词，自动关闭压缩，送入全部Top3片段。这招在法律、合规场景救了我们无数次。

5.4 “生成约束注入后，LLM经常输出格式错误的JSON，怎么办？”

这是Prompt工程的老大难。LLM不是代码编译器，它会“努力”凑出JSON，但字段名拼错、引号漏写、逗号多加。

三重保险方案：

第一重：Prompt中用XML标签包裹JSON，如<answer_json>{"answer":"..."}</answer_json>。XML标签比JSON引号更难伪造，LLM更易识别；
第二重：后端用Pydantic模型校验，定义严格Schema，捕获所有格式错误，并返回清晰错误码（如ERR_JSON_SYNTAX）；
第三重：失败时自动Fallback。若JSON校验失败，立即用更宽松的正则提取"answer":"(.+?)"，并记录日志供后续优化Prompt。

我们在某银行项目中，此方案将JSON解析失败率从12%压至0.3%。关键是：不追求100%完美，而追求99.7%可用+0.3%有迹可循。

5.5 “业务方说‘还是不准’，但所有指标都显示提升了，到底谁错了？”

这是最棘手的。真相往往是：你们在用不同的“准确”定义对话。技术团队看黄金集，业务方看某个具体case；技术团队统计整体，业务方揪着那个1%的错误不放。

破局之道：

建立共同语言：和业务方一起定义“什么是不可接受的错误”。例如：“数值错1%可以接受，但‘是/否’判断错误零容忍”；
错误分类看板：将错误分为四类：
- A类（致命）：关键数值、法律条款、安全警告错误；
- B类（严重）：实体名称错、单位错、时效错；
- C类（一般）：格式不统一、标点错误；
- D类（可接受）：同义词替换（“心梗”vs“心肌梗死”）。
  只盯A/B类错误率，C/D类不计入考核；
定期“错误复盘会”：每月拉业务方一起看10个典型A类错误，现场分析根因。这比发100页报告管用十倍。

最后分享一个真实故事：某次复盘会，我们发现一个A类错误——“手术同意书签署时限为术前24小时”，但系统答“48小时”。追查发现，原文PDF扫描件中“24”被OCR识别为“48”。技术团队立刻升级OCR引擎，业务方当场拍板追加预算。那一刻，大家才真正站在了同一战壕里。精度提升，终究是人与人之间的协作，而非模型与模型的竞赛。