RAG 实战：给 AI 接上私有知识库的完整方案

上一篇我们聊了 Agent 动态路由——任务交接时怎么把控流向。这次换个方向聊一个大家问得最多的问题怎么让 AI 能回答你自己公司的文档、产品手册、内部 Wiki你可能试过直接把文档塞进 System Prompt结果 token 超限了。你也可能试过 Fine-tuning但数据更新一次就得重新训练。两条路都走不通——这就是 RAG 存在的原因。RAG 是什么一句话类比RAGRetrieval-Augmented Generation 先检索再生成。类比RAG 就像开卷考试。模型本身是那个能写文章的学生知识库是那一堆参考书。考试时不靠死记硬背而是先翻书找到相关段落再用自己的理解写答案。没有 RAG 的 AI 是闭卷考——它只能答它训练时见过的内容。为什么不直接 Fine-tuning这是大家最常问的问题。Fine-tuning 训练的是「风格和能力」不是「知识」。维度RAGFine-tuning知识更新改向量库秒级生效重新训练几小时到几天成本低API 向量DB高GPU 算力幻觉风险可溯源能引用原文模型可能「记错」适用场景私有知识、频繁更新专业语气、特定格式输出结论知识库类需求首选 RAG想让模型说话更像你们品牌才考虑 Fine-tuning。RAG 完整流程拆解RAG 分两个阶段索引阶段离线和查询阶段在线。索引阶段一次性/更新时 文档 → 分块(Chunking) → 向量化(Embedding) → 存入向量数据库 查询阶段每次对话 用户提问 → 向量化 → 相似度检索 → 取出 Top-K 段落 → 拼进 Prompt → LLM 生成回答第一关文档分块Chunking分块策略直接决定检索质量但大多数人第一次都搞错了。固定长度分块最常见但有问题fromimport# 最常见写法按字符数切分1000# 每块最多1000字符200# 相邻块重叠200字符防止语义断裂\n\n\n。 ❌ 常见错误chunk_overlap0→ 一个完整句子被切成两半检索时两半都不完整模型无法理解✅ 正确做法chunk_overlap设为chunk_size的 10%-20%→ 语义完整相邻块有重叠保护语义分块效果更好稍复杂fromimportfromimport# 按语义相似度自动切分不按字符数硬切percentile# 超过85%相似度阈值才切分85# 输出的每个 chunk 语义上都是完整的✅ 语义分块在技术文档、法律合同这类强结构文本效果明显更好❌ 但速度更慢每次都要调用 Embedding适合离线批量处理第二关向量化EmbeddingEmbedding 是把文本变成一串数字向量语义相近的文本向量距离更近。类比把每段文字映射到一个 1536 维的空间里「苹果手机」和「iPhone」在这个空间里距离很近和「橙子」距离远。选 Embedding 模型# 方案AOpenAI text-embedding-3-small性价比最高推荐fromimporttext-embedding-3-small# 1536维比 ada-002 便宜5倍# modeltext-embedding-3-large, # 精度更高贵3倍一般用不到# 方案B本地模型零成本但精度稍差fromimportBAAI/bge-m3# 多语言中文效果好devicecpu# 测试一下两段近义句向量距离应该很小如何重置密码忘记密码怎么办# 这两个向量的余弦相似度应该 0.9关键原则索引时用什么 Embedding查询时必须用同一个——不能混用。向量数据库选型数据库适用场景特点Chroma本地开发、原型验证零配置纯 PythonQdrant生产环境推荐性能好支持过滤Pinecone云服务快速上线全托管按量付费pgvector已有 PostgreSQL不用新增基础设施# Chroma 本地版开发用fromimport./chroma_db# 本地持久化my_knowledge_base# Qdrant 生产版fromimportimporthttp://localhost:6333my_knowledge_base第三关检索策略大多数 RAG 系统检索效果差不是因为 Embedding 模型不好而是检索策略太简单。基础检索相似度搜索# 最基础返回最相似的4个chunk如何申请年假4# 带分数能看到每个 chunk 的相似度0-1越高越相关如何申请年假4forinprintf相似度: {score:.3f} | 内容: {doc.page_content[:50]}...进阶检索MMR最大边际相关性❌ 纯相似度搜索的问题Top-4 可能都是在说同一件事高度重复✅ MMR 在保证相关性的同时最大化结果多样性# MMR 检索相关 不重复如何申请年假4# 返回4个20# 先取20个候选再从中选4个最多样的0.7# 0最多样1最相关0.5-0.7 效果最好混合检索向量 关键词生产推荐fromimportfromimport# 关键词检索BM25对专有名词、型号特别有效4# 向量检索k4# 混合各取 50%0.50.5# 可调专有名词多时提高 BM25 权重iPhone 14 的电池容量是多少# BM25 精准匹配「iPhone 14」向量找到语义相关段落两者互补第四关完整 RAG Chain 搭建把前面所有环节串起来搭一个可以直接上生产的 RAG Chainfromimportfromimportfromimportfromimportfromimport# 1. 初始化组件gpt-4o-mini0text-embedding-3-small./chroma_dbmy_knowledge_basemmrk4fetch_k20# 2. RAG Prompt关键要求模型基于上下文回答你是一个专业的知识库助手。请根据以下检索到的上下文回答用户问题。**规则**- 只基于提供的上下文回答不要编造- 如果上下文中没有相关信息直接说「根据现有资料我找不到这个问题的答案」- 回答要简洁直接引用原文时用引号**检索到的上下文**{context}**用户问题**{question}# 3. 格式化检索结果多个 chunk 拼在一起defformat_docsdocsreturn\n\n---\n\nf[来源: {doc.metadata.get(source, 未知)}]\n{doc.page_content}forin# 4. 组装 ChainLCEL 写法context# 检索 → 格式化question# 问题直接传入# 5. 使用我们公司的年假政策是什么print带来源引用的版本fromimport# 同时返回答案和来源文档answersource_documents# 保留原始 chunk年假怎么申请print答案answerprint\n引用来源forinsource_documentsprintf - {doc.metadata.get(source, 未知)}: {doc.page_content[:80]}...第五关文档入库工程化把文档批量处理入库这才是生产中最麻烦的部分importfromimportfromimportfromimportdefload_documentsdocs_dir: strlist支持 PDF、Word、TXT、Markdown 混合入库.pdf.docx.txt.mdforin*ifinstr# 给每个 chunk 打上来源标记forinsourcefile_pathstrprintf✅ 已加载: {file_path.name} ({len(docs)} 段)returndefbuild_knowledge_basedocs_dir: str, persist_dir: str一键构建知识库# 加载文档printf\n共加载 {len(raw_docs)} 个文档片段# 分块800150\n\n\n。printf分块后共 {len(chunks)} 个 chunk# 向量化入库分批处理避免 API 限流text-embedding-3-small# 批量处理每批 100 个100Noneforinrange0lenifisNoneknowledge_baseelseprintf进度: {min(ibatch_size, len(chunks))}/{len(chunks)}printf\n✅ 知识库构建完成共 {len(chunks)} 个向量return# 使用./docs./chroma_db常见坑踩过才知道坑1Chunk 太大检索噪音多❌chunk_size3000一个 chunk 包含了太多无关内容检索出来的段落「离题」✅ 推荐chunk_size600-1000回答简单问题用小 chunk需要完整上下文时用k6坑2相同文档重复入库# ❌ 每次启动都重新入库向量越来越多# ✅ 检查是否已有数据有就直接加载ifandprint加载已有向量库elseprint新建向量库坑3提问语言和文档语言不一致❌ 文档是中文用英文查询 → 相似度打分错乱✅ 用多语言 EmbeddingBAAI/bge-m3或在检索前把提问翻译成文档语言坑4Top-K 太少关键信息检索不到❌k2覆盖太少问题涉及多个段落时漏答✅ 生产环境推荐k4~6token 允许的情况下宁多不少坑5Prompt 没有「只基于上下文回答」约束❌ 没加限制 → 模型结合自己训练知识和检索结果混答无法区分哪些是你的文档里有的✅ 明确写「只基于以下上下文没有就说没有」——这一句能把幻觉降低 80%发布前自查清单Embedding 模型索引和查询时一致chunk_overlap≥chunk_size的 10%每个文档 chunk 打了来源 metadataPrompt 中有「只基于上下文」约束检索数量k≥ 4重复入库已做幂等检查混合检索BM25 向量用于专有名词多的场景总结这篇我们从零搭了一套完整的 RAG 私有知识库方案分块决定上限chunk_size800overlap150语义分块效果比固定分块好 20-30%Embedding 选型开发用text-embedding-3-small中文内容用bge-m3检索策略分层基础用相似度去重用 MMR专有名词多用混合检索Prompt 约束是关键「只基于上下文」这一句能把幻觉降低 80%工程化必做入库幂等检查文档打 metadata 来源批量处理防限流理解 RAG 的核心是检索质量 生成质量——答案已经在文档里了问题是能不能找对。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】