别再盲目迷信微调了，搞定私有数据其实靠的是这套 RAG 工作流

如果你直接把公司的 API 文档或者数据库丢给大模型，大概率会得到一个一本正经胡说八道的回答。很多人第一反应是“我要不要去微调（Fine-tune）一下模型？”，说实话，对于绝大多数开发者来说，微调既贵又慢，而且数据更新了你还得重新练一遍，性价比极低。

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

我最近在复盘一套生产级别的 RAG 架构时发现，大家最容易踩的坑就是把 RAG 想得太简单了。很多人以为只要把文档切片、做个向量检索就完事了，但实际在处理复杂的开发者文档时，效果往往差得离谱。

一个真正能用的 RAG 系统，不只是“查询 -> 检索 -> 回答”这么简单，它其实由两套独立的工作流组成：

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

这是决定 RAG 天花板的地基。

• 解析与清洗 (Parsing)： 别直接把 PDF 丢进去，PDF 里的表格和层级结构如果不处理好，检索出来全是乱码。
• 切片策略 (Chunking)： 这是一个极其考验经验的环节。切太大了，上下文里全是废话，浪费 Token 还没重点；切太小了，语义就断了。比如 API 文档，你得保证“限流规则”这一段被完整切出来，而不是被劈成两半。
• 向量化 (Embeddings)： 把切好的文本变成高维向量，让“请求频率”和“每分钟调用次数”在数学空间里能靠在一起。

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

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

• 混合检索 (Hybrid Search)： 这是我最想强调的一点。纯语义检索（Vector Search）在处理技术名词时经常翻车。比如用户搜 ERR_AUTH_401，语义模型可能觉得这只是个错误码，但关键词检索（Keyword Search）能精准命中。一定要把两者结合起来。
• 重排序 (Reranking)： 这是很多人的盲区。第一轮检索可能会找回 20 个片段，但 LLM 的上下文窗口有限，且信息密度有限。你需要用一个专门的 Reranker 模型对这 20 个片段进行精细打分，最后只把最强的 5 个喂给大模型。
• 上下文构建： 把系统提示词、检索到的精准片段、用户问题拼在一起，最后交给 LLM 生成答案。

这里有个核心逻辑大家一定要记住：如果检索阶段找错了文档，LLM 再强也救不了场。

我建议大家在做 RAG 评估时，要把“检索质量”和“生成质量”拆开来看。如果回答错了，先查是不是检索器（Retriever）没把东西找回来，再去查是不是模型（LLM）没读懂。

如果你想写一个高质量的 RAG 系统提示词，可以参考下面这个结构：

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

# Context
${retrieved_chunks}

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

# User Question
${user_query}

# Answer