RAG生产实战：检索质量、生成稳定性与延迟优化七关

1. 这不是理论课，是我在三个RAG项目里踩出来的实操手册

“Practical Tips and Tricks for Developers Building RAG Applications”——这个标题里最重的词不是RAG，不是Application，而是Practical。它不承诺你听懂Transformer架构就能上线，也不保证你调通一个LangChain Chain就万事大吉。它只负责告诉你：当客户在凌晨两点发来消息说“搜索结果完全不对”，当你发现用户问“上个月第三周的销售环比是多少”，系统却返回了三份PDF封面图，当你在Prometheus里看到retriever latency突然飙升到800ms而日志里只有“query processed”这一行时，你该先看哪一行代码、改哪个参数、查哪张表。

我过去18个月深度参与了三个生产级RAG系统交付：一个面向金融合规文档的内部知识中枢（日均查询12万+，SLA 99.95%），一个嵌入SaaS产品中的客户支持助手（支持17种语言，响应需<1.2秒），还有一个医疗科研文献辅助平台（处理超200万篇带图表的PDF，要求答案可溯源至具体段落和页码）。它们用的不是同一套技术栈，但暴露出的问题高度一致——90%的线上故障和体验劣化，根源不在LLM本身，而在于RAG流水线中那些被文档轻描淡写带过的“小细节”：分块策略选错一个参数，整个语义检索就失效；重排序模型没做领域适配，top-3结果里永远混着一条无关信息；甚至只是PDF解析时丢掉了页眉页脚里的章节编号，下游就再也无法准确定位答案来源。

这篇内容就是为正在真实环境里搭建RAG系统的开发者写的。它不讲BERT怎么预训练，不推导Cross-Encoder的损失函数，不比较Llama3和Qwen谁更“聪明”。它只聚焦一件事：如何让RAG从实验室Demo变成扛住业务压力、经得起用户反复折腾的可靠服务。无论你是刚跑通第一个from langchain.retrievers import BM25Retriever的新手，还是已经部署过两版向量库的老兵，只要你还在为“为什么召回不准”、“为什么答案幻觉严重”、“为什么加了重排反而更慢”这些问题熬夜，这里记录的就是你马上能抄、能改、能验证的经验。核心关键词很直白：RAG应用开发、检索质量、生成稳定性、延迟优化、生产可观测性——没有虚词，全是我在Kibana里盯过、在Grafana里调过、在prod机器上strace过的真问题。

2. RAG不是“检索+生成”两个模块的拼接，而是一条必须全程可控的精密流水线

2.1 为什么90%的RAG失败始于对“流水线”的误判

很多团队启动RAG项目时，脑子里的架构图是这样的：用户提问 → Embedding模型 → 向量数据库 → LLM → 答案。这图没错，但它漏掉了最关键的要素——每个箭头都是有损耗、有偏差、有状态的活体管道，而非理想化的无损通道。我把RAG流水线拆解为五个强耦合、不可割裂的环节：数据摄入（Ingestion）→ 文本切分（Chunking）→ 向量化与索引（Embedding & Indexing）→ 检索与重排（Retrieval & Re-ranking）→ 提示工程与生成（Prompting & Generation）。任何一个环节的微小偏差，在下游都会被指数级放大。

举个真实案例：我们在金融合规项目中，初期用默认的RecursiveCharacterTextSplitter（chunk_size=500, chunk_overlap=50）处理监管文件。表面看一切正常，直到某天风控同事问：“《巴塞尔协议III》第4.2.1条关于杠杆率缓冲的要求，是否适用于所有一级资本工具？”系统返回的答案里混入了《巴塞尔协议II》里早已废止的条款。排查发现，原始PDF中“巴塞尔协议III”和“II”的章节标题紧邻，分块时被切到了同一个chunk里。Embedding模型把这两个完全不同的协议编码成了相似向量，检索时只要query里出现“巴塞尔”，就大概率召回这个“双协议混合块”。我们没去换更大参数的embedding模型，而是直接重构了chunking策略：强制按文档结构切分（识别H1/H2标题）、在chunk开头注入文档元数据前缀（如“[Basel III] Chapter 4.2.1: Leverage Ratio Buffer…”）、将chunk_size从500字符压缩到200字符并增加overlap至100。改动后，该类混淆查询的准确率从63%跃升至98.7%。你看，问题根子在数据摄入端的切分逻辑，解决方案却要穿透整个流水线设计。

