上一篇我写 RAG不想把它讲成“给 AI 接一个知识库”。因为知识库只是资料放在哪里RAG 真正要解决的是当 AI 给出一个答案时我们能不能知道它依据了哪段材料、有没有遗漏限制条件、能不能在证据不足时拒答。但如果继续往下讲 RAG很快就会遇到一堆术语Embedding、Chunk、Vector DB、BM25、Reranker、Citation、Faithfulness、RAG Eval……这些词如果直接堆出来文章会很像技术名词表。读者看完还是不知道它们到底在 RAG 系统里解决什么问题所以这一篇不写代码不写复杂架构只做一件事把 RAG 里的核心术语翻译成人话并说明每个组件在“证据链”里负责什么。如果把 RAG 看成一条可信回答链路它大概是这样原始文档 ↓ 清洗 / 解析 ↓ Chunking ↓ Embedding ↓ 向量检索 / BM25 检索 ↓ Hybrid Search ↓ RRF 融合排序 ↓ Reranker 精排 ↓ Final Evidence ↓ LLM 基于证据生成回答 ↓ Citation / Faithfulness / Abstention ↓ RAG Eval这条链路看起来很长但它其实只服务一个目标让 AI 的回答从“看起来对”走向“有证据、可追溯、可验证”。1. Document原始资料Document就是进入知识库的原始资料。它可以是公司制度 PDF、产品说明书、客服 SOP、GitHub README、技术文档、Markdown 博客、简历、订单规则、FAQ也可以是数据库里的业务记录。Document 解决的是 RAG 里最基础的问题系统到底从哪里拿事实如果没有外部资料模型只能依赖参数记忆。它可能知道一些通用知识但不知道你的公司政策、项目文档、订单状态、内部流程、用户简历。所以 Document 是 RAG 的原料。但原始文档不能直接塞给模型。原因很简单太长。太乱。格式复杂。版本不清楚。里面可能有页眉、页脚、目录、广告、水印、重复段落。有些信息已经过期。有些信息不属于当前用户或当前租户。所以进入 RAG 系统的第一步不是 embedding也不是向量库而是文档治理这份文档是谁的、从哪里来、什么时候更新、属于哪个业务线、是否有效、用户有没有权限看。一句话总结Document 是 RAG 的事实来源但原始文档本身还不是可用证据。2. Chunk证据片段Chunk就是把大文档切成一小段一小段方便检索和引用。很多人会把 chunking 理解成“把长文切短”比如每 500 tokens 切一段重叠 50 tokens。这个理解太粗。真正好的 chunk不只是短而是要成为一个“证据单元”。比如一份退款政策里有这样一段定制商品非质量问题不支持七天无理由退货。若商品存在质量问题用户需在签收后 7 日内提交图片或视频证据客服审核后进入售后流程。如果你把它切成两段第一段只保留“定制商品非质量问题不支持七天无理由退货”。第二段只保留“用户需在签收后 7 日内提交证据”。那模型可能在回答时丢掉条件或者误解适用范围。所以 chunk 的目标不是平均切短而是把文档切成能被检索、被引用、被验证的最小证据单元。好的 chunk 不只包含正文还应该带上能追溯和过滤的信息比如标题、章节、来源、页码、版本、所属租户、更新时间和权限范围。比如{content:定制商品非质量问题不支持七天无理由退货...,source:refund_policy_v3.pdf,section:定制商品售后限制,page:7,tenantId:merchant_001,version:v3,updatedAt:2026-06-01}这才是一个对 RAG 友好的 chunk。一句话总结Chunk 不是把文档切短而是把文档切成 AI 能使用、用户能追溯的证据片段。3. Embedding把文本变成语义坐标Embedding 是 RAG 里最常被提到的词。简单说Embedding 就是把一段文本变成一串数字也就是向量。为什么要这么做因为计算机不能直接理解“这两句话意思很接近”。它需要一种可以计算的表示方式。比如用户问出差住酒店最多能报销多少钱文档里写的是差旅住宿报销标准一线城市 600 元/晚其他城市 400 元/晚。这两句话用词不完全一样。用户说的是“出差”“住酒店”“最多能报销多少钱”文档写的是“差旅”“住宿”“报销标准”。如果只靠关键词系统不一定能稳定命中。但从语义上看它们问的其实是同一类问题。Embedding 的作用就是把这些文本映射到一个向量空间里。你可以把它理解成“语义坐标”。意思接近的文本坐标距离更近。意思不相关的文本坐标距离更远。所以在 RAG 里Embedding 解决的是让系统可以计算用户问题和文档片段之间的语义相似度。具体流程分成两个阶段。第一阶段是文档入库也就是提前处理知识库原始文档 ↓ 切成 chunk ↓ 每个 chunk 做 embedding ↓ 得到每个 chunk 的向量 ↓ 把 chunk 原文 向量 metadata 存入数据库比如文档被切成三个 chunkchunk_001差旅住宿报销标准一线城市 600 元/晚其他城市 400 元/晚。 chunk_002交通费报销需提供发票。 chunk_003餐饮补贴按城市等级计算。系统会把每个 chunk 都转成向量。真实的向量通常有几百到几千维这里只用简化数字演示chunk_001 embedding [0.12, -0.44, 0.87, ...] chunk_002 embedding [0.31, 0.22, -0.10, ...] chunk_003 embedding [-0.18, 0.62, 0.40, ...]这些数字不是给人看的而是给系统计算相似度用的。第二阶段是用户提问也就是在线检索用户问题 ↓ 问题也做 embedding ↓ 得到 query 向量 ↓ 拿 query 向量去数据库里查相似 chunk ↓ 返回最相似的 topK 个 chunk ↓ 把这些 chunk 原文交给 LLM 生成回答比如用户问出差住酒店最多能报销多少钱系统会把这个问题也转成向量query embedding [0.10, -0.41, 0.83, ...]然后系统会比较query embedding 和 chunk_001 embedding 距离很近 query embedding 和 chunk_002 embedding 距离较远 query embedding 和 chunk_003 embedding 距离较远所以它会优先召回 chunk_001差旅住宿报销标准一线城市 600 元/晚其他城市 400 元/晚。最后LLM 不是凭空回答而是基于召回的 chunk 生成根据差旅住宿报销标准一线城市住宿最高可报销 600 元/晚其他城市最高可报销 400 元/晚。所以 Embedding 不是直接回答问题它只负责把“可能相关的证据”找出来。你可以把它理解成 RAG 检索层的第一步文档 chunk 先变成向量 用户问题也变成向量 系统比较两边向量的距离 距离越近说明语义越相关 然后取回对应 chunk 原文 再交给大模型生成回答但这里有一个非常重要的边界Embedding 解决的是语义相似不等于事实正确。相似不代表能回答。相关不代表完整。语义接近不代表证据足够。比如用户问SKU-A1937 是否支持德国仓发货这个问题最关键的是两个精确信息SKU-A1937 德国仓系统必须找到同时和这两个条件相关的内容。如果只靠 Embedding它可能召回这些看起来相近的内容SKU-A1938 支持德国仓发货。 SKU-A1937 支持法国仓发货。 德国仓发货规则说明。这些内容都“相关”但不一定能回答用户的问题。因为用户问的不是“德国仓规则是什么”也不是“类似 SKU 怎么发货”而是SKU-A1937 这个具体商品是否支持德国仓发货这种问题不能只靠语义相似还需要 BM25 / 关键词检索、metadata filter甚至直接查业务数据库。所以不要把 Embedding 当成语义魔法。它只是 RAG 检索系统的一部分。一句话总结Embedding 是 RAG 检索层的语义匹配器它把文档片段和用户问题都变成向量通过相似度找到可能相关的候选证据。但它只能说明“语义接近”不能保证证据完整、事实正确、权限合规也不能替代关键词检索和业务数据查询。4. Vector DB存向量、查相似有了 embedding 之后需要一个地方存这些向量并支持按相似度检索。这就是 Vector DB。常见选择包括 PGVector、Milvus、Qdrant、Weaviate、Pinecone也可以使用 Elasticsearch / OpenSearch 的向量检索能力。Vector DB 的基本工作方式是文档被切成 chunk。每个 chunk 被 embedding 成向量。向量和 chunk 一起存入数据库。用户提问时问题也被 embedding 成向量。系统查找和问题向量最相似的 chunk。把这些 chunk 交给大模型生成答案。基本流程chunk 文本 ↓ embedding 模型 ↓ 向量 ↓ Vector DB ↓ 相似度检索 ↓ topK chunks如果你用 Java / Spring Boot / PostgreSQL 技术栈PGVector 是一个很适合入门和工程落地的选择。它是 PostgreSQL 的向量相似搜索扩展可以让你在 PostgreSQL 里存向量、建索引、做相似度查询。对个人项目和中小型应用来说PGVector 的优势是工程成本低document、chunk、metadata、tenant_id 可以和业务数据放在同一个 PostgreSQL 里也方便接入 Spring AI 的 VectorStore 抽象不需要一开始就维护单独的向量数据库集群。但 Vector DB 不是 RAG 的全部。很多人做 RAG 的第一个误区就是我接了向量数据库所以我有 RAG 了。不一定。如果你没有好的 chunk没有 metadata filter没有 citation没有拒答没有 eval那它只是一个“向量检索 Prompt”demo。用一个生活类比假设你有一个图书馆。Document 是一本本书。Chunk 是书里被裁出来的一小段内容。Embedding 是给每一段内容贴一个“语义坐标”。Vector DB 是图书馆的“语义索引系统”。用户问题也会被贴一个“语义坐标”。系统就看用户问题这个坐标离哪些内容的坐标最近。最近的几段就是候选证据。所以 Vector DB 不是“知识库本身”的全部它只是知识库里的一个检索组件。一句话总结Vector DB 负责把 chunk 的语义坐标存起来并在用户提问时找出最相似的候选证据但证据是否完整、是否有权限、是否支持答案还要靠 chunk 质量、metadata filter、reranker、citation、faithfulness 和 eval。5. topK到底取多少条证据topK 是一个很小但很重要的参数。它表示检索时取前 K 条结果。比如topK 5意思是系统会取最相似的 5 个 chunk 放进上下文。很多人会以为 topK 越大越好因为取更多证据似乎更安全。但真实情况不是这样。topK 太小可能漏掉关键证据。topK 太大可能引入噪声污染上下文。无关 chunk 进入 prompt 后模型可能把错误信息也编进答案。上下文越长成本越高延迟越大。比如用户问住宿报销标准topK 太小可能只拿到金额漏掉“必须提供发票”topK 太大又可能把交通费、餐饮补贴、加班餐费一起塞进上下文污染回答。如果 topK 太小比如 topK 1只取第 1 条 chunk好处是上下文很干净成本低速度快。但风险是如果第 1 条不完整系统就漏掉关键条件。比如第 1 条只说一线城市住宿最高 600 元/晚。但第 4 条才说报销时必须提供住宿发票且需经过部门负责人审批。如果 topK 1模型只能看到第一条就可能回答不完整。这叫漏召回。如果 topK 太大比如 topK 20取前 20 条 chunk看起来证据更多好像更安全。但问题是前 20 条里很可能混进很多“看起来相关但其实没用”的内容差旅住宿标准 交通费规则 餐饮补贴 出差审批 酒店协议 员工福利 加班餐费 团队建设报销……这些内容一起塞进 Prompt模型可能被干扰。用户问的是“住宿最高报销多少”但上下文里混入“餐饮补贴”“交通费”“加班餐费”模型就可能把不相关规则也带进答案。这叫噪声污染上下文。所以 topK 的本质是一个平衡topK 太小容易漏掉关键证据 topK 太大容易引入无关噪声所以 topK 不是越大越好而是要和 chunk 质量、检索质量、reranker、上下文窗口一起调。比如naive RAG 可能直接取 top5。Hybrid Search 可能先召回 top50。Reranker 再从 top50 里选 top5。最终只把最可靠的 3–5 个 chunk 放进 prompt。topK也分两种第一种是召回阶段的 topK。它的目标是“不要漏”。比如Vector Search 先召回 top50 BM25 也召回 top50这时候 topK 可以大一点因为只是候选池还没直接塞进 Prompt。第二种是最终上下文的 topK。它的目标是“少噪声”。比如 reranker 从 top50 里重新排序最后只选final topK 3 或 5这几条才会真正进入 Prompt让 LLM 生成答案。所以完整流程是用户问题 ↓ 向量检索 / BM25 检索 ↓ 先多召回一些候选证据比如 top50 ↓ Reranker 重排 ↓ 最终只选 top3~top5 ↓ 放进 Prompt ↓ LLM 生成答案一句话总结topK 决定有多少候选证据进入下一步太少会漏召回太多会污染上下文。6. Similarity Threshold相似度阈值Similarity Threshold就是相似度低于某个分数的结果不要。比如similarityThreshold 0.75意思是相似度低于 0.75 的 chunk 不进入上下文。它的作用是减少无关内容进入 prompt。但这个参数也不能迷信。阈值太高可能把有用证据过滤掉。阈值太低可能放进很多噪声。不同 embedding 模型、不同业务问题、不同 query 长度都会影响分数分布所以 threshold 不能照抄需要靠 eval 调。Similarity Threshold 可以理解成检索结果的最低及格线。Similarity Threshold 的本质是一个平衡阈值太高结果更干净但可能漏掉有用证据 阈值太低结果更多但可能引入噪声它和 topK 的区别也要分清。topK 控制的是最多取几条Similarity Threshold 控制的是低于多少分不要比如topK 5 similarityThreshold 0.75意思不是“无论如何取 5 条”而是先按相似度排序最多取前 5 条但低于 0.75 的不要假设结果是0.91chunk A 0.86chunk B 0.79chunk C 0.68chunk D 0.62chunk E虽然 topK 5但因为 threshold 0.75最后只保留chunk A chunk B chunk C所以可以这样理解topK 是数量上限 threshold 是质量底线一句话总结topK 决定“最多拿几条”Similarity Threshold 决定“太不像的不要”。7. BM25 / Lexical Search关键词检索不是过时技术BM25 或 lexical search可以简单理解成关键词检索。它不像 embedding 那样理解语义而是更关注词面命中。比如SKU-A1937 HTTP 401 退款政策第 7 条 tenant_id RetrievalAugmentationAdvisor PGVector这些查询不需要先“理解语义”而是要精确命中。如果用户问“SKU-A1937 是否支持德国仓发货”系统就应该优先找到包含SKU-A1937的文档或表格。如果用户问“Spring AI 的 RetrievalAugmentationAdvisor 怎么用”系统就应该优先命中官方文档里包含这个类名的片段。所以 BM25 / lexical search 没有过时。它解决的是向量检索不擅长的问题编号。错误码。字段名。类名。方法名。产品型号。政策条款。固定术语。短 query。中英混合表达。这也是为什么很多生产 RAG 系统会做 Hybrid Search而不是只做向量检索。BM25 / Lexical Search 这段的核心意思是不要以为 RAG 只靠 Embedding。Embedding 擅长找“意思相近”的内容但 BM25 擅长找“字面上必须命中”的内容。你不需要记 BM25 的公式只要理解它比普通关键词匹配更会衡量词的重要性和匹配强度特别适合编号、类名、字段名、错误码、政策条款这类必须精确命中的内容。你只要理解BM25 更重视词面命中尤其适合查精确词。如果用 Embedding系统可能觉得这些内容相关HTTP 403 权限错误 HTTP 401 未认证 HTTP 500 服务异常但如果用户明确问HTTP 401那系统就必须优先命中包含HTTP 401的片段。这就是 BM25 的价值。它不是过时技术而是在 RAG 里补 Embedding 的短板。更具体一点Embedding 容易在这些场景失手比如用户问“退款政策第 7 条怎么说”Embedding 可能召回退款政策总则、退款流程、售后说明但不一定精确命中“第 7 条”。BM25 会更关注“第 7 条”这个词面。一句话总结Embedding 找语义相似BM25 / lexical search 找精确命中。8. Hybrid Search两路一起找证据Hybrid Search就是混合检索。最常见的是Vector Search BM25 / Lexical Search也就是向量检索负责找语义相关。关键词检索负责找精确命中。两路结果合并后再排序。它解决的是一个非常现实的问题单一路检索器容易漏证据。比如用户问我的简历里有没有能支撑 RAG evaluation 的证据简历里可能没写 “RAG evaluation”但写了设计了 evidence guard、citation check、unsupported claim detection用于限制 AI 生成中的无证据扩写。这个时候向量检索有价值。但如果用户问我的项目有没有写 PGVector那就应该精确命中PGVector这个词关键词检索更重要。所以 Hybrid Search 不是炫技而是降低漏召回。基本流程是用户问题 ↓ Vector Recall找语义相关 Lexical Recall找精确命中 ↓ 融合排序/去重/重排 ↓ 候选证据Vector Search 像一个懂意思的人“你虽然没说 evidence guard但我知道它和 RAG evaluation 有关。”BM25 像一个认真查关键词的人“你问 PGVector我就必须找到 PGVector 这个词。”一句话总结Hybrid Search 语义检索负责“意思相近”关键词检索负责“原词命中”。两路一起召回可以降低关键证据被漏掉的概率。9. RRF把多路检索结果合并Hybrid Search 会产生两张排行榜RRF 的作用就是把这两张排行榜合并成一张总榜。做完 Hybrid Search 后会出现一个新问题Vector Search 有一组结果。BM25 / Lexical Search 有一组结果。这两组结果怎么合并最直接的想法是把分数加起来。但这通常不严谨。因为向量相似度和 BM25 分数不是同一种分数。它们来自不同算法尺度不同不能简单相加。这时候可以用 RRF。RRF全称 Reciprocal Rank Fusion中文可以理解成“倒数排名融合”。它不直接比较原始分数而是看排名。公式大概是RRF score Σ 1 / (k rank)不用被公式吓到它的意思很简单如果一个 chunk 在向量检索里排得很靠前在关键词检索里也排得靠前那它更可能重要。如果一个 chunk 只在某一路检索里非常靠前它也有机会被保留下来。RRF 关心的是“排第几”不是原始分数是多少。举个简单例子Chunk A向量检索第 1关键词检索第 5 Chunk B向量检索第 20关键词检索第 1 Chunk C向量检索第 3关键词检索没有召回RRF 会综合这些排名而不是强行比较“向量相似度 0.82”和“BM25 分数 12.7”谁更大。RRF 最适合解决的问题是Vector Search 和 BM25 的分数不能直接加但它们的排名可以融合。你可以把它放回整个 RAG 流程用户问题 ↓ Vector Search 返回一组排行榜 ↓ BM25 返回一组排行榜 ↓ RRF 根据“排名”融合两组结果 ↓ 得到候选证据总榜 ↓ Reranker 再精排 ↓ 选出 Final Evidence这里还要分清 RRF 和 RerankerRRF用排名规则快速融合多路检索结果 Reranker用模型进一步判断 query 和 chunk 是否真的相关一句话总结RRF 是把 Vector Search 和 BM25 的结果合并成一张更合理的候选证据排行榜。10. Reranker最终复核候选证据Retriever 是粗筛Reranker 是复核。检索器先找出一批候选 chunk比如 top50 或 top100。Reranker 再判断这些 chunk 和当前问题到底有多相关。最后只选最适合回答问题的几个 chunk 进入 prompt。为什么要这样做因为召回阶段追求“不要漏”。重排阶段追求“更准确”。如果一开始就只取 top5很可能漏掉关键证据。如果把 top50 全部塞进 prompt又会污染上下文。所以常见做法是先多召回再精排。典型流程用户问题 ↓ Vector Search / BM25 先召回 top50 ↓ RRF 把多路结果融合成候选列表 ↓ Reranker 逐条判断这个 chunk 到底能不能回答这个问题 ↓ 重新排序 ↓ 只选 top3 / top5 放进 Prompt ↓ LLM 基于最终证据生成答案Reranker 和 Embedding 的区别非常重要。Embedding 的做法一般是把 query 单独变成向量 把 chunk 单独变成向量 然后计算两个向量距离它更像是快速粗筛这个问题和这个 chunk 的语义大概像不像Reranker 的做法通常是把 query 和 chunk 放在一起让模型直接判断它们的相关性它问的是更细的问题这个 chunk 是否真的能回答当前 query 这个 chunk 是强相关、弱相关还是只是沾边 这个 chunk 是否包含用户问题需要的关键条件举个例子。用户问退款政策第 7 条怎么说前面检索可能召回A退款政策总则 B退款申请流程 C第 7 条定制商品非质量问题不支持七天无理由退货 D售后审核要求 E退货运费说明Embedding 可能觉得 A、B、D、E 都和“退款政策”相关。但 Reranker 会更容易判断用户问的是“第 7 条” C 直接包含“第 7 条” 所以 C 应该排第一这就是 reranker 的价值它不是只看大概相关而是更细地判断“能不能支撑这个问题”。一句话总结Reranker 是 final context 之前的最后一道证据复核它决定哪些候选 chunk 真正有资格进入大模型上下文。11. Metadata Filter只在正确范围里检索很多 RAG demo 会直接在所有文档里检索但生产系统不能这样做。Metadata就是文档或 chunk 附带的信息。比如{tenantId:merchant_001,sourceType:refund_policy,language:zh,version:v3,status:active,updatedAt:2026-06-01}Metadata Filter 就是按这些字段过滤。为什么它重要因为不是所有文档都应该被检索。用户问退款政策时系统要先判断是不是当前商家的政策是不是当前语言是不是当前版本是不是 active 状态是不是当前用户有权限访问是不是对应业务线如果不做 metadata filter系统可能召回旧版本政策。其他租户文档。测试文档。英文文档。无权限文档。已废弃规则。这不是回答不准的问题而是系统边界问题。RAG 检索时不能在所有文档里乱找。它必须先限定范围只在“当前用户应该看的、当前业务应该用的、当前版本有效的文档”里检索。Chunk 本身是正文比如定制商品非质量问题不支持七天无理由退货。Metadata 是这段 chunk 身上的标签比如{tenantId:merchant_001,sourceType:refund_policy,language:zh,version:v3,status:active,updatedAt:2026-06-01}这些标签不是给大模型看的废信息而是给系统检索时做过滤用的。也就是说系统不是直接问哪些 chunk 和用户问题最相似而应该先问在当前商家 merchant_001 的 active 中文退款政策里哪些 chunk 和用户问题最相似这就是 Metadata Filter。一句话总结Metadata Filter 决定“哪些资料有资格参与检索”Embedding / BM25 决定“这些资料里哪些最相关”。12. Tenant Filter多租户系统的硬隔离Tenant Filter 可以理解成 Metadata Filter 里最不能出错的一种。Metadata Filter 是范围控制Tenant Filter 是权限隔离。如果一个系统服务多个公司、多个商家、多个团队每个组织就是一个 tenant。比如商家 A 有自己的退款政策。商家 B 有自己的退款政策。商家 C 有自己的商品知识库。用户来自商家 A那么系统只能检索商家 A 的文档。不能靠 prompt 说请你只回答当前商家的内容。这不够。真正的 tenant filter 应该在数据库查询、检索条件、权限系统里生效。比如WHEREtenant_idmerchant_001如果 tenant filter 漏了后果不是“回答不够好”而是“数据越权”。一句话总结Tenant Filter 不是 Prompt 约束而是数据访问控制。13. Citation答案来自哪里但不代表答案一定被支持Citation就是引用来源。它告诉用户这个答案来自哪篇文档。来自哪个 chunk。来自哪一页。来自哪个章节。原文片段是什么。比如{answer:一线城市住宿最高可报销 600 元/晚。,citation:{document:2026 差旅报销制度,section:住宿标准,page:3,quote:一线城市 600 元/晚其他城市 400 元/晚}}Citation 的价值是让答案可追溯。但要注意有引用不等于可信。引用只能说明系统给了来源。它不能自动说明答案真的被来源支持。比如原文说定制商品非质量问题不支持七天无理由退货。模型回答所有跨境商品都不支持退货。这个答案可能也带了引用但它扩大了原文范围所以不可信。一句话总结Citation 是可信的起点不是终点。14. Faithfulness / Groundedness答案是否忠于证据Faithfulness 和 Groundedness 经常一起出现。你可以先不用纠结二者的边界它们都在问一个核心问题模型说的话证据里到底有没有如果证据说候选人参与了 Spring Boot 后端开发并接入了 Redis 限流。模型改写成主导设计高并发 AI Agent 平台使用 Redis、RocketMQ、PGVector 构建生产级 RAG 系统。这就是典型不 faithful。因为模型加了很多证据里没有的东西。这在 AI 简历、项目包装、求职材料里尤其危险。它不是简单“润色”而是把没有证据的经历写成了事实。所以 Faithfulness / Groundedness 不是看答案是否流畅也不是看答案是否有引用而是看答案里的每个关键 claim 是否被证据支持。你可以把它拆成 claim 检查Claim 1主导设计高并发 AI Agent 平台证据支持没有。 Claim 2使用 Redis证据支持有。 Claim 3使用 RocketMQ证据支持没有。 Claim 4使用 PGVector证据支持没有。 Claim 5构建生产级 RAG 系统证据支持没有。所以 Faithfulness 检查的不是“这句话写得好不好”而是每一个关键 claim 是否有证据支撑 有没有夸大 有没有扩展范围 有没有补充证据里没有的技术 有没有把参与说成主导 有没有把 demo 说成生产级这也是为什么 Faithfulness 不能只看语言是否流畅也不能只看答案是否带了引用。因为模型最容易出现的问题就是它可以把错误答案说得非常自然。一个不 faithful 的答案可能具备这些表象语言很流畅结构很清楚看起来专业甚至带了引用但只要答案里的关键结论没有被证据支持它仍然不可信。一句话总结Citation 问的是“答案挂了哪个来源”Faithfulness 问的是“这个来源到底支不支持答案”。有引用只是把答案和资料连起来Faithfulness 才是在检查这条连接是不是真的成立。15. Abstention证据不足时系统应该拒答Abstention就是拒答。但这里的拒答不是“模型不会”而是“系统知道不该答”。什么时候应该拒答没有检索到证据。证据之间互相冲突。用户没有权限访问相关资料。问题超出知识库范围。答案需要实时订单状态但当前只有静态政策文档。检索结果只支持一部分结论不支持完整回答。比如用户问这个订单还能退吗如果系统只检索到通用退款政策但没有订单状态、商品类型、物流节点、是否定制商品这些信息就不应该直接回答“可以退”或“不可以退”。更好的回答是当前知识库只包含通用退款政策无法确认该订单是否符合退款条件。需要查询订单状态、商品类型和物流信息后才能判断。这就是可信 RAG 的边界感。一句话总结可信 RAG 不应该永远给答案。它必须能识别证据不足、权限不足、信息缺失和结论无法成立的情况。16. RAG Eval证明系统真的变好了RAG Eval就是评测 RAG 系统是不是真的有效要用一组可重复的测试问题检查系统到底坏在哪个环节。很多 demo 的评测方式是问几个问题。看起来回答不错。觉得系统可以上线。这很危险。因为 RAG 的错误可能发生在多个环节文档解析错。chunk 切坏了。embedding 召回错。BM25 没命中。RRF 排序不好。reranker 选错证据。final context 被噪声污染。模型没有忠实使用证据。引用不支持答案。该拒答时没有拒答。所以 eval 的价值不是打一个漂亮分数而是定位系统坏在哪里。常见评测维度包括retrieval recall该召回的证据有没有召回。context precision召回的上下文有多少真的有用。faithfulness答案是否忠于证据。answer relevance答案是否回应问题。citation accuracy引用是否真的支持答案。abstention accuracy该拒答时有没有拒答。RAG 不是一个单点功能而是一条链路文档解析 ↓ chunk 切分 ↓ embedding / BM25 召回 ↓ RRF / Reranker 排序 ↓ final context 选择 ↓ LLM 生成回答 ↓ citation 引用 ↓ faithfulness 检查 ↓ abstention 拒答这条链路任何一环出问题最后答案都可能错。一句话总结没有 Eval你只能凭感觉调 RAG。有了 Eval你才能知道问题到底出在检索、排序、上下文选择、生成、引用还是拒答边界。到这一步RAG 才开始从 demo 接近工程系统。17. 把这些词放回一条证据链里现在再回头看这些术语它们其实不是孤立概念。Document 是原料。Chunk 是证据单元。Embedding 是语义坐标。Vector DB 是语义检索工具。BM25 / Lexical Search 是精确词面检索工具。Hybrid Search 是双路召回。RRF 是多路排序融合。Reranker 是候选证据复核。Metadata Filter 是检索范围控制。Tenant Filter 是数据隔离。Citation 是来源标记。Faithfulness / Groundedness 是答案是否忠于证据。Abstention 是边界控制。RAG Eval 是质量证明。它们共同组成的是问题 ↓ 检索正确范围内的证据 ↓ 选择最能支撑答案的证据 ↓ 基于证据生成回答 ↓ 标记引用来源 ↓ 检查答案是否忠于证据 ↓ 证据不足时拒答 ↓ 用 eval 证明系统是否变好这就是我理解的可信 RAG。它不是“向量库 Prompt”。也不是“把 PDF 丢进去让 AI 聊天”。它是一套把问题、证据、生成、引用、拒答、评测串起来的工程系统。18. 下一篇从 0 到 1 搭一个个人技术资产知识库下一篇我会开始写保姆级实战从 0 到 1 搭一个个人技术资产知识库Spring Boot Spring AI PGVector 保姆级教程。这次不做泛泛的“PDF 聊天机器人”而是用自己的真实技术资产作为知识库来源个人博客文章GitHub README项目文档技术复盘Markdown 笔记目标也不是一上来做完整企业级平台而是搭出一个最小可信 RAG 骨架文档从哪里来chunk 怎么切embedding 怎么入库PGVector 怎么检索metadata 怎么过滤回答怎么带 citation证据不足怎么拒答retrieval trace 怎么记录最小 eval case 怎么设计它还不是完整企业级知识库但会保留企业级系统最关键的边界意识来源、权限、版本、证据、引用、拒答和评测。最后回到一句话RAG 的目标不是让 AI 更会说而是让 AI 的回答更值得被信任。参考资料Patrick Lewis et al.Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020 / arXiv:2005.11401.https://arxiv.org/abs/2005.11401Spring AI Reference Documentation.Retrieval Augmented Generation.https://docs.spring.io/spring-ai/reference/api/retrieval-augmented-generation.htmlpgvector.Open-source vector similarity search for Postgres. GitHub.https://github.com/pgvector/pgvectorGordon V. Cormack, Charles L. A. Clarke, Stefan Büttcher.Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods. SIGIR 2009.https://research.google/pubs/reciprocal-rank-fusion-outperforms-condorcet-and-individual-rank-learning-methods/Shahul Es et al.RAGAS: Automated Evaluation of Retrieval Augmented Generation. EACL 2024 / arXiv:2309.15217.https://arxiv.org/abs/2309.15217我是 Ryan一个专注于可信 AI 应用工程的开发者我的技术博客。相比让 AI 生成更多内容我更关心它的回答是否有证据过程是否可追溯结果是否经得起验证。