RAG 知识库
Retrieval Augmented Generation，检索增强生成技术，让 AI 基于特定知识回答问题
简介
RAG（检索增强生成）是一种结合检索和生成的 AI 技术架构。它通过从外部知识库检索相关信息，再将检索结果提供给大模型作为上下文，使大模型能够基于特定知识生成更准确的回答。
核心工作流程
企业文档 → Embedding 向量化 → 向量数据库存储
↓
用户提问 → Embedding 向量化 → 检索相似文档 → 大模型综合回答
关键技术组件
1. 文档处理管道
- 文档加载：支持 PDF、Word、Excel、PPT 等多种格式
- 文本切分：按语义或固定长度切分文档
- 元数据提取：标题、作者、日期等信息
2. Embedding 向量化
- 将文本转换为高维向量
- 语义相似的文本在向量空间中距离相近
- 支持多种 Embedding 模型
3. 向量数据库
- 高效存储海量向量
- 支持近似最近邻（ANN）检索
- 可扩展的索引结构
4. 检索策略
- 相似度检索
- 混合检索（关键词 + 向量）
- 重排序机制
- 结果融合
不同素材中的观点
来自 2026-04-29-yupi-ai-guide-core-concepts：
- RAG 是检索 + 生成两阶段技术
- 利用外部知识库给 AI 补充知识
- 回答更准确，减少幻觉
- 16 个核心概念之一
来自 2026-04-29-yupi-ai-guide-programming-tech：
- 构建企业自己的问答系统或客服
- 基于企业真实数据作答，更准确贴合实际
- 是 AI 编程开发的四大核心业务领域之一
来自 2026-05-17-ai-pm-interview-claude-workflow：
- 个人也应该给自己建RAG知识库，而不只是帮公司做。简历是第一份语料、项目复盘文档是第二份、面试转录是第三份、笔记是第四份
- 当这些语料持续喂给Claude，它从通用助手变成个人面试教练——知道你做过什么项目、踩过什么坑、答崩过哪道题
- “为什么选RAG不选微调”是AI PM面试中被问频率最高的题之一（38场面试中被问5次以上），说明RAG vs 微调的选型判断是行业共识级考点
- 搭建个人AI教练的成本是0元，核心是持续积累结构化语料
来自 2026-05-17-pm-ai-knowledge-base-design-practice：
- 本地RAG已经足以验证“文档可对话”的核心价值，但一旦要满足手机访问和多人协作，就必须从单机实验升级为云端产品
- 知识库产品的关键不只是“检索到段落”，而是把语义理解能力接入文件管理、权限、上传下载和多端访问等完整产品流程
- 作者用Ollama + Dify + 本地模型做了原型验证，最终选择带REST API和Docker部署能力的Yuxi，体现了RAG从技术方案走向产品化落地的路径
- 在20位知识工作者的非正式调研中，87%经常找不到已存文档内容、63%会因为找不到而重复整理资料，这说明RAG知识库首先解决的是知识可达性与复用率问题
来自 2026-05-21-woshipm-ai-knowledge-base-product-design：
- 这篇素材把 RAG 知识库的问题定义进一步明确为“语义理解缺失导致的知识不可达”：用户真正痛的不是没存资料，而是资料虽然存在却无法按问题意图被找回
- 本地 RAG 只能证明“文档可对话”，但要成为产品还必须补上多端访问、多人协作、权限治理、上传下载与检索双模式等完整系统能力
- 作者用成本40% / 可扩展性25% / 部署维护复杂度20% / 文档社区15%的权重做技术选型，说明 RAG 产品落地不仅是模型问题，更是工程可交付性与组织适配问题
- 在20位知识工作者的非正式调研中，87%经常找不到已存文档内容、63%会因找不到而重复整理，说明RAG知识库首先解决的是知识复用率与可达性问题
来自 2026-05-18-woshipm-ai-knowledge-management-design-practice：
- 这篇素材进一步把RAG知识库的价值从“回答问题”推进到“重建知识可达性”：用户真正痛的不是没存资料，而是资料命名缺乏语义、导致无法按意图找回
- 作者先用Ollama + Dify + 本地模型验证了RAG对文档问答的可行性，但很快暴露出单机方案无法支撑手机访问、多人共享和免安装使用，说明RAG产品的真正门槛在交付形态而不只是检索效果
- 从产品化视角看，RAG系统必须接入文件上传下载、用户认证、权限治理、移动端体验和API能力，才能从“桌面盆栽”变成组织级知识基础设施
- Yuxi之所以胜出，不是因为概念上更先进，而是因为REST API、流式输出、Docker部署和知识图谱/向量检索结合，更适合把RAG能力嵌入完整业务流程
来自 2026-05-18-woshipm-ai-pm-interview-2-questions：
- 本文把 RAG 放进 AI PM 面试的智能客服幻觉治理场景中，强调“用 RAG”不是完整答案，只是“四层防火墙”的第二层“给 AI 找课本”
- RAG 要真正降低幻觉，前提是产品手册、FAQ、退款指南等知识库本身结构化、准确、可维护；如果知识库内容错误，模型只是更有依据地答错
- 面试官常会追问“怎么确保 RAG 检索到的内容准确”“知识库本身有错误怎么办”，这说明 RAG 选型能力必须和知识库治理、来源标注、人工反馈、线上监控一起表达
- 智能客服场景中的完整闭环是：边界约束先决定什么不能答，RAG 决定能答时依据什么答，人工错题本决定错了如何改，监控指标决定线上何时预警
来自 2026-05-27-woshipm-ai-ecommerce-kol-agent：
- RAG 在电商 AI 导购场景被升级为”测评真实性的合规底线”：Elaine.H 的”达人帮你挑”PRD 把测评知识层定义为”独立的结构化存储 + RAG 检索增强生成方式，确保生成的测评摘要 100% 基于真实测评内容，避免捏造观点”。这把 RAG 从”检索增强能力”升级为”防止 AI 捏造达人观点的工程保障”，是 RAG 价值的一次重要扩展
- RAG 的合规闭环：置信度校验 + 事后抽检 + 来源标注：本文给出 RAG 在面向 C 端用户的内容生成场景中的完整合规设计——生成时进行置信度校验（不确定的内容不输出）、事后抽检（系统抽样人工复核）、所有生成内容添加”AI 生成”标识、测评摘要标注”基于达人过往测评整理”。这套机制比单纯”用 RAG”更进一步，是 RAG 走向高合规场景（医疗/金融/电商代言）的工程模板
- 多模态结构化解析是 RAG 测评库的供给侧：本文提到”多模态大模型能力已实现商用落地，可自动完成达人测评视频、图文内容的结构化解析，批量提取商品评价维度、正负向观点、核心判断原句”——这把 RAG 的数据准备从”文档切片+Embedding”扩展到”视频/图文结构化抽取+维度归一化”，是 RAG 在 UGC/PGC 内容驱动场景的关键基础设施
- RAG 与 Agent / Skills 分层的协作模式：在 Agent 9 步处理流程中，“Step6 任务拆解与编排”会调度独立的”测评检索 Skill”通过 RAG 拉取 KOL 测评，再调度”风格复刻 Skill”注入达人口吻——RAG 不再是独立产品，而是 Agent 调度链路中的一个原子 Skill，这是 RAG 在多技能 Agent 架构下的标准位置
来自 2026-05-31-woshipm-100rmb-production-rag：
- 100 元人民币可搭出生产级 RAG 平台：Claude Code 生成方案与代码 + 通义千问（qwen3.6-plus 对话 + text-embedding-3-large 向量）提供推理能力，全链路 API 花费约 100 元。系统包含多格式文档入库、Milvus 混合检索（稠密 1024 维 + BM25 稀疏）、LangGraph 十节点状态机、评测面板（命中率/MRR/忠实度/相关性）与企业级前端
- 生产级 RAG 的核心闭环：classify → decompose/rewrite → HyDE（可选）→ retrieve → rerank → compress → generate → evaluate，评估不通过可回退重写。单轮”检索 + 生成”在复杂问题上容易漏召回或幻觉，分类、HyDE、Rerank、自纠正与置信度评估构成可调优闭环
- 真正的敌人是静默失败：14 个 Bug 中最耗时的不是明确报错，而是检索 0 条、配置被忽略、向量维度 silently mismatch。生产 RAG 的上限由 Embedding 兼容性、向量库 Schema、阈值与评测闭环决定，而不是 Prompt 质量
- 四层排查策略（可复用）：存储层（Milvus count / PostgreSQL 一致性）→ 向量层（vector length / 索引存在性）→ API 层（独立脚测 Base URL / 延迟 / 维度）→ 管道层（retrieve 条数与 score / 阈值与 Rerank），用 A/B 最小脚本做对比测试一锤定音
来自 2026-05-27-通过codex解析Agent工作流程：
- RAG 解决的三大核心问题被清晰归纳为：知识过时（模型知识停在训练截止日）、记忆容量限制（长文档突破上下文窗口）、幻觉（AI 凭空编造）——这三个问题的优先级排列方式与产品经理实际评估 RAG 是否该引入的决策路径一致
- 普通知识库 vs 向量知识库的区分用了一个生动比喻：普通库是”书架模式”，只能按关键词找，容易漏；向量库是”智能索引员”，提前把文本转成数字指纹（向量），通过语义匹配找到意思相近的内容。这个对比对非技术人员理解 RAG 的价值非常直观
- RAG 工作流程的完整闭环被拆解为：文档分片 → 向量化 → 相似度比对 → 分片召回 → 拼成增强版提示词 → 模型基于材料作答——其中”巧妙绕过了窗口限制”这一点是很多技术文章容易忽略的 RAG 设计优势
- Codex 中 RAG 的实际使用方式被演示为：创建向量知识库 → 导入长文档 → 提问时系统自动调用知识库内容作答，且明确指出”事实来源来自知识库文件，最终表述经过 LLM 总结”——这个”事实来源 vs 最终表述”的分离是理解 RAG 产品责任归属的关键认知
来自 2026-05-31-notebooklm-x-gemini：
- NotebookLM 是 RAG 架构在个人知识管理场景的典型落地：与企业级 RAG 不同，NotebookLM 面向个人用户，让用户上传 PDF、网页、YouTube 视频等资料后，仅基于这些资料回答问题，并精确标注每句话的出处（如”这句话来自第 4 份文件第 3 页”）。这验证了 RAG 不仅适用于企业场景，个人知识管理同样是高价值落地场景
- RAG + 推理模型的分层架构：NotebookLM（RAG 层）负责精准检索，Gemini（推理层）负责深度分析——这种”记忆 + 思考”的分离是 RAG 架构从”工具”走向”工作流”的关键一步。把外部报告和个人资料同时放入 NotebookLM，再用 Gemini 问”这份报告对我有没有用？“是 RAG 在个人知识管理中的高阶用法
- RAG 产品效果取决于输入质量：“这招准不准，取决于你的内部资料有没有先准备好”——RAG 检索的上限是输入资料的质量和覆盖面，这与企业 RAG 中”知识库内容错误，模型只是更有依据地答错”的结论一致
学习重点（面试高频考点）
1. 向量数据库选型
- Milvus：开源高性能向量数据库
- PGVector：PostgreSQL 向量扩展
- Chroma：轻量级本地向量库
- Pinecone：云原生向量数据库服务
2. 文档管道优化
- 抽取：不同格式文档的解析策略
- 转换：文本清洗和标准化
- 加载：批量导入和增量更新
3. 索引构建策略
- 索引类型选择
- 分片和分区
- 性能调优参数
4. 查询优化方法
- 查询重写
- 多轮检索
- 结果排序
- 上下文压缩
实用信息
典型应用场景
- 企业内部知识库问答
- 客服机器人
- 文档智能检索
- 法律/医疗专业问答
- 产品手册查询
开发工具
- Apache Tika：强大的文件解析器
- LangChain4j：Java RAG 框架
- Spring AI：Spring 生态 RAG 支持
- Dify：低代码 RAG 平台