LangChain 学习笔记 11：回到 Embedding 与 Transformer，再看一遍 RAG

读到最后一章，书又回到 Embedding、相似度、注意力、Transformer、语义搜索和传统 NLP。起初我觉得这些内容像补充知识，重新对照前面的组件以后才发现，它们是在回答一个更基础的问题：RAG 为什么能找到“相近”的文字，模型又为什么能利用放进上下文的内容？

Embedding 做的是表示，不是保存事实

Embedding 把一段文本转换成高维向量。语义接近的句子，通常会在向量空间里更靠近，因此“账号进不去”和“登录失败”有机会互相召回。

常见的点积和余弦相似度都可以衡量向量关系。具体使用哪一种，应与 Embedding 模型和索引配置保持一致，而不是建库时选一个、查询时又换另一个。

更重要的是，向量相近只说明表达相似，不代表事实一致。两份文档可能讨论同一政策，却分别属于不同年份；两段观点可能主题相同，结论却相反。时间、权限、来源和版本仍要依赖元数据与业务规则。

Transformer 提醒我们：上下文也是有限资源

Transformer 通过注意力机制，让每个 token 根据上下文中的其他 token 形成表示。对于应用开发者来说，不必先推完所有公式，也能得到一个很实际的结论：模型只能利用本次请求里实际提供的信息。

Prompt、RAG 和 Memory 做的事情，都与“哪些内容应该进入上下文”有关。

但上下文并非越长越好。放入更多文本会增加成本和延迟，相关证据还可能被噪声淹没。一个 100k token 的窗口能够装下很多资料，不代表每次都应该把资料全部塞进去。

关键词检索和语义检索各有擅长

关键词检索适合错误码、订单号、产品名和精确术语；语义检索擅长同义表达和自然语言问题。

例如查询“ERR-1042”时，关键词通常更可靠；查询“为什么登录后总被踢出来”时，语义搜索更容易匹配“会话过期与重复登录”。真实知识库经常把两种召回合并，再通过重排序把更有用的证据放到前面。

这也解释了为什么 Retriever 不只是“调用一次向量库”：它还要处理过滤、融合、排序和返回数量。

再看 RAG：它补的是上下文，不是参数

RAG 把外部资料检索出来，放进当前请求的上下文。更新知识时不必重新训练模型，也更容易给出引用来源。

但 RAG 不会自动消除幻觉。可能发生的失败至少有四种：

1. 文档没有被正确加载；
2. 正确片段没有被召回；
3. 检索结果互相冲突；
4. 模型没有忠实使用证据。

因此可靠系统需要引用、拒答、冲突处理和评测，而不是只在 Prompt 里写一句“请不要编造”。

传统方法没有因为 LLM 消失

规则、关键词、正则和小型分类器，在延迟、成本和可解释性上仍然很有优势。

如果一个请求可以根据文件扩展名路由，就不必调用模型分类；如果订单号有固定格式，就先用规则校验；如果高频意图只有几个类别，小模型可能已经足够。

LLM 更适合处理难以用固定规则描述的语言歧义。好的系统会组合不同能力，而不是让最昂贵、最不确定的组件包办全部工作。

回看整本书的组件地图

模块	我现在对它的理解
模型 I/O	定义模型调用的输入、输出与失败协议
数据增强	建立可追踪、可评估的外部知识通道
Chain	组织相对确定的数据流和步骤
Memory	选择并维护当前任务需要的状态
Agent	在受限工具集合中动态选择动作
Callback	还原一次请求的运行轨迹
Integrations	把供应商变化控制在边界内

这些模块最终都绕不开四个问题：数据从哪里来，状态保存在哪里，下一步由谁决定，出了问题怎样定位。

读完后的最后一个判断

这本书的具体 API 已经有明显时代痕迹，照着包路径复制代码很可能跑不通。但它提供的概念地图仍然有价值。

我现在不会把 LangChain 当成大模型能力本身。它更像一套组织模型、数据、状态、工具和运行轨迹的方法。真正让应用可复用、可扩展的，仍然是清晰契约、受控权限、显式状态和持续评测。

框架会继续更新，工程问题不会。能够把这些问题看清楚，就是这次阅读最值得留下的收获。