很多团队第一次把产品文档接进 Dify 知识库时，都会遇到一个很微妙的问题：系统看起来能回答，回答也像那么回事，但细看又经常答偏。
用户问“私有化部署时如何配置对象存储”，它回答“如何创建普通账号”；用户问“旧版本迁移到新版本是否需要重建索引”，它开始解释“什么是知识库”；用户追问“这个接口 timeout 怎么排查”，它给出一段和前端请求超时相关的通用建议，完全没有引用内部文档里的网关、向量引擎、Embedding 服务和重试策略。
这种问题最容易被误判为“大模型不行”。于是有人换更大的模型，有人调 Prompt，有人把温度降到 0，有人把“请严格基于知识库回答”写三遍。结果可能会好一点，但很难稳定。因为在 RAG 系统里，模型只是最后一个环节。真正决定答案是否贴着文档走的，往往是前面的检索链路：文档怎么切、Embedding 怎么建、向量引擎有没有命中、TopK 和相似度阈值怎么设、重排有没有启用、上下文预算够不够、最终塞给模型的证据是不是正确。
本文以一个产品文档知识库从“答非所问”到“可稳定上线”的调优过程为主线，复盘 Dify 知识库问答里最常见的答偏原因。它不是一篇点按钮教程，而是一份工程排查笔记：当你已经能把 Dify 跑起来，却不知道为什么知识库问答不稳时，可以按这条链路逐段检查。
一、先把“答偏”拆成四类，不要一上来就改 Prompt
我们最初接入的是一套产品文档知识库，内容包括安装部署、API 调用、错误码、权限体系、计费说明、版本迁移和常见问题。文档总量不算大，几十万字，按理说不应该特别难。但第一轮测试时，问题非常集中：简单概念能答，细节问题容易偏；热门文档能答，冷门章节容易漏；相似词能召回，带具体错误码的问题反而乱；多轮追问时，第一轮正确，第二轮开始漂。
如果只看最终答案，会觉得问题很多、毫无规律。我们后来把失败样本拆开，发现大致可以分成四类。
第一类是“没有召回”。用户的问题对应文档里明明有答案，但检索结果里没有相关片段。模型拿不到证据，只能凭通用知识补。比如文档写了“导入离线模型后需要在模型供应商页刷新模型列表”，但用户问“为什么 Dify 里配置了模型还是 model_not_found”，检索结果却命中了“模型价格说明”。
第二类是“召回了但排序靠后”。相关片段出现了，但排在第 8、第 12，最终 TopK 只给模型前 4 条。模型看到的是别的段落，自然答偏。这类问题在混合检索或相似度阈值设置不合理时很常见。
第三类是“召回片段本身坏了”。文本分段把标题、前置条件、表格说明和正文拆散了。某个片段里只有“将该字段设置为 true”，但上一个片段才写了“如果使用企业统一接入网关”。模型拿到半截证据，答案就会像断章取义。
第四类是“上下文拼接失败”。检索结果是对的，重排也是对的，但塞进模型时被截断、被模板稀释，或者被聊天历史挤掉。尤其是文档片段较长、TopK 较大、系统提示词又很啰嗦时，真正有效的证据可能没有进入模型可关注的位置。
所以，调 Dify 知识库问答时，第一步不是改 Prompt，而是给每个失败样本打标签：没召回、排序差、分段坏、上下文挤。只有把问题归类，后面的调参才不是碰运气。
二、Embedding 不是“随便选一个就行”
Embedding 的作用，是把用户问题和文档片段映射到同一个语义空间。用户问“如何排查 model_not_found”，文档里写“模型 ID 不存在或未授权”，二者字面不完全一样，但语义应该靠近。向量引擎检索时，就是用这种语义距离来判断哪些片段更相关。
问题在于，不同 Embedding 模型对语料的理解能力并不一样。中文产品文档、英文 API 文档、代码片段、错误码、表格字段、版本号、URL、命令行参数，对 Embedding 都是不一样的压力。如果模型更擅长通用对话语义，却不擅长技术字段，它可能知道“部署”和“安装”相近，却分不清model_not_found、invalid_api_key、context_length_exceeded这些错误码的边界。
我们当时的第一版知识库使用了默认 Embedding 配置，简单问答能过，但错误码类问题大量答偏。排查日志后发现，用户问model_not_found时，召回片段里经常出现“模型选择建议”“模型价格”“模型能力对比”，而真正的错误码章节排序不高。原因不是向量引擎坏了，而是 Embedding 对错误码这种强标识文本的区分度不足，再加上文档分段时错误码表格被拆得比较碎。
调优时，我们做了三件事。
第一，固定一组评测问题。不要只凭现场感觉测试。至少准备 50 到 100 个真实问题，覆盖安装部署、API Key、Base URL、模型 ID、知识库导入、timeout、rate_limit、上下文超限、权限、费用和版本迁移。每个问题标注期望命中的文档章节。
第二，对比不同 Embedding 模型的命中情况。不是只看最终答案，而是看 TopK 里有没有正确片段、正确片段排第几、相似度分数分布是否明显。一个好的 Embedding 配置，应该让同主题问题聚在一起，让跨主题片段拉开距离。
第三，切换 Embedding 后必须重建索引。很多人改了 Embedding 模型，却没有重新索引已有文档，结果新问题向量和旧文档向量不在同一套语义空间里，表现会很奇怪。知识库调优时，Embedding 模型、分段策略和索引状态要一起记录，不能只记 Dify 页面上的检索参数。
Embedding 的选择不是越贵越好，而是要看它是否适合你的文档。产品文档里大量出现字段名、接口路径、错误码、配置项时，评测集比主观体验更可靠。
三、文本分段决定“证据颗粒度”，不是越细越好
RAG 的第二个关键点是文本分段。文档进入知识库时，不会整篇都塞进向量引擎，而是切成一个个 chunk。用户提问后，系统召回的是 chunk，不是原始文档。
分段太短，会丢上下文。比如某个片段只有一句“将enable_rerank设置为 true”，但不知道是在哪个配置文件、哪个环境、哪个版本下设置。模型看到这句话，也很难回答完整。
分段太长，会稀释主题。一个 chunk 里同时包含部署说明、API 示例、错误码解释和计费规则，Embedding 会得到一个混合语义。用户问具体错误码时，这个长片段可能因为主题太杂而分数不高；即使命中，也会占用大量上下文预算。
我们在产品文档知识库里踩过一个典型坑：文档使用 Markdown 编写，标题层级很清晰，但导入时采用了固定长度切分。结果有些二级标题和正文被拆开，表格标题和表格内容被拆开，代码块和说明文字被拆开。用户问“OpenAI 兼容接口的 Base URL 应该填到哪一级”，召回片段里只有一段 URL 示例，却没有上文解释“客户端通常填/v1，具体接口请求才是/v1/chat/completions”。模型于是回答得含糊。
后来我们把分段策略改成“按标题结构优先，长度限制兜底”。也就是说，先尽量保持一个小节的完整语义，再用合理长度拆分；对表格、代码块、错误码列表这类结构化内容，尽量让字段名、含义、原因、处理方式留在同一个片段里。每个 chunk 的理想状态是：单独拿出来，也能回答一个具体问题。
分段时还要注意 overlap，也就是相邻片段的重叠。适当重叠可以保留上下文，比如前一个片段的标题和下一段开头同时出现。但 overlap 不是越大越好。重叠过大，会让相似片段重复进入召回结果，挤掉其他有价值的证据。我们的经验是：先用较小重叠保证标题和关键前置条件不丢，再通过日志观察重复召回比例。如果前 5 条里有 3 条几乎一样，就说明重叠或分段粒度可能需要调整。
一个好用的检查方法是：随机抽取 30 个 chunk，不看原文，只看 chunk 本身，问自己“这段能不能独立表达一个知识点”。如果大量片段需要翻前后文才能理解，分段就还没准备好上线。
四、向量引擎要看索引状态，也要看数据版本
在 Dify 里，知识库体验看起来像一个配置页面，但底层其实依赖向量引擎。文档导入、切分、Embedding、写入索引、检索召回，每一步都可能出问题。
有一次我们遇到一个很隐蔽的现象：新上传的文档在 Dify 页面里显示已经存在，但问答时完全召回不到。最初大家怀疑是相似度阈值太高，后来查任务日志才发现，文档解析成功了，分段也成功了，但 Embedding 写入阶段有部分失败。页面上看起来“文档在知识库里”，实际向量索引并不完整。
这类问题在自部署或企业内网环境里更常见。Embedding 服务可能经过 API 中转站或企业统一接入网关，网络超时、限流、模型权限、请求体大小限制都会影响索引。尤其是批量导入大文档时，一部分 chunk 写入成功，一部分 chunk 失败，如果没有日志审计，很难从最终问答表现倒推原因。
因此，向量引擎调优不能只看“有没有文档”，还要看四个状态。
第一，文档解析是否完整。PDF、Word、Markdown、网页抓取的结构差异很大。解析阶段如果丢表格、丢标题、丢代码块，后面再怎么调向量检索都救不回来。
第二，chunk 数量是否符合预期。几十万字文档只切出几十个 chunk，通常太粗；几万字文档切出几千个 chunk，通常太碎。数量异常往往能提前暴露分段问题。
第三，Embedding 是否全部成功。关注失败率、重试次数、timeout、rate_limit、model_not_found、invalid_api_key 这类错误。索引阶段的错误会直接变成召回阶段的盲区。
第四，索引版本是否一致。改了文档、改了分段、改了 Embedding、换了向量引擎配置，都应该记录版本。否则你今天测的是旧索引，明天测的是新索引，调参结论会互相打架。
如果团队已经有统一 API 网关，可以把 Dify 的模型请求和 Embedding 请求都纳入同一套日志。我们在项目里用过一个技术配置备忘页记录 Base URL、模型 ID、索引批次和网关观测入口，其中顺手记了一份工具入口：https://178.nz/dn。它不应该替代日志系统，但在多人协作排查时，能减少“你当时到底填的哪个地址”的沟通成本。
五、召回率和相似度阈值是一对跷跷板
知识库问答里，经常有人问：TopK 应该设多少？相似度阈值应该设多少？
这个问题没有固定答案，因为二者是一对跷跷板。TopK 控制“最多拿多少条候选证据”，相似度阈值控制“分数低于多少就不要”。TopK 太小，容易漏掉正确片段；TopK 太大，容易把噪声带进上下文。阈值太高，答案可能经常说不知道；阈值太低，模型可能被无关内容带偏。
Dify 文档里对知识检索节点的 Top K 和 Score Threshold 有明确说明：Top K 是重排后返回的最大结果数，Score Threshold 是返回结果的最低相似度要求。实际使用时，要结合是否启用 Rerank 来理解这些参数。如果没有重排，TopK 更像粗召回截断；如果启用了重排，TopK 和阈值才更适合承担“先找全，再筛准”的角色。
我们的调参顺序是这样的。
先关心召回，不急着追求答案漂亮。把 TopK 适当放宽，比如从 3 提到 8 或 12，阈值先不要设得过高。用评测问题观察正确片段是否能进入候选列表。这个阶段目标是“找得到”。
然后再关心噪声。看候选结果里有多少跨主题片段。比如用户问“timeout”，召回结果里是否混入“账单超额”“权限不足”“模型价格”。如果噪声很多，就逐步提高相似度阈值，或者改用混合检索与重排。
最后再收敛上下文。不是 TopK 越大越安全。最终给模型的证据应该足够覆盖答案，但不要把一堆弱相关片段塞进去。我们在线上通常会把“初始召回候选数”和“最终上下文片段数”分开看：前者可以偏大，后者必须克制。
一个很实用的判断标准是：如果正确片段经常排在 TopK 外，优先提升召回；如果正确片段已经在前几条，但答案仍然跑偏，优先检查上下文拼接和 Prompt；如果召回结果里相关和不相关混在一起，优先考虑重排。
六、重排不是装饰按钮，而是从“找得到”到“排得准”的关键
向量检索擅长快速找相似内容，但它不一定擅长精确排序。尤其在产品文档里，很多问题的语义相近，但答案边界不同。比如“API Key 无效”“模型不存在”“Base URL 填错”“网关超时”都属于接口接入问题，向量检索可能把它们放在一起。用户问invalid_api_key，如果model_not_found章节排在前面，最终答案就会答偏。
重排的价值在这里体现出来。典型做法是：第一阶段用向量引擎或混合检索取较多候选，第二阶段用 Rerank 模型根据用户问题重新排序，最后只把最相关的几条交给大模型。第一阶段追求召回率，第二阶段追求精度。
在 Dify 中，如果你的知识库问题已经从“完全找不到”变成“找得到但排序不稳”，就应该认真测试重排。不要把 Rerank 当成一个可有可无的增强项。它会增加延迟和成本，但对相似章节多、错误码多、FAQ 多的产品文档非常有用。
我们当时做过一组对比。不开重排时，用户问“OpenAI 兼容接口调用报 model_not_found 怎么处理”，前 5 条里有模型能力介绍、模型接入教程、错误码解释和价格说明，真正的错误码处理段落有时排第 4。开启重排后，错误码处理段落稳定排到前 1 或前 2，答案明显收敛。
不过，重排也不是魔法。它依赖第一阶段候选集。如果正确片段根本没有被初召回，重排模型也无能为力。所以调参时不要只看最终 TopK，要看两层：初召回候选里有没有正确片段，重排后正确片段是否靠前。前者不行，调 Embedding、分段、检索模式；后者不行，调 Rerank、阈值和候选数量。
还要注意成本控制。Rerank 的输入是候选片段，候选越多，重排耗时和费用越高。一个常见策略是：初召回 20 条以内，重排后取 3 到 6 条进入上下文。具体数字要根据文档长度、模型上下文窗口和业务容错率决定。
七、混合检索适合技术文档，但不要让关键词信号喧宾夺主
纯向量检索适合语义相近的问题，但技术文档里有大量强关键词：错误码、接口路径、字段名、配置项、版本号、命令行参数。这些内容靠语义相似度不一定稳定。用户问https://api.vectorengine.cn/v1/chat/completions，语义模型可能只理解“这是一个接口地址”，但全文检索可以直接命中原文。
因此，产品文档知识库通常更适合混合检索：向量检索负责理解“用户意图”，全文检索负责捕捉“精确符号”。Dify 的混合检索思路也正是把语义和关键词结合起来，再通过排序或重排挑选更合适的结果。
但混合检索也有副作用。关键词太强时，系统可能因为某个高频词反复命中无关章节。比如文档中到处都有“模型”“接口”“配置”，用户问“模型 ID 找不到”，全文检索可能命中所有含“模型”的段落。如果没有重排或合理权重，噪声会变多。
我们处理技术文档时，会把问题分成两类。
第一类是语义问题，比如“企业版如何做统一接入”“为什么知识库回答不稳定”“怎样减少上下文成本”。这类问题更依赖向量语义。
第二类是符号问题，比如model_not_found、timeout、rate_limit、Base URL、API Key、/v1/chat/completions。这类问题必须让关键词命中参与排序。
如果知识库里错误码和配置项很多，建议优先测试混合检索加重排，而不是只在纯向量检索里调阈值。纯向量检索调到最后，可能会在“语义问题”和“符号问题”之间顾此失彼。
八、上下文预算：证据找到了，不代表模型看到了
RAG 系统有一个容易被忽略的事实：检索成功不等于回答成功。最终模型能利用什么，取决于上下文里实际放了什么。
Dify 应用里通常会有系统提示词、用户问题、聊天历史、知识库片段、工具调用结果，有时还有输出格式要求。所有这些内容都会占用上下文窗口。如果模型上下文预算有限，或者模板组织不合理，检索到的关键证据可能被截断，也可能被放在很靠后的位置，导致模型关注不足。
我们曾经遇到过一个案例：检索日志显示正确片段排第 1，但模型答案仍然偏。进一步查看最终 prompt，发现系统提示词写得很长，包含角色设定、语气要求、免责声明、格式模板、边界规则；再加上多轮聊天历史，知识库片段只剩下几段摘要。正确证据虽然被召回，但进入模型时已经不完整。
解决这类问题，要把上下文当成预算来管理。
第一，控制系统提示词长度。RAG 应用的 Prompt 不应该堆满抽象要求。与其写十句“请严谨、准确、专业”，不如明确写“优先依据知识库片段回答；如果片段缺少关键条件，请说明缺失信息；不要把不同版本的配置混合”。
第二，控制聊天历史。多轮问答里，历史记录会快速挤占空间。可以只保留与当前问题相关的摘要，或者在知识库问答场景中降低历史权重。用户问产品文档细节时，最新问题和检索证据通常比很早的对话更重要。
第三，控制片段数量和长度。TopK 不是越大越好。最终进入上下文的片段要少而准，必要时对长片段做摘要或裁剪，但不要裁掉标题、版本、前置条件和关键字段解释。
第四，调整拼接顺序。重要证据应该靠近用户问题或明确标注来源。多个片段之间要有边界，避免模型把 A 章节的前提和 B 章节的结论拼在一起。
如果你遇到“日志里命中了，答案却不引用”的问题，不要急着换模型。先把最终上下文打印出来，看模型到底看到了什么。很多时候，问题就藏在这一步。
九、model_not_found、timeout、rate_limit：RAG 调优也要会排接口错误
Dify 知识库问答并不只是“知识库配置问题”。在真实部署里，它还依赖模型供应商、Embedding 服务、Rerank 服务、向量引擎、数据库、对象存储、API 网关和网络环境。任何一段出错，都可能表现为问答质量下降。
model_not_found是常见问题之一。它可能发生在生成模型，也可能发生在 Embedding 或 Rerank 模型。原因包括模型 ID 写错、使用展示名而非真实模型名、供应商未授权、Base URL 指向错误环境、网关模型路由未配置、模型下线或版本迁移后名称变化。排查时不要只看聊天模型，索引阶段的 Embedding 模型也要看。
timeout更复杂。它可能出现在文档导入阶段，也可能出现在查询阶段。导入大文档时，Embedding 批量请求过慢会导致索引超时；查询时，向量检索、重排、LLM 生成叠加，会让整体响应时间超过前端或网关限制。解决 timeout 不能只把超时时间调大，还要拆分耗时：解析耗时、Embedding 耗时、向量检索耗时、Rerank 耗时、生成耗时分别是多少。
rate_limit通常意味着并发或调用频率超过限制。知识库批量索引时很容易触发。处理方式包括降低批处理并发、增加重试退避、分时导入、使用缓存、给 Embedding 和生成模型分开配额。不要让线上问答和批量索引抢同一个模型额度，否则用户会在高峰期看到随机失败。
context_length_exceeded则通常和上下文预算有关。TopK 太大、片段太长、历史太多、系统提示词太长，都可能触发。处理时要从拼接策略入手，而不是简单换更长上下文模型。长上下文能缓解问题，但也会增加成本，并且不等于模型一定能更准确地利用所有证据。
如果团队使用 OpenAI 兼容接口或企业统一接入层，建议在配置表里明确区分三种地址：网关根地址、兼容接口版本地址、具体请求路径。例如有些客户端填https://api.vectorengine.cn/v1，实际请求由 SDK 拼成/chat/completions；而调试 curl 时可能直接访问完整路径。Base URL 层级混淆，是model_not_found和 timeout 排查中很常见的噪声来源。
十、日志审计：不要只看最终答案，要看每一步的证据
要把 Dify 知识库问答调到可上线，必须建立日志习惯。没有日志，所有调参都是玄学。
最少要记录这些字段：用户问题、改写后的查询、命中的文档 ID、chunk ID、chunk 文本摘要、相似度分数、重排分数、最终进入上下文的片段、模型 ID、Embedding 模型、Rerank 模型、响应耗时、错误码、token 消耗和最终答案。
这些日志有三个作用。
第一，用来定位单个失败样本。用户反馈“答错了”，你能快速知道是没召回、排序差、上下文挤，还是模型没有遵循证据。
第二，用来做批量评测。把 100 个问题跑一遍，统计命中率、正确片段平均排名、无答案率、平均耗时、平均成本。这样调参就有方向，而不是今天感觉好、明天感觉差。
第三，用来做成本审计。RAG 的成本不只在最终大模型生成。Embedding 索引、Rerank、长上下文生成、重试、失败请求都会产生成本。没有日志，很难知道钱花在哪个环节。
我们上线前做过一个简单但很有用的表格：每个问题一行，列出“期望文档”“召回 Top5”“正确片段排名”“是否进入最终上下文”“答案是否合格”“失败原因”。跑完一轮后，问题非常清楚：有些章节是分段问题，有些是阈值问题，有些是 Prompt 对无答案场景处理不好。然后逐类修，不会互相干扰。
日志不是为了追责，而是为了让系统可解释。RAG 最大的优势之一，就是答案可以追溯到外部知识。如果连内部调试时都看不到证据链，就很难谈稳定上线。
十一、成本控制要前置，而不是上线后再补
很多团队做 RAG 原型时，只关注“能不能答对”，上线前才发现成本和延迟压不住。Dify 知识库问答的成本主要来自四段：文档索引阶段的 Embedding，查询阶段的检索和重排，生成阶段的大模型调用，以及失败重试带来的额外消耗。
Embedding 成本通常是一次性或低频，但文档频繁更新时也会变成持续成本。优化方式包括增量索引、避免重复导入、文档去重、只索引有效正文、把版本归档文档和当前文档分开。
Rerank 成本和候选数量直接相关。候选越多，重排越贵、越慢。不要为了追求安全感，把初召回设到很大。先用评测集找一个能覆盖大多数问题的候选范围，再决定是否对高风险问题单独放宽。
生成成本和上下文长度、模型选择有关。不是所有问题都需要最强模型。简单 FAQ、固定配置查询、错误码解释，可以使用较低成本模型；复杂迁移方案、跨文档总结、需要推理的问题，再路由到更强模型。Dify 工作流或外部网关都可以承担一定的模型路由职责。
失败重试也要计入成本。timeout 后盲目重试三次，用户看到的是一次失败，账单里可能是多次调用。更合理的做法是：对可重试错误使用指数退避；对 model_not_found、invalid_api_key 这类配置错误不要重复请求；对 context_length_exceeded 先缩短上下文再重试。
成本控制的目标不是一味省，而是让钱花在有效证据和有效生成上。一个召回混乱、上下文臃肿、重试无节制的 RAG 系统，即使偶尔答对，也很难长期运行。
十二、从答非所问到可上线：一套可复用的调优流程
最后，把整个调优过程整理成一条可复用流程。
第一步，建立评测集。收集真实用户问题，不要只写理想问题。问题要覆盖概念、操作、错误码、版本差异、权限、计费、API 调用、部署和边界场景。每个问题标注期望答案来源。
第二步，检查文档质量。确认标题层级、表格、代码块、错误码列表、版本说明都能被正确解析。删除过期内容，标注版本差异，避免同一个问题在旧文档和新文档里有冲突答案。
第三步，调整分段。按语义结构切分，保证 chunk 能独立表达知识点。对标题、前置条件、字段解释、处理步骤保持完整。用抽样检查确认片段可读。
第四步，选择并验证 Embedding。用评测集看正确片段是否进入候选列表。切换 Embedding 后重建索引，记录索引版本。
第五步，调召回参数。先放宽 TopK 看能否找全，再逐步调整相似度阈值控制噪声。不要在召回还不够时过早提高阈值。
第六步，引入混合检索和重排。技术文档优先测试混合检索，错误码和配置项尤其需要关键词信号。对于相似章节多的问题，用 Rerank 提升排序稳定性。
第七步，检查上下文拼接。打印最终 prompt，确认正确证据进入上下文且没有被截断。控制系统提示词、聊天历史和片段数量。
第八步，处理接口错误。把 model_not_found、timeout、rate_limit、context_length_exceeded、invalid_api_key 分别归因，不要混在“知识库不准”里。模型路由、Base URL、API Key、网关日志都要纳入排查。
第九步，建立日志和审计。记录 query、chunk、score、rerank、上下文、模型、耗时和成本。用数据观察每次调参的效果。
第十步，灰度上线。先给内部团队使用，再开放给小范围真实用户。对低置信度问题允许回答“知识库中没有足够信息”，不要强行编。上线后持续收集失败样本，定期回归评测。
这套流程跑下来，我们的产品文档知识库从“看起来能答但经常偏”，变成了“知道什么时候能答、什么时候该拒答、出错时能定位”。这比单纯追求每个问题都说得漂亮更重要。
Dify 的价值在于把 RAG 应用搭建门槛降了下来，但低门槛不等于免调优。知识库问答的质量，来自文档、Embedding、向量引擎、召回率、相似度阈值、重排、上下文拼接、模型路由、日志审计和成本控制共同作用。任何一个环节含糊，最终都会以“答偏”的形式暴露出来。
所以，当 Dify 知识库问答不准时，不要第一反应就怪大模型。先沿着链路问几个问题：文档被正确解析了吗？分段能独立表达吗？Embedding 适合这类技术语料吗？向量索引完整吗？正确片段进 TopK 了吗？相似度阈值是否过严或过松？重排有没有把证据排上来？最终上下文里到底放了什么？接口层有没有 model_not_found、timeout 或 rate_limit？成本和延迟是否可控？
把这些问题逐个回答清楚，RAG 系统才会从一个“能演示的知识库”，变成一个“能上线的产品能力”。
