你问它"张小龙是哪一年进的腾讯"，它答得上来。你换个问法，“腾讯这些年都投了哪些游戏公司”，它开始一本正经地编。同一个模型，同一份训练数据，差距就藏在"答案能不能从外部材料里查出来"这件事上。
这就是 RAG 出场的理由。RAG（Retrieval-Augmented Generation，检索增强生成）干的事，一句话就能说清：模型不再全靠肚子里那点参数硬答，先到外部文档里检索相关材料，再照着材料作答。
原生 RAG：三步走
文本式 RAG 的流程，教科书上写得很直白：
- 切块。原始文档太长，先切成几百到上千 token 的片段，方便后面建索引。
- 向量化 + 检索。每个片段过一遍 Embedding 模型，编码成向量，搭一个索引。用户提问时，把问题也编码，在索引里找 K 个最相似的片段当"证据"。
- 生成。证据片段和问题拼在一起喂给大模型，让它基于这些材料作答。
这套流程简单可靠，能把幻觉压下去一大截，因为模型手里终于有了真材料。但它的检索逻辑只有一条：向量像不像。像，就捞出来；不像，就漏掉。
问题就出在这。你想查"某家公司背后的投资方"，答案散在三四篇不同的文章里，每一篇单独看，跟问题都不怎么"像"。向量检索要么捞不到，要么捞回一堆似像非像的碎片。跨实体、多跳的关系推理，是文本检索最力不从心的地方。
知识图谱来补位
知识图谱（Knowledge Graph）的玩法不一样：它先把知识拆成"实体 + 关系"，存成一张图。“腾讯"是一个节点，“投资"是一条边，指向"米哈游"这个节点。查询的时候不走"像不像”，走"连不连得上”。
KG-RAG 的流程，比原生 RAG 多两步：
- 实体识别与链接。从用户问题里抽出实体（人名、公司名、地名），到图里找到对应节点。同义词、别名这关，一般还要配合向量检索做模糊匹配。
- 图检索。以实体节点为中心，沿着关系遍历：查属性，比如某个人物的出生日期；查关系，比如某家公司投过谁、跟谁合作。
- 知识整合。把查到的子图转成文字段落或表格，作为给模型的结构化上下文。
- 生成。和原生 RAG 一样，材料加问题进模型，出答案。
跟"碰运气"式的向量检索比，图检索的好处是显式的：关系是画出来的，不是猜出来的。跨文档的同一实体，在图里天然就是一个节点，不用反复拼凑；多实体、多关系的问答，子图能把逻辑关系直接摆给模型看，错漏和冲突都少一截，还方便溯源——答错了，顺着图能查到是哪条边给的依据。
1M 上下文来了，能绕开检索吗
这几年上下文窗口一路狂飙，1M token 的模型都有了。有人干脆把整本文档都塞进去，连检索都省了。省不掉的，理由有四个：
- 贵。1M token 的显存和计算开销摆在那，多数问题其实只需要一小段上下文，为一次提问烧一百万 token 的钱，不划算。
- 窗口再大也装不下真知识库。真实业务里几十万、几百万份文档，1M 窗口也就是个零头。
- 噪音。内容越多，模型要分辨的无关信息越多，注意力被稀释，准确率不升反降。
- 维护。文档在变、知识在涨，每次都把新内容拼进上下文，没有增量更新的余地。
所以，超长上下文能省掉一部分切块和检索，但替代不了结构化检索本身。窗口是给"一次性读完"的场景用的，知识库是给"长期可查"的场景用的。
往后怎么走
RAG × 知识图谱的方向，基本是三个：多模态图谱（图里除了文本还存图像、音视频）、结构 + 向量混合检索（图谱关系配向量相似度，两头都占）、可解释推理链（把模型的推理路径画出来，供审计）。
模型负责把问题读懂、把答案说圆，检索层负责把靠谱的材料递到它手里。图谱让这条递材料的链路，从"看着像"升级成"查得着"。