提示：不要迷信“端到端微调”。RAG的脆弱性往往藏在数据预处理的毛细血管里。一个没处理好的PDF页眉、一段被OCR错误识别的表格、一个未标准化的日期格式（“2023-01-01” vs “Jan 1st, 2023”），都可能成为压垮检索质量的最后一根稻草。流水线思维的第一步，是给每个环节装上“压力表”和“流量计”。

2.2 流水线各环节的“可控性”指标定义

要让RAG真正可控，必须为每个环节定义可测量、可告警、可归因的质量指标。这不是为了写汇报，而是为了在问题发生时，30秒内定位到故障域。以下是我在三个项目中沉淀出的核心指标清单，全部接入了Prometheus+Grafana：

这些指标不是摆设。在医疗项目中，我们设置了recall_at_3 < 80%的告警，触发后自动拉取最近100次失败query，用diff工具对比其embedding向量与标准答案chunk的余弦相似度分布。结果发现，所有失败case都集中在“药物相互作用”类query上——因为原始embedding模型是在通用语料上训练的，对“CYP3A4抑制剂”这类专业术语的向量表征能力极弱。解决方案不是换LLM，而是在embedding层前插入一个轻量级的领域术语增强模块（Domain Term Augmentor）：对query和chunk中的医学实体（从UMLS词典匹配）进行同义词扩展和权重提升。这个改动使recall_at_3在该类query上从41%提升至92%，且未增加任何推理延迟。

2.3 流水线协同设计的三大铁律

基于上述实践，我总结出RAG流水线设计不可妥协的三条铁律，每一条都源于血泪教训：

铁律一：Chunking策略必须与下游任务强绑定，而非追求“通用最优”
很多人花大力气调参找“最佳chunk_size”，却忘了问：你的RAG要解决什么问题？如果是问答（QA），需要chunk包含完整问答对，size宜小（128-256 tokens），强调语义完整性；如果是摘要（Summarization），chunk需覆盖完整事件脉络，size宜大（512-1024 tokens），容忍一定冗余；如果是法律条款比对，则必须按条款编号切分，哪怕一个条款只有20字。我们在SaaS客服项目中，曾用512-token chunk处理用户投诉邮件，结果LLM总在生成答案时遗漏关键时间点。后来改为按句子边界切分+滑动窗口合并：先按标点切句，再将语义连贯的3-5句合并为一个chunk，并在chunk头标注“[Time: 2024-03-15] [Issue: Payment Failed]”。这个看似笨拙的方法，让时间敏感型query的准确率提升了37%。

铁律二：Embedding模型的选择，80%取决于你的数据分布，而非榜单排名
别被MTEB排行榜绑架。一个在新闻语料上SOTA的模型，面对满是缩写、符号、表格的医疗PDF，表现可能不如一个专为生物医学微调的小模型。我们的做法是：用1000个真实业务query，对候选embedding模型进行A/B测试。测试不是比平均cosine similarity，而是比recall_at_3——即每个query检索出的top-3 chunk中，有多少个真正包含了回答该query所需的最小信息单元（我们称之为“Answer Span”）。测试发现，bge-reranker-base在金融文本上recall_at_3为79.2%，而一个仅用10万条监管文件微调过的text-embedding-ada-002变体，达到了86.5%。后者参数量小3倍，推理快2.1倍。选择依据很简单：在你的数据上，谁让正确答案更快、更准地出现在前三名里。

铁律三：重排序（Re-ranking）不是“锦上添花”，而是检索质量的最终保险丝
很多团队觉得“向量检索够用了”，跳过重排。但在真实场景中，向量检索的top-10里常混入2-3个高相似度噪声（如相同作者的不同论文、同一政策的不同修订版）。重排模型的作用，是用更精细的语义匹配（如Cross-Encoder）对这10个候选做终极审判。我们坚持：所有生产RAG必须配置重排，且重排模型必须用业务query微调。微调数据不用多，200个高质量query-pair（正例：query+正确chunk；负例：query+相似但错误的chunk）足矣。用cohere-rerank-v3做基线，微调后mrr提升22%，且re_rank_latency_p95稳定在220ms内（通过ONNX Runtime + TensorRT优化）。记住：重排不是增加延迟的负担，而是用可控的毫秒级代价，买断了检索结果的可靠性。

