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. 离线索引
- 离线索引负责把文档变成可检索的数据
- 常见文档:
- 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 快但依赖聚类质量
10. 为什么要 Hybrid Search
- 单纯向量检索不够
- 因为业务问题里有大量精确词
- 比如菜品名、订单状态、规则编号、错误码
- 向量检索擅长语义相似
- 关键词检索擅长精确匹配
- 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客服]]