Skip to content

RAG 知识卡片(简历版)

这份卡片按你当前简历的项目强度整理。

目标不是搜索引擎 / 向量数据库全覆盖,而是:

  • 能撑住 苍穹外卖 AI 智能客服 Agent 里的 Hybrid RAG 追问
  • 能讲清楚 Pgvector、向量检索、关键词检索、RRF、Reranker、Query Expansion
  • 能把 RAG 和 Spring AI Advisor、记忆系统、工具调用串起来
  • 能过 Java Agent 应用开发方向的一面 / 二面项目深挖

1. RAG 是什么

  • RAG = Retrieval-Augmented Generation
  • 中文叫:检索增强生成
  • 核心不是让模型变聪明
  • 而是让模型先查资料,再基于证据回答
  • 裸 LLM 像闭卷考试
  • RAG 像开卷考试
  • 但开卷前要先把正确资料找出来

2. RAG 解决什么问题

  • 解决模型知识过期
  • 解决企业私有知识模型不知道
  • 解决长文档不能全部塞进上下文
  • 解决回答缺少依据
  • 解决部分幻觉问题
  • 记一句:
  • RAG 把模型直觉回答,变成基于证据回答

3. RAG 典型链路

  • 离线阶段:

  • 文档解析

  • 文档清洗

  • 文档切分

  • 向量化

  • 建索引

  • 存 metadata

  • 在线阶段:

  • 用户问题进来

  • Query Rewrite / Query Expansion

  • 向量召回

  • 关键词召回

  • RRF 融合

  • Reranker 精排

  • 构造上下文

  • LLM 基于证据回答

  • 证据不足就拒答或降级

4. 离线索引

  • 离线索引负责把文档变成可检索的数据
  • 常见文档:
  • PDF
  • Markdown
  • QA
  • TXT
  • 不同文档适合不同切分方式
  • PDF 要注意标题、页码、段落结构
  • QA 可以按问答对切
  • Markdown 可以按标题层级切
  • TXT 可以按段落或语义边界切
  • metadata 很重要
  • 比如来源、标题、版本、更新时间、权限、业务标签

5. 文档切分

  • 切太大:
  • 召回不准
  • 噪声多
  • 上下文浪费
  • 切太小:
  • 语义断裂
  • 模型看不到完整上下文
  • 好的切分要保留语义完整性
  • 常见做法:
  • 按标题
  • 按段落
  • 按 token 长度
  • 加 overlap
  • 记一句:
  • chunk 质量决定 RAG 上限

6. Embedding

  • Embedding 是把文本转成向量
  • 向量表示语义特征
  • 相似问题在向量空间里距离更近
  • 向量检索适合:
  • 同义表达
  • 口语化问题
  • 模糊语义匹配
  • 但它不擅长所有场景
  • 对订单号、错误码、菜名、专有名词
  • 关键词检索往往更稳定

7. 向量检索

  • 向量检索看的是语义相似度
  • 常见相似度:
  • cosine similarity
  • inner product
  • L2 distance
  • 面试不用陷入公式
  • 要讲清楚取舍:
  • 向量检索召回语义相关内容
  • 但可能漏掉精确词
  • 也可能召回“看起来相似但答不上问题”的片段

8. Pgvector

  • Pgvector 是 PostgreSQL 的向量扩展
  • 可以在数据库里存向量
  • 可以做相似度检索
  • 适合中小规模 RAG 项目落地
  • 好处:
  • 和业务数据放在同一套数据库体系里
  • 工程接入成本低
  • 查询、过滤、权限字段比较好结合
  • 局限:
  • 超大规模搜索能力不如专门向量数据库
  • 高并发和大数据量下要关注索引和性能

9. 向量索引

  • 暴力检索叫 Flat
  • 准确率高
  • 但数据大时慢
  • HNSW:
  • 查询快
  • 召回率和内存之间有取舍
  • IVF:
  • 先聚类再查局部
  • 速度快
  • 但可能漏召回
  • 面试记法:
  • Flat 准但慢
  • HNSW 快但吃内存
  • IVF 快但依赖聚类质量
  • 单纯向量检索不够
  • 因为业务问题里有大量精确词
  • 比如菜品名、订单状态、规则编号、错误码
  • 向量检索擅长语义相似
  • 关键词检索擅长精确匹配
  • Hybrid Search = 向量召回 + 关键词召回
  • 好处:
  • 既能召回同义表达
  • 又不丢关键术语
  • 你的项目里可以说:
  • 用户问法很口语,但业务规则又有大量精确词,所以用了 Hybrid RAG

11. RRF 融合

  • RRF = Reciprocal Rank Fusion
  • 作用是融合多路召回结果
  • 不直接比较不同检索器的原始分数
  • 而是看排名
  • 排名越靠前,贡献越大
  • 好处:
  • 简单
  • 稳定
  • 适合融合向量检索和关键词检索
  • 面试口径:
  • RRF 解决的是多路召回结果怎么合并排序的问题