3. 检索质量攻坚：从“能搜到”到“精准命中”的七道关卡

3.1 关卡一：PDF/文档解析——90%的“垃圾进”源头在此

RAG的基石是干净、结构化的文本。而现实是，80%的企业知识库是PDF，其中又有一半是扫描件或复杂排版。我们踩过的坑足够写本书：

• 扫描PDF的OCR陷阱：Tesseract默认输出会把表格识别成乱序文本流。比如一个三列表格，OCR后变成“姓名电话邮箱姓名电话邮箱…”。解决方案不是换OCR引擎，而是在OCR后强制执行表格结构重建。我们用pdfplumber提取原始坐标，用layoutparser识别表格区域，再调用table-transformer模型恢复行列结构，最后将表格转为Markdown格式嵌入chunk。这一步使财务报表类query的准确率从31%升至89%。

• 页眉页脚污染：监管文件页眉常含“机密”、“版本号V2.3”等字样，被无差别塞进chunk，污染embedding。我们开发了一个轻量规则引擎：用正则匹配页眉页脚模式（如“^第.页$”、“^保密等级.$”），结合字体大小、位置（距页边<1cm）双重过滤，识别后剥离。剥离后，chunk_length_stddev下降42%，检索噪声减少明显。

• 文档元数据丢失：原始PDF的章节标题、页码、作者信息，是答案溯源的关键。但多数解析器（如PyPDF2）只返回纯文本。我们的方案是：用pymupdf（fitz）解析，它能保留完整的文本块（TextBlock）坐标、字体、颜色信息。我们据此构建元数据：坐标在顶部10%且字体加粗的TextBlock视为章节标题；坐标在底部5%且含“Page”字样的视为页码。这些元数据被注入chunk开头，格式为[Source: SEC_Filing_2024.pdf | Page: 42 | Section: Risk Factors]。这不仅让答案可溯源，更让LLM在生成时天然感知上下文层级。

注意：不要试图用一个工具解决所有解析问题。我们生产环境是混合栈：pymupdf处理文字+元数据，pdfplumber+table-transformer处理复杂表格，unstructured处理Office文档，doctr处理扫描件。每个工具只做它最擅长的一件事，用统一API封装。

3.2 关卡二：文本切分——不是切得越碎越好，而是切得“恰到好处”

Chunking是RAG里最被低估的艺术。我见过太多团队把chunk_size设为1000，结果发现top-1结果里永远缺了最关键的那个条件句。核心原则：chunk必须是一个语义原子（Semantic Atom），即独立存在时仍能表达完整意图或事实。

我们采用三级切分策略，动态适配内容类型：

1. 第一级：结构感知切分（Structure-Aware Splitting）
   用langchain.text_splitter.MarkdownHeaderTextSplitter或自研的PDF标题识别器，按H1/H2/H3标题切分。这是底线，确保不跨章节。

2. 第二级：语义完整性校验（Semantic Integrity Check）
   对每个标题切分后的chunk，运行轻量NLP检查：

   • 是否包含完整主谓宾（用spaCy依存分析，ROOT节点存在且非介词）
   • 是否以句号/问号/感叹号结束（避免截断句子）
   • 是否含“if”、“when”、“unless”等条件连词，且对应从句完整（用规则匹配括号和逗号）
     若不满足，向前/后合并相邻chunk，直到满足。

3. 第三级：长度约束与重叠（Length Constraint & Overlap）
   在满足语义完整的前提下，应用长度约束：

   • QA类：max_tokens=256，overlap=64（确保条件句不被切开）
   • 法律条款：max_tokens=128，overlap=32（条款短，需高精度）
   • 技术文档：max_tokens=512，overlap=128（需覆盖上下文）

实测效果：在金融项目中，此策略使recall_at_3提升28%，且LLM生成答案的“引用准确性”（即答案中提到的条款编号与实际chunk元数据一致）达99.2%。

3.3 关卡三：向量化——Embedding不是黑盒，是可调试的组件

Embedding模型常被当作黑盒调用。但它的输出向量，直接决定了检索空间的几何结构。我们必须能“看见”它。

我们的调试方法论叫向量空间探针（Vector Space Probing）：

• 步骤1：构建探针集（Probe Set）
  选取50个典型业务query（如“如何申请跨境支付牌照？”、“GDPR对数据本地化的要求？”），以及每个query对应的3个黄金答案chunk（人工标注）。

