面试日记 第 22 天面试官把手机推过来屏幕上是 Kimi K3 的发布稿。“一百万 token 上下文。”她看着我“你们那套 RAG是不是该进垃圾桶了”我说不急先把基础分拿了把 RAG 的两大阶段完整讲了一遍离线索引做知识入库清洗、切块、转向量、进 Milvus在线问答处理请求问题向量化、相似度检索、Rerank、拼进 Prompt 让模型生成。她点点头没追问流程把问题推了回来“流程你背得挺熟。那回答我刚才的问题——既然模型自己装得下一百万 token你们为什么还要维护向量库这一套”“其实我们已经不维护了。”我说“上个月就把 RAG 拆了文档直接塞全文。链路短不用调 top_k又快又省事。”她打开自己的笔记本转过来屏幕上是一份推理成本监控。“塞一次全文多少钱”我没答上来。“我替你算。”她指着账单“你们的知识库八十万 token按现在旗舰模型的输入价塞一次全文两块多。一天几千次问答每一轮都把八十万 token 重新塞一遍。省的是你的事费的是公司的钱。”她往下划了一屏是一条召回率曲线。“再看效果。大海捞针测试做过吗上下文塞到几十万 token模型对中间段落的命中率明显往下掉。文档虽然进了上下文关键时刻就是捞不出来。”我辩解“K3 不是号称长上下文很强吗”“强所以人家才把缓存命中做到九成以上。”她把发布稿里那行字圈出来“你猜为什么因为真在用长上下文的团队都在想办法复用已经塞过的内容、少做重复灌入——跟你说的每轮全量重塞恰恰是反的。”我握着笔半天只写出一句“那我把向量库装回来。”“先把题答完整。”她把电脑合上RAG 的完整流程是怎么样的这一次我答的不只是流程名还有每一步省的是什么钱、防的是什么坑。回答重点RAG 的核心就是“先搜后答”整个流程分成离线索引和在线问答两大阶段。离线索引阶段做的是知识入库1把原始文档清洗干净、切成 300-500 字的小块 2用嵌入模型把每个文本块转成向量 3向量存进 Milvus 这类向量数据库建好索引等着被搜在线问答阶段处理用户请求1用户提问进来先把问题也转成向量 2拿这个向量去数据库里做相似度检索捞出最相关的 5-10 个文档块 3对检索结果做重排序把最相关的排前面 4把用户问题和检索到的上下文一起塞给大模型让它基于这些材料生成回答整个流程的精髓在于大模型不再“裸奔”回答问题而是带着检索到的知识去生成既能减少幻觉又能让回答有据可查。扩展知识一百万上下文时代RAG 为什么反而省不掉先算成本账。八十万 token 的知识库按 K3 输入价 3 美元/百万 token 估算每轮问答全量塞入一次约 2.4 美元而走 RAG 每轮只送检索出的 5-10 个块、几千 token两者差着三个数量级。再算效果账大海捞针类测试普遍显示上下文拉长后模型对中间段落的召回会明显衰减“装得下”和“捞得着”是两回事。真正的反常识点在这里上下文窗口越大无脑塞全文越亏。K3 依托 Mooncake 分离式推理架构把编程场景的缓存命中率做到 90% 以上财新报道口径恰恰说明工程上的主力方向是复用已经塞过的上下文、避免重复灌入而不是取消检索。长上下文解决的是轮次之间重复内容的复用RAG 解决的是从百万级语料里选出这次该看的几千 token两者是分工谁也没替代谁。文档分块策略分块是 RAG 效果的关键块太大检索不精准块太小又丢失上下文。常见的三种切法1语义切分用 SemanticSplitter 这类工具保证每个块语义完整独立比如一个问答对不会被切成两半2结构切分HTML、PDF 这种有层级的文档按标题层级切割像 HTMLHeaderTextSplitter 就能保留文档结构3递归切分RecursiveCharacterTextSplitter 先按大的分隔符切切不动了再按小的切兼顾连贯性和长度限制实际项目里300-500 字一块是比较通用的起点具体要根据业务场景调。检索阶段的优化手段单纯靠向量检索其实不够用生产环境通常会做多路召回混合检索特别适合那种用户可能用专业术语搜索的场景纯向量检索容易漏掉精确匹配的结果。11464. 什么混合检索在基于大模型的应用开发中混合检索主要解决什么问题Prompt 组装技巧检索完拿到一堆文档块怎么塞给大模型也有讲究# 典型的 RAG Prompt 模板prompt基于以下参考资料回答用户问题。如果资料中没有相关信息请说明无法回答。 参考资料 {context} 用户问题{query} 回答上下文太长会影响模型效果超过 4000 token 的时候可以考虑做摘要压缩RAPTOR 这类树状摘要方案就是干这个的。面试官追问追问如果检索出来的文档和用户问题不太相关大模型生成的答案会怎样有什么办法缓解回答大模型会硬着头皮用这些不相关的内容去凑答案结果就是回答跑偏或者出现幻觉。缓解手段主要有三个 1加一个相关性打分的环节低于阈值的直接丢掉不给模型 2在 Prompt 里明确告诉模型“如果资料不相关就直接说不知道” 3用 Reranker 做二次排序把真正相关的顶上来追问向量检索和传统的关键词检索各有什么优缺点回答向量检索擅长语义理解用户说“怎么退款”能搜到“退货流程”这种同义词的文档但对精确匹配不敏感搜“iPhone 15”可能漏掉带这个精确词的文档。关键词检索正好反过来精确匹配很强但不懂语义“退款”搜不到“退货”。所以生产环境一般两个一起用取长补短。追问文档块之间有上下文依赖怎么办比如前一段说“它”指的是更前面的某个概念。回答这是分块策略的经典问题。常用的解法是加 overlap相邻的块之间重叠 50-100 字保证上下文不丢。更高级的做法是用 Parent-Child 结构检索的时候匹配小块返回给模型的时候带上它的父块这样既精准又有上下文。回去我把成本监控调出来重新看了一遍RAG 那套离线索引看着笨其实每轮只把最相关的几千 token 送进模型剩下的钱和注意力都省下来了。这道题容易被“上下文窗口”这个数字带偏窗口装得下不等于装得划算、看得过来。完整题解和原始追问已经整理在面试鸭准备大模型应用方向的同学可以顺手把 RAG 这一组题过一遍。