私有知识库的正确打开方式是 RAG 工作流

把公司的 API 文档或数据库直接喂给大模型，往往会得到一本正经的错误答案。很多人第一反应是想微调模型，但对大多数开发者而言，微调成本高、周期长，数据更新后还需重新来过，性价比不高。

真正能让 AI 在实战中落地的，是 RAG（检索增强生成）。

在复盘生产级 RAG 架构时，常见的问题是把 RAG 想得过于简单，认为只要文档切片并做向量检索就完成了，但在处理复杂的开发者文档时，效果往往很差。

一套能用的 RAG 系统，远不止“查询 -> 检索 -> 回答”这三步，它由两条独立工作流组成：

一、知识准备（离线任务）

这是决定 RAG 效果上限的地基。

• 解析与清洗： 不要直接把 PDF 放进去。如果表格和层级结构没有处理好，检索得到的只会是碎片。
• 切片策略： 这是最考验经验的一环。切块过大，上下文中会混入大量无关信息，浪费 Token 且难以抓住重点；切块过小，语义会被截断。以 API 文档中的“限流规则”为例，需要确保完整的一段被切出，而不是被一分为二。
• 向量化： 将文本转换为高维向量，使得“请求频率”和“每分钟调用次数”在向量空间中能够彼此靠近。

二、实时检索（在线任务）

用户提问时，系统要完成以下动作：

• 混合检索： 这一点很重要。纯语义检索在处理技术术语时经常失误。例如搜索 ERR_AUTH_401，语义模型可能只是把它当作普通错误码，而关键词检索能够精准匹配。因此需要将两种方式结合使用。
• 重排序： 这是很多人会忽视的环节。第一次检索可能返回 20 个片段，但 LLM 的上下文窗口有限，信息密度也受限。此时需要使用专门的 Reranker 模型对这 20 个片段进行细致评分，最终只保留得分最高的 5 个送入大模型。
• 上下文构建： 将系统提示词、精准检索到的片段以及用户的问题拼接起来，然后交给 LLM 生成最终答案。

核心逻辑记住一条：检索阶段找错文档，LLM 再强也救不回来。

评估 RAG 时，把“检索质量”和“生成质量”分开看。回答错了，先查是不是检索器没把内容找回来，再查是不是模型没读懂。

想写一个高质量 RAG 系统提示词，可参考这个结构：

# Role
你是一个专业的文档助手，请严格基于提供的【参考上下文】来回答用户的问题。

# Context
${retrieved_chunks}

# Constraints
1. 如果【参考上下文】中没有提到相关信息，请直接回答“抱歉，在现有文档中未找到相关信息”，严禁编造任何事实。
2. 你的回答必须保持专业、简洁，并尽可能引用文档中的原话。
3. 如果问题涉及代码或 API 调用，请确保格式正确。

# User Question
${user_query}

# Answer