• 步骤2：可视化向量分布
  用UMAP降维，将所有probe query和golden chunk向量投射到2D平面。健康状态应是：每个query向量与其golden chunk向量紧密聚簇，不同query簇之间清晰分离。若发现“跨境支付”和“数据本地化”簇严重重叠，说明embedding模型未能区分领域概念。

• 步骤3：诊断与干预
  若分布异常，优先检查：

  • 输入预处理：query是否做了领域术语增强？（如将“GDPR”替换为“General Data Protection Regulation”）
  • 模型微调：用probe set的query-chunk pair，对embedding模型最后一层做LoRA微调（仅训练0.1%参数）
  • 后处理：对向量做L2归一化，或应用领域特定的向量加权（如对法规名称、条款编号字段的embedding向量赋予更高权重）

在医疗项目中，我们发现“drug interaction”和“adverse reaction”在向量空间中距离过近。通过在query预处理中加入UMLS语义类型标签（[UMLS:T121]表示“药物”），并将该标签的embedding向量与query向量concat，再送入模型，两者的欧氏距离扩大了3.2倍，recall_at_3提升19%。

3.4 关卡四：向量索引——选型不是比速度，而是比“抗噪性”

向量数据库选型，新手常陷入QPS（每秒查询数）的迷思。但生产环境中，更致命的是抗噪性（Noise Resistance）——即在数据有噪声、query有歧义、网络有抖动时，仍能返回稳定结果的能力。

我们对比了FAISS、Milvus、Qdrant、Weaviate在真实负载下的表现：

结论：Weaviate的Hybrid Search是生产首选。它允许我们对模糊query（如“苹果的财报”）先用BM25召回相关文档，再用向量检索精排，完美规避了纯向量检索对拼写错误、缩写（“AAPL” vs “Apple Inc.”）的敏感。在SaaS客服项目中，Hybrid Search使recall_at_3在长尾query上稳定在90%+，且mrr比纯向量方案高0.15。

3.5 关卡五：检索策略——单一向量检索已死，混合检索是标配

“向量检索”这个词本身已过时。真实世界中，用户query千奇百怪：有精确术语（“ISO 27001 Clause 8.2”），有口语化描述（“我的密码忘了怎么办？”），有拼写错误（“recieve”），有缩写（“FDA”）。指望一个embedding模型通吃，是最大的幻觉。

我们的生产检索策略是四层漏斗（Four-Layer Funnel）：

1. Layer 1：关键词初筛（Keyword Pre-filter）
   用Elasticsearch或Weaviate的BM25，对query做全文检索，召回top-1000 candidate。这步极快（<50ms），且对拼写、缩写鲁棒。过滤掉明显无关文档（如query含“退款”，却召回“新产品发布”文档）。

2. Layer 2：向量精检（Vector Refinement）
   对Layer 1的1000个candidate，用向量数据库计算query向量与它们的相似度，取top-100。这步利用了语义，但范围已大幅缩小，效率可控。

3. Layer 3：重排序（Cross-Encoder Re-ranking）
   将Layer 2的top-100，用微调过的bge-reranker-large做精细化打分，取top-10。这是精度保障。

4. Layer 4：规则终审（Rule-based Final Filter）
   对top-10应用业务规则：

   • 时间过滤：若query含“2024年”，则剔除发布时间早于2024-01-01的chunk
   • 权限过滤：根据用户角色，剔除标记为“HR Only”的chunk
   • 一致性过滤：若多个top-chunk来自同一文档，只保留分数最高者，避免答案重复

这套策略在金融项目中，将recall_at_3从单一层的68%提升至89%，且P95延迟稳定在320ms（Layer 1: 45ms, Layer 2: 180ms, Layer 3: 85ms, Layer 4: 10ms）。

3.6 关卡六：重排序——小模型，大作用，必须微调

重排序模型常被当作“可选项”。但数据证明，它是RAG精度的最后防线。我们坚持：不微调的重排模型，不如不用。

微调方法极其简单：

• 数据：收集200个真实bad case。Bad case = 用户query + 检索返回的top-10 chunk中，人工标注哪些是“相关”（label=1），哪些是“不相关”（label=0）。重点收集那些向量相似度高但语义无关的case（如“利率”和“汇率”的混淆）。
• 模型：选用bge-reranker-base（384M参数），因其在中文上表现稳健，且支持ONNX导出。
• 训练：用Pairwise Ranking Loss，batch_size=16，epochs=3。全程在单张3090上完成，耗时<15分钟。
• 部署：导出为ONNX模型，用ONNX Runtime推理，P95延迟<200ms。

