RAG(一)

什么是RAG它解决的什么问题大模型局限性一知识具有时效性可以外挂知识库让大模型知道实时信息局限性二训练数据来源于公共区域对公司的私有知识不感知可以外挂知识库让大模型知道公司的私有信息既具有的大模型能力又具备私有知识还能过数据隐私审查局限性三大模型不会对问题承认自己的茫然他会预测以下话术出现的概率最高而胡编乱造不保证准确性三种解法RAGfine-tuning上下文RAG检索增强生成每次用户提问时先从知识库里检索相关内容把内容一起发给模型让模型基于这些内容回答。用户问题 → 检索知识库 → 找到相关文档片段 → 塞进Prompt→ 模型回答优点 成本低知识库随时可更新回答可以追溯来源缺点 依赖检索质量检索不准则答案不准Fine-tuning微调用私有数据对模型做二次训练把知识烧进模型参数里。优点 模型对特定领域更懂语言风格可以定制缺点 成本高数百到数千美元训练耗时知识更新需要重训无法追溯来源鸡哥见过不少团队一开始就去搞微调结果花了大量时间和钱效果还不如好好调一下 RAG 的检索。上下文模型的上下文窗口越来越大Claude 200K TokenGemini 1M Token直接把整个文档塞进 Prompt。优点 操作简单不需要搭检索系统缺点 Token 成本高昂每次都要传完整文档有Lost in the Middle问题——超长上下文时模型对中间位置的内容注意力会显著下降文档超大时仍然放不下怎么选私有知识库问答文档可更新 →RAG首选 让模型更懂特定领域的语言风格 →Fine-tuning 文档量小几十页以内临时用一次 → 长上下文RAG的核心检索质量只有提升检索质量才能让你的模型具备实时性准确性高效性如何学习RAG认知篇 为什么需要RAG→ 架构全貌 → 跑通第一个应用 基础设施篇 选什么Embedding模型 → 向量数据库选型 →PGVectorvsQdrantvsMilvus文档处理篇 多格式加载与Metadata设计 → 分块策略 → 企业知识库构建 检索优化篇 向量检索的局限 → 混合检索双路召回→ 查询改写 后处理优化篇Reranker精排 → 上下文压缩 → 效果量化评估 高级RAGGraphRAG→ 多路召回融合RAG怎么搭建RAG的两条管道RAG 本质上由两条完全独立的管道组成执行时机完全不同Indexing Pipeline索引管道——离线执行一次性或定期重跑原始文档 → 加载 → 分块 → 向量化 → 存入向量库Query Pipeline查询管道——在线执行每次用户提问时触发用户问题 → [查询处理] → 检索 → [后处理] → 生成一个很重要的认知这两条管道完全解耦。 文档更新时只跑索引管道重新入库查询时只跑查询管道。这意味着知识库可以随时更新不影响线上服务。IndexingPipeline离线 ──────────────────────────────────────────────────────────────── 原始文档PDF/Word/HTML/DB/代码... ↓DocumentLoader格式解析Document原始文字Metadata ↓DocumentTransformer清洗分块ListTextSegment切块后的片段 ↓EmbeddingModel语义向量化ListEmbedding高维浮点向量 ↓VectorStore持久化存储 向量库PGVector/Qdrant/MilvusQueryPipeline在线每次提问 ──────────────────────────────────────────────────────────────── 用户问题自然语言 ↓[可选]QueryTransformer改写/扩展/路由 优化后的查询 ↓EmbeddingModel问题向量化 ↓VectorStore.searchTopK相似度搜索ListTextSegment候选结果通常10-20条 ↓[可选]RerankerCross-Encoder精排 ↓[可选]ContextCompressor块内噪声过滤 最终上下文通常3-8条高质量片段 ↓Prompt构建System检索结果用户问题 ↓ChatModel大模型推理 最终答案含来源引用RAG搭建之前的思考1.我要用哪个 Embedding 模型如果是纯中文或中英混合第一推荐是通义千问的 text-embedding-v3。原因很直接● 阿里自己训练的中文语义理解比 OpenAI 的模型强● 国内网络直接访问不用翻墙● API 价格便宜如果是纯英文text-embedding-3-smallOpenAI是主流选择效果稳定价格也不贵。如果对数据安全有要求不能调外部 API本地部署 BGE 系列bge-m3 或 bge-large-zh。效果和商业 API 差距不大但需要自己维护服务。模型 维度 适用场景 text-embedding-v3通义1024或2048可配 中文首选 text-embedding-3-smallOpenAI1536英文/通用 text-embedding-3-largeOpenAI3072高精度场景贵 bge-m3本地1024离线部署 bge-small-zh本地512资源受限场景2.我要用哪个向量数据库开发阶段 / 快速验证SimpleVectorStore内存Spring AI 内置的内存向量库不用装任何东西启动就能用。用它的场景做 Demo、验证流程、测试效果。不能用它的场景程序重启数据就没了生产环境绝对不能用。正式项目 / 中小规模PGVectorPostgreSQL 的向量扩展如果你的项目本来就在用 PostgreSQL加一个扩展就变成了向量数据库不用引入新基础设施。鸡哥见过的大多数企业内部 RAG 项目用 PGVector 就够了千万级文档块都没问题。运维成本低研发团队熟悉 SQL遇到问题好排查。用它的场景已有 PostgreSQL 的项目数据量千万级以下需要和关系型数据混合查询。大规模 / 高并发Qdrant 或 Milvus专门为向量搜索设计的数据库检索速度更快但引入了新的运维复杂度。用它的场景数据量亿级以上并发查询极高或者需要向量搜索的高级特性过滤、分片等。3.TopK 和相似度阈值怎么设TOPK优先使用五个阈值0.5-0.6。先把阈值设低确认入库的内容能被检索到再逐步提高到合理区间。4.怎么知道知识库跑通了知识库有的能根据知识库进行回答知识库没有的也不会胡编乱造措辞不同但语义相同的问题回答的不一样说明Embedding 模型对你的业务语言理解不够需要换模型或者调分块策略。Embedding 模型选型embedding的本质是将语义转换成空间坐标text-embedding-v3 是目前在中文企业项目里的第一推荐。为什么首先是中文效果。阿里在中文语料上做了大量专项训练在 C-MTEB 中文检索榜上的表现明显优于 OpenAI Embedding。测过同一套知识库换成通义千问 Embedding 后不改其他任何东西检索召回率提升很明显。其次是合规性。数据在阿里云国内节点处理不出境企业内部知识库项目完全没有合规顾虑。成本方面也有优势——通义千问 Embedding 的定价比 OpenAI 低很多大规模入库场景下差异相当显著。维度可以配置1024 或 2048建议默认用 1024效果和成本的平衡点在这里。维度不匹配——最高频的坑向量数据库在建表时需要指定向量维度。这个维度必须和你的 Embedding 模型输出的维度完全一致。哪怕差一个数字入库时就报错。在一个 RAG 系统里你可能有多个知识库、多个向量表。每个知识库的 Embedding 模型可以不同——只要同一个知识库内部保持一致就行。知识库A产品手册→ 用通义千问Embedding维度1024知识库B英文技术文档→ 用OpenAItext-embedding-3-small维度1536查询知识库A必须用通义千问模型 encode 问题 查询知识库B必须用OpenAI模型 encode 问题场景一某中小企业的内部知识库员工 ~500 人文档几千份主要中文内容没有数据合规特殊要求。通义千问 text-embedding-v3。效果好、成本几乎可以忽略、接入简单完全没必要搭本地推理服务。场景二某医院的病历问答系统患者数据不能出医院内网必须本地部署。BGE-Large-zh Ollama 本地推理纯离线。医院通常有存储但不一定有 GPUOllama 支持纯 CPU 推理虽然慢点但入库是批量操作接受。场景三快速验证一个 RAG Demo 给客户看时间紧两天内要有东西演示。OpenAI text-embedding-3-small没什么好想的最快最省事。