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-06-17-ai-knowledge-base-product-design：
- 用户调研数据揭示RAG的真实价值定位：87%的知识工作者经常找不到已存储的文档内容，63%的人曾因”找不到”而重复下载或重新整理资料。这说明RAG知识库解决的核心问题不是”存储容量”，而是”认知鸿沟”——传统文件系统的命名/路径检索无法匹配人类的语义记忆模式
- 本地RAG到云端产品的关键转折点：作者用Ollama + Dify + 本地模型验证了”文档可对话”的技术可行性，但暴露两个致命缺陷：可用性（关机后手机无法访问）和协作性（每人需重复搭建环境）。这个转折说明RAG的产品化门槛不在检索精度，而在交付形态——多端访问、多用户协作、零安装部署
- 技术选型的四维评估框架：成本40%、可扩展性25%、部署维护复杂度20%、文档社区15%。作者对比Cherry Studio、MaxKB、WeKnora、Dify后选择Yuxi，核心原因是”完整REST API + Docker三步部署 + 开源无调用限制”，体现了RAG产品落地时工程可交付性优先于算法先进性
- 用户行为驱动的双模式检索设计：内测发现70%的用户在30秒内希望不经过对话就能直接搜索。因此产品设计为”快捷检索（关键词）+ 智能助理（对话式）“双模式，前者满足”我知道我要什么”的精确查询，后者满足”我模糊记得有相关概念”的探索式场景
- RAG产品的成本优势实证数据：20人团队月成本约300元（服务器50元+API 200元+存储30元），人均15元/月，仅为Notion AI（1400元/月）或飞书知识库（1000元/月）的21%-30%，且数据完全自主可控
- 关键业务指标设计：知识检索时间<30秒、问答采纳率>80%、文档复用率>60%（避免僵尸文档）、周活渗透率>30%。这些指标把RAG系统的价值从”检索准确率”扩展到”知识激活效率”和”组织使用深度”
- 产品哲学的核心洞察：“知识工作者真正的痛苦不是’找不到’，而是’找到了也无法对话、无法提炼、无法让沉睡的文字重新开口说话’“。这把RAG的定位从”检索工具”升级为”激活装置”——用户打开知识库的动机往往不是”浏览”，而是”求救”
来自 2026-05-27-ai-ecommerce-kol-guide：
- RAG在电商导购场景的核心应用：在KOL蒸馏AI导购中，RAG用于构建达人专属测评知识库。每个KOL维护独立的测评库（向量化存储），包含历史测评的所有结构化观点、原文摘录、商品评分，支持根据用户意图向量检索Top-K最相关内容
- RAG作为”测评真实性的合规底线”：测评知识层采用”独立的结构化存储 + RAG检索增强生成方式”，确保生成的测评摘要100%基于真实测评内容，避免捏造观点。这把RAG从”检索增强能力”升级为”防止AI捏造达人观点的工程保障”
- RAG的合规闭环设计：生成时进行置信度校验（不确定的内容不输出）+ 事后抽检（系统抽样人工复核）+ 所有生成内容添加”AI生成”标识 + 测评摘要标注”基于达人过往测评整理” + 回复中附上测评原文链接。这套机制是RAG走向高合规场景（医疗/金融/电商代言）的工程模板
- 多模态结构化解析是RAG测评库的供给侧：通过多模态大模型自动完成达人测评视频、图文内容的结构化解析，批量提取商品评价维度、正负向观点、核心判断原句。这把RAG的数据准备从”文档切片+Embedding”扩展到”视频/图文结构化抽取+维度归一化”
- RAG与Agent/Skills分层的协作模式：在Agent 9步处理流程中，“任务拆解与编排”会调度独立的”测评检索Skill”通过RAG拉取KOL测评，再调度”风格复刻Skill”注入达人口吻——RAG不再是独立产品，而是Agent调度链路中的一个原子Skill
来自 2026-05-30-ai-rag-production-100-yuan：
- 100元成本验证生产级RAG可行性：天涯轩在100元RAG实验中证明”AI代码生成 + 国内大模型API”路线在预算层面可行。全链路API花费约100元（含Embedding批量写入 + 多轮对话测试 + Rerank调用），使用通义千问qwen3.6-plus对话模型和text-embedding-3-large向量模型（实际输出1024维）
- 生产级RAG的完整交付物定义：不只是Demo，而是带评测与可观测性的平台——后端（Node.js + Fastify 5 + LangGraph十节点DAG + SSE流式）+ 前端（Vite + React 19 + TailwindCSS 4，四面板：对话、文档、评估、配置）+ 基础设施（Milvus 2.5.x稠密+BM25稀疏混合检索、PostgreSQL 16、Redis 7、Attu管理界面）+ 评测指标（命中率、MRR、忠实度、相关性）
- 静默失败是RAG最危险的敌人：修复14个Bug中，最耗时的不是报错类故障，而是”无报错但不工作”的静默失败——检索0条、向量维度不一致（Schema定义3072维但实际API返回1024维）、API地址被忽略、阈值过滤全部丢弃。生产RAG的上限由Embedding兼容性、向量库Schema、阈值与评测闭环决定，而不是Prompt写得多漂亮
- 国内大模型接入需要实测验证：不能照搬海外经验。向量维度必须实测（通义text-embedding-3-large实际1024维非3072维）、相似度阈值必须基于自家模型+自家语料实测分布（通义v3的COSINE分数常在0.2–0.45，不能用OpenAI经验值0.7否则全部被过滤）、SDK配置写法必须用独立脚本验证（LangChain对国内API需用configuration.baseURL不是baseUrl）
来自 2026-07-05-woshipm-enterprise-knowledge-graph-6-lessons：
- RAG 与企业级知识图谱的边界被进一步拉清：普通 RAG 解决的是“从文档里找答案”，适合检索相关段落并让模型综合；企业级知识图谱解决的是“让知识被结构化治理、持续复用、稳定推理”，适合处理产品、地域、客群、互斥规则、有效期和证据链等业务判断。
- RAG 在十几万篇分散文档场景下会遇到治理瓶颈：当知识来源跨系统、跨省份、跨业务线时，只靠切片和向量化无法回答“这条知识是什么类型、和哪个产品有关、是否有效、是否冲突、能否被客服和 Agent 稳定复用”。这说明 RAG 的供给侧必须补上知识准入、字段标准和规则治理。
- 知识图谱可作为 RAG 的结构化增强层：文档中的活动、规则、限制、权益、渠道和时间若只停留在文档切片里，问答偶尔能命中；一旦挂回具体产品、客户、地域和有效期，就能支持冲突检查、重复识别和资格判断，成为 RAG 之外的可信推理基础。
- 证据链是 RAG 走向企业业务判断的关键验收项：好的系统不能只返回答案，还要展示关联节点、使用关系、证据切片、关键条件、过期判断和互斥判断，防止把不同文档规则串错或把过期活动当成有效活动。
来自 2026-07-05-juejin-context-engineering-harness：
- RAG 是上下文工程的业务资料注入层：文章把“只用通用大模型，不注入本地业务资料”列为 LLM 落地四个高频坑之一。通用模型不懂企业内部代码、业务规则和产品资料，容易生成看似合理但脱离现场的内容；正确做法是用 RAG 检索本地文档、代码库和业务规则作为补充上下文。
- RAG 必须进入 Harness 闭环，而不是停在检索拼接：文章的三阶段链路是 Prompt → Context → Harness。RAG 解决“模型看见业务资料”，但线上系统还要用 Harness闭环工程 校验格式、成本、合规和业务目标。也就是说，RAG 提供依据，Loop/围栏负责验收，二者结合才是可上线系统。
- 本地业务资料是减少幻觉的前置条件，但不是充分条件：即使检索到了资料，模型仍可能输出多余文字、错误 JSON 或越界方案，因此 RAG 与 Loop Engineering、MCP 技能和安全围栏需要作为一条链路设计。
来自 2026-07-07-woshipm-enterprise-kg-hybrid-architecture：
- RAG 与图数据库的分工更清晰：当前混合架构的本质是图数据库负责“认准对象”，RAG 负责“找原文内容”，大模型负责“组织答案”。这说明 RAG 不是被知识图谱替代，而是和图谱层分工协作。
- 企业 RAG 需要多库混合，而非单一向量库：MongoDB 保存原文、切片、抽取字段、证据链、审核和版本；Milvus 做语义召回；Elasticsearch 做关键词精确命中；NebulaGraph 做产销品标准实体与别名关系。RAG 的上下文来源来自这些系统共同供给。
- 规则能被回答，不代表已经结构化入图：办理条件、限制规则、FAQ、客服口径可能仍在 MongoDB 文档切片或抽取字段里，由 Milvus/ES 召回后交给大模型总结。这提醒 RAG 产品经理不要把“能答”误判为“规则已治理完成”。
- 先归一对象再召回原文是企业问答关键链路：产销品别名图谱 把“摄像头/监控”归一为“天翼云眼”，再用 RAG 召回文档，能明显提升问答命中率与稳定性。
来自 2026-07-11-woshipm-enterprise-rag-knowledge-layering：
- RAG 在五层架构中的角色被精确限定为”找相似文档 + 回填原文证据”：这篇素材把企业知识拆成主数据/实体、关系、属性、规则四类，再加弱结构文档切片，共五层。RAG（Milvus 语义检索 + MongoDB 原文回填）承担的是”召回相关政策、活动说明、客服口径”和”回填答案依据原文片段”，而”两个产品是否互斥”这种确定性关系必须交给图数据库，不能靠向量相似度判断。这把”RAG 能答一切”的误区收敛为”RAG 负责语义与证据，图库负责确定性关系”。
- 向量库的天然盲区：无法判断确定性业务关系：“向量库可以找到和这份文档内容相似的文档，但它不知道两个产品是否互斥。“这句话点明了纯 RAG 在企业业务判断中的根本局限——语义相似 ≠ 业务规则成立，互斥/依赖/适用/覆盖这类关系必须结构化落库。
- 弱结构文档才是 RAG 的正确供给侧：政策原文、客服话术、培训材料、FAQ、投诉口径、会议纪要这类”语言自然、颗粒度不一、结构不稳定”的内容，正是应该走”切片 → 向量化 → 存 Milvus，原文存 MongoDB，切片通过 ID 关联图谱节点”的路径，不该强行抽成图。这给 RAG 的数据准备划了清晰边界：结构化的进图，弱结构的进向量库。
- 不是所有 RAG 都要上图数据库：当知识量少、关系不复杂、规则频繁变化尚未稳定、缺乏图库运维能力或人工审核机制时，可先用 Milvus 做轻量化 Vector Graph RAG（实体、关系、切片都向量化，用 ID 引用串联），待关系稳定后再逐步沉淀到图数据库。这是对”企业级 RAG 一定要配知识图谱”的务实纠偏。
来自 2026-07-16-woshipm-ai-landing-methodology-finance-to-pm：
- RAG 在”先规则后智能”场景中的验证角色：作者用 Coze 搭了一个财务制度问答 Agent 原型，把散在制度文件、发薪 SOP 和报销规则里的显性规则整理成 RAG 知识库，让员工能用自然语言查询薪资和报销规则。这个实践验证了 AI落地三大逻辑 中”先规则后智能”的关键发现——知识库里规则越干净，RAG 回答就越稳；规则本身模糊的部分（如需要人工判断的特例），交给 AI 反而会放大混乱。RAG 在规则清晰但执行繁琐的运营场景中，价值不是”替代客服”，而是”把规则咨询从翻 5 个系统变成自然语言问答”。
- RAG 供给侧的质量决定 AI 输出上限：财务制度问答 Agent 的实践证明，RAG 系统的上限不在检索精度或模型能力，而在知识库供给侧的质量——制度文件、SOP 和报销规则的结构化程度和一致性，直接决定了 RAG 回答的稳定性和可用性。这与”数据治理比模型调参更重要”的底层逻辑一致。
《做了五年PM，我是怎么开始接触AI方向的》（产品经理林景贤，2026-07-16）
一位被裁的传统PM选择RAG作为第一个AI产品原型项目的原因很务实：技术上有现成框架（LangChain和LlamaIndex），不需要写代码也能搭起来。但重点不是搭起来——重点是要经历一次完整的产品思考：这个RAG要解决什么问题（选一个真实的小痛点）、用什么数据（数据质量怎么评估）、“好的回答”长什么样（定义具体标准）、找同事试用收集反馈迭代。技术部分可以不碰或只做最轻量配置，但产品决策必须自己做：选什么数据、定义什么标准、怎么判断”够好了”。
最打动人的面试回答案例：候选人说”我自己搭了一个RAG系统，把团队的会议纪要和产品文档丢进去，做了一个内部问答工具。准确率不高，大概75%。但我的同事们开始真的用它了，每天有5-8人在用。我在收集他们的反馈，下一版重点优化搜索召回。“——没有术语、没有方法论，但一个AI PM该有的思考方式全部在里面。面试官不怕做得不完美，怕的是什么都没做过。
关键判断：你需要一个项目来证明自己”懂AI”——一个你自己跑通的RAG原型，比十门课程证书更有说服力。RAG作为入门项目不是因为技术最简单，而是因为它强制要求PM做出一系列只能自己做、AI无法代劳的产品决策。
学习重点（面试高频考点）
1. 向量数据库选型
- Milvus：开源高性能向量数据库
- PGVector：PostgreSQL 向量扩展
- Chroma：轻量级本地向量库
- Pinecone：云原生向量数据库服务
2. 文档管道优化
- 抽取：不同格式文档的解析策略
- 转换：文本清洗和标准化
- 加载：批量导入和增量更新
3. 索引构建策略
- 索引类型选择
- 分片和分区
- 性能调优参数
4. 查询优化方法
- 查询重写
- 多轮检索
- 结果排序
- 上下文压缩
实用信息
典型应用场景
- 企业内部知识库问答
- 客服机器人
- 文档智能检索
- 法律/医疗专业问答
- 产品手册查询
开发工具
- Apache Tika：强大的文件解析器
- LangChain4j：Java RAG 框架
- Spring AI：Spring 生态 RAG 支持
- Dify：低代码 RAG 平台
不同素材中的观点（补充）
- 2026-07-17-woshipm-course-consulting-assistant-3-iterations：课程咨询助手说明 RAG/知识库失败常常不是“召回算法不行”，而是运营与架构缺位——多源课程资料版本冲突、把实时状态问题仍丢给文档检索、把“上传文件”当一次性上线动作。建议拆成 控制知识库（稳定规则与禁承诺）与 证据知识库（可变事实 + 负责人/版本/有效范围）；实时状态改走业务查询（MCP），材料走解析 Skill。无更新责任时，更强模型只会生成更流畅的过期错误答案。