效果：微调后，mrr从0.62升至0.79，rerank_gain达17.3%。更重要的是，它显著降低了LLM的幻觉率——因为输入给LLM的context，是经过语义严格筛选的top-3，而非向量检索的“相似度最高但可能无关”的top-3。

3.7 关卡七：检索评估——别信“平均准确率”，要信“长尾分布”

所有RAG团队都该建立自己的长尾评估集（Long-Tail Evaluation Set）。它不是100个随机query，而是：

• 50个高频query（占流量70%）
• 30个中频query（占流量20%）
• 20个长尾query（占流量10%，但投诉率最高）：如“2023年Q4欧盟对AI法案的最新修订意见稿第3.2条原文”，“客户ID CUST-8821在2024-02-15的退款申请状态变更日志”

我们每月用此集评估，绘制recall_at_k曲线（k=1,3,5,10）。健康RAG的曲线应是：recall_at_1≥75%，recall_at_3≥85%，recall_at_10≥95%。若recall_at_1很高但recall_at_3骤降，说明重排失效；若recall_at_10远低于95%，说明初筛（Layer 1）漏掉了关键文档。

一次评估中，我们发现长尾query的recall_at_3仅为52%。深挖日志，发现这些query都含精确时间戳和ID，而我们的关键词初筛（Layer 1）未开启phrase match，导致“2024-02-15”被拆分为三个独立词，召回率暴跌。修复后，长尾queryrecall_at_3升至88%。

4. 生成稳定性与延迟优化：让RAG从“能用”到“敢用”的实战心法

4.1 Prompt工程不是写作文，是设计“LLM的思考路径”

很多团队把Prompt当成魔法咒语，反复试错“加个‘请’字会不会更好”。这是误区。Prompt的本质，是为LLM设定一个清晰、可执行的推理框架（Reasoning Framework）。我们用的不是Chain-of-Thought，而是Chain-of-Verification（验证链）。

标准Prompt结构如下（以金融问答为例）：

你是一名资深金融合规顾问，正在为客户解答问题。请严格遵循以下步骤： 1. 【检索验证】：检查提供的上下文（Context）中，是否明确包含回答问题所需的全部关键信息（如具体条款编号、生效日期、适用对象）。若缺失任一关键信息，回答“根据当前资料，无法确定，请咨询合规部门”。 2. 【溯源标注】：若能回答，必须在答案末尾用[Source: filename.pdf | Page: X | Section: Y]格式标注信息来源。禁止编造来源。 3. 【风险提示】：若答案涉及“建议”、“可能”、“通常”等非绝对性表述，必须在答案开头添加“【风险提示】：此为一般性参考，具体执行请以最新监管文件为准。” 4. 【简洁输出】：答案必须控制在3句话内，首句直接给出结论。 问题：《巴塞尔协议III》第4.2.1条关于杠杆率缓冲的要求，是否适用于所有一级资本工具？ Context：[Source: Basel_III_Final.pdf | Page: 42 | Section: 4.2.1] "The leverage ratio buffer applies to Common Equity Tier 1 capital instruments issued by globally systemically important banks (G-SIBs), but not to other Tier 1 or Tier 2 instruments."

这个Prompt的威力在于：它不告诉LLM“怎么想”，而是告诉它“想什么、验证什么、标注什么”。在SaaS客服项目中，采用此框架后，答案幻觉率从12.7%降至3.2%，且100%的答案都带有效溯源标注。LLM不再自由发挥，而是成为一个严格执行验证流程的合规机器人。

实操心得：Prompt必须和你的RAG流水线深度耦合。例如，如果你的chunking策略在chunk头注入了[Section: Risk Factors]，那么Prompt里就必须有“检查Section字段是否匹配”的指令。脱钩的Prompt，再华丽也是空中楼阁。

4.2 上下文管理——不是塞得越多越好，而是“精准喂养”

LLM的上下文窗口（如128K）是诱惑，也是陷阱。我们严禁将top-10 chunk全塞进去。原因有三：