12. Reranker 精排

  • 粗召回只负责把候选找出来
  • 不保证每条都真正能回答问题
  • Reranker 负责重新判断:
  • 问题和候选片段是否真正相关
  • 片段是否能支撑回答
  • 常见链路:
  • 先召回 top-k
  • 再 rerank
  • 最后取 top-n 进上下文
  • 记一句:
  • 召回负责找得全,精排负责排得准

13. Query Expansion

  • Query Expansion 是查询扩展
  • 作用是把用户问题改写成更容易检索的形式
  • 可以补充同义词
  • 可以补充业务关键词
  • 可以生成多个查询
  • 适合用户问题太短、太口语、信息不完整的场景
  • 风险:
  • 扩展过头会引入噪声
  • 所以不能盲目扩展
  • 要结合业务场景控制范围

14. Context Construction

  • Context Construction 是上下文构造
  • 不是把召回片段直接全部塞给模型
  • 要做:
  • 去重
  • 截断
  • 排序
  • 合并
  • 保留来源
  • 控制 token
  • 标明证据边界
  • 目标是:
  • 让模型看到最有用的证据
  • 又不要被噪声干扰
  • 记一句:
  • RAG 不是检索完就结束,上下文构造决定模型能不能用好证据

15. 拒答逻辑

  • RAG 不是每次都必须回答
  • 证据不足时应该拒答或降级
  • 否则模型会编
  • 常见做法:
  • 相似度低于阈值拒答
  • Reranker 分数低拒答
  • 证据片段不包含关键事实拒答
  • 提示词要求只能基于上下文回答
  • 项目口径:
  • 客服场景宁可提示转人工,也不能编造退款规则或配送政策

16. RAG 和 Spring AI Advisor

  • Advisor 可以理解成模型调用前后的拦截链
  • RAG 可以放在 Advisor 链里
  • 常见职责:
  • 注入用户上下文
  • 注入记忆
  • 做 RAG 检索
  • 做工具过滤
  • 做安全校验
  • RAG 不是孤立模块
  • 它要和意图识别、记忆、工具调用一起协作
  • 项目口径:
  • 知识型问题优先走 RAG
  • 操作型问题优先走 Tool Calling
  • 个性化问题结合记忆

17. RAG 和 Tool Calling 区别

  • RAG 查知识
  • Tool Calling 做动作
  • RAG 适合:
  • FAQ
  • 规则解释
  • 菜品咨询
  • 配送政策
  • Tool Calling 适合:
  • 查订单
  • 改地址
  • 取消订单
  • 加购物车
  • 项目里不能混:
  • 该查资料时不要调用工具
  • 该操作业务时不能只靠 RAG 编答案

18. RAG 和记忆系统区别

  • RAG 面向外部知识库
  • 记忆面向用户长期偏好和历史上下文
  • RAG 解决:
  • 业务规则是什么
  • 文档怎么说
  • FAQ 怎么答
  • 记忆解决:
  • 用户喜欢什么口味
  • 用户常用什么地址
  • 用户有什么饮食限制
  • 面试口径:
  • RAG 是公共知识,记忆是用户个性化事实

19. RAG 失败怎么排查

  • 不能只说 prompt 没写好
  • 要分层排查:
  • 文档解析有没有丢内容
  • chunk 是否切断语义
  • embedding 是否匹配业务语言
  • 向量召回有没有召到
  • 关键词召回有没有覆盖精确词
  • RRF 融合是否把正确片段压下去了
  • Reranker 是否误排
  • Context 是否太乱
  • Prompt 是否约束证据边界
  • 拒答阈值是否合理

20. 项目高分口径

  • 我的项目不是只接了一个向量库
  • 而是做了一条 Hybrid RAG 链路
  • 离线支持 PDF / Markdown / QA / TXT 文档入库
  • 在线并行走向量检索和关键词检索
  • 用 RRF 融合多路召回结果
  • 再用 Reranker 精排
  • 最后构造上下文给模型回答
  • 对 FAQ 高频问题
  • 先走本地语义缓存
  • 命中就短路返回
  • 没命中再进入 RAG / 模型链路
  • 这样兼顾:
  • 准确性
  • 延迟
  • 成本
  • 可追溯性

21. 面试一句话总结

  • RAG 的核心不是向量库,而是证据链路
  • 召回负责找候选,Reranker 负责排准确,Context 负责让模型用得上
  • Hybrid Search 解决语义召回和精确匹配的互补问题
  • RAG 查知识,Tool Calling 做动作,Memory 管用户个性化事实
  • 客服场景里,证据不足要拒答或转人工,不能让模型编规则

相关链接:[[RAG 基础概念]] | [[RAG 向量索引算法和向量数据库]] | [[RAG 文档处理与切分策略]] | [[苍穹外卖AI客服]]