• 信息稀释：无关chunk挤占token，稀释关键信息权重
• 幻觉温床：LLM可能从噪声chunk中提取错误事实
• 延迟黑洞：长上下文使LLM推理时间呈非线性增长

我们的上下文注入策略是动态精炼（Dynamic Refinement）：

• Step 1：Query-Chunk相关性打分
  用重排模型对top-10 chunk再次打分，取top-3。
• Step 2：Chunk内信息密度过滤
  对每个top-3 chunk，用规则提取“信息密度”：
  • 统计chunk中名词短语（NP）数量（用spaCy）
  • 过滤掉NP数量<3的chunk（信息量不足）
  • 若NP数量>15，用TextRank算法提取top-5关键句，只注入这些句子
• Step 3：注入元数据前缀
  将[Source: ... | Page: ... | Section: ...]作为chunk第一行，确保LLM优先关注来源

此策略使平均注入token数从3200降至850，P95生成延迟从1800ms降至920ms，且answer_hallucination_rate下降41%。

4.3 延迟优化——从“毫秒级”到“亚秒级”的七项硬核操作

RAG的P95延迟必须<1.2秒，否则用户感知为“卡顿”。我们的优化清单，每一项都经过压测验证：

1. Embedding层：ONNX Runtime + TensorRT加速
   将bge-m3模型导出为ONNX，用TensorRT在GPU上推理。效果：单文档向量化从1200ms→210ms，提速5.7倍。

2. 向量检索层：量化索引（Quantized Index）
   Weaviate中启用hnsw索引的ef_construction=128和M=32，并开启quantizer（PQ量化）。效果：索引内存占用降65%，recall_at_3仅降0.8%，P95检索延迟从180ms→95ms。

3. 重排序层：模型蒸馏（Model Distillation）
   用bge-reranker-large（1.2B）蒸馏出bge-reranker-small（120M），保持95%的mrr。效果：重排延迟从280ms→110ms。

4. LLM层：KV Cache复用
   在生成时，对同一query的多次请求，复用第一次的KV Cache。需在API网关层实现请求指纹（fingerprint）和Cache Key映射。效果：第二次请求延迟从900ms→200ms。

5. 网络层：gRPC替代HTTP
   所有内部服务（Embedding、Retriever、Reranker、LLM）间通信，改用gRPC。效果：序列化/反序列化开销降70%，P95网络延迟从85ms→25ms。

6. 缓存层：两级缓存（Two-Level Cache）

   • L1：Redis缓存query -> top-3 chunk IDs（TTL=1h），命中则跳过检索
   • L2：本地内存缓存chunk ID -> chunk text（TTL=24h），避免重复读取向量库
     效果：整体P95延迟降35%，缓存命中率82%。

7. 熔断降级：Fallback Strategy
   当任一环节延迟>1s，自动降级：

   • Embedding失败 → 用BM25关键词检索
   • 重排失败 → 直接用向量检索top-3
   • LLM超时 → 返回“正在处理，请稍候”，后台异步生成后推送
     效果：P99.9延迟从5.2s→1.1s，可用性从99.2%→99.95%。

4.4 生产可观测性——没有监控的RAG，等于裸奔

RAG的复杂性决定了：没有端到端可观测性，就不可能快速定位问题。我们的监控栈是：

• Metrics（指标）：所有前述流水线指标，全部上报Prometheus。关键告警：

  • retrieval_recall_at_3 < 80%（持续5分钟）
  • generation_hallucination_rate > 8%（滚动1小时）
  • retriever_latency_p95 > 300ms（持续10分钟）

• Traces（链路追踪）：用Jaeger追踪每个query的完整链路。关键Span：
  ingestion → chunking → embedding → retrieval → reranking → prompting → generation
  每个Span标注耗时、输入长度、输出长度、错误码。当retrievalSpan耗时突增，可立即下钻到具体query和向量库实例。

• Logs（日志）：结构化日志，每个query生成唯一request_id，贯穿所有服务。关键日志字段：
  request_id,user_id,query,retrieved_chunks（ID列表）,reranked_chunks（ID+score）,final_context_tokens,llm_response,hallucination_flag

• Debugging（调试）：提供/debug端点，输入request_id，返回该query的完整流水线快照：原始query、所有中间chunk文本、各环节耗时、LLM输入prompt全文、LLM输出。这是SRE的救命稻草。

在一次线上事故中，retrieval_recall_at_3跌至65