7 posts tagged with "rag"

应该如何说起代码搜索呢，先说代码搜索的几个小的子流派吧，这方面可能略微和其他领域不同

代码的检索我认为是可以分解成以下几种的：

• 搜索引擎式
• grep传统搜
• 向量embedding搜
• 码仓index

每一种都是什么意思呢，举个例子

搜索引擎式是复用传统的搜索引擎，如elasticsearch, meilisearch等；也有一些变体，比如github的代码搜索，主要是弥补传统搜索引擎在代码搜索的不足

grep如其名字，基于linux grep或者riggrep，在agent内使用最广

向量embedding搜则有多个子任务，如NL2Code, Code2Code, Code2NL等，每个还有一些细微差别，这个很有意思，待会讲；

码仓index呢，则大致有两种：一种基于传统的AST分析，希望构建整个码仓的符号树或者CKG来辅助搜，另一种则寄希望于新型的生成式大模型，希望让LLM读了仓库之后能生成”索引“，典型的做法比如deepwiki。

搜索引擎式​

传统的搜索引擎其实在代码搜上有很多问题，参见

https://github.blog/engineering/architecture-optimization/the-technology-behind-githubs-new-code-search/

最严重的问题甚至不是想象的NL2Code的问题，而是传统搜索引擎的部分优化不够、部分优化又不足，总之不与代码适配

1. 索引的开销, 恐怖的内存消耗

当我们第一次部署 Elasticsearch 时，需要几个月的时间才能索引 GitHub 上的所有代码（当时大约有 800 万个存储库）。今天，这个数字已经超过 2 亿，而且代码不是静态的：它不断变化，这对搜索引擎来说是相当具有挑战性的。

2. 可不可以不要索引？对大规模库高并发是不可能的：

首先，让我们探讨一下解决问题的蛮力方法。我们经常收到这样的问题：“你为什么不直接使用 grep？为了回答这个问题，让我们使用 ripgrep 对这 115 TB 的内容进行一些数学计算。在具有八核 Intel CPU 的机器上，ripgrep 可以在 2.769 秒内对缓存在内存中的 13 GB 文件运行详尽的正则表达式查询 ，即大约 0.6 GB/秒/内核。 我们很快就会发现，这对于我们拥有的大量数据来说确实不起作用。代码搜索在 64 个核心、32 个机器集群上运行。即使我们设法将 115 TB 的代码放入内存中并假设我们可以完美并行化工作，我们也会在 96 秒内使 2,048 个 CPU 内核饱和，以处理单个查询！只能运行一个查询。其他人都必须排队。结果是每秒 0.01 次查询

3. 分词器不需要了：搜索引擎依赖分词来减少构建倒排的成本和作为基础搜索单元，但就和Tokenizer的引入一样，这个开销的减少从来不是免费的，接下来的问题就是：代码如何分词？另一个问题是：停用词全部没用了！无论是!@?/#$:{}()[]还是什么别的乱七八糟的符号，都是编程语言的最爱, 这使得传统的分词系统更加雪上加霜

   1. 如果提前跑一遍AST分析呢？我们的CPU要算爆炸了:), 并且你如何统一没有LSP小众语言，不同的语法版本（py2->3）... 工程量立刻爆炸了
   2. 能不能在char level倒排？太爆炸了索引，所以github是使用3-char的倒排的 argument -> arg、rgu、gum、...
   3. 代码里面还有注释，注释还有多语言，甚至单个仓库都很常见中英两种语言的注释...看起来朴素的分词器比如jieba要全面阵亡了...

4. 基于git的增量更新：增量更新本身可以用merkel tree，这也是cursor在用的技术，但结合git版本？你发现事情变得复杂起来了，这是纯工程的复杂性。一次git commit涉及到十几个文件的几行变化，需要触发至少十几个chunk的embedding更新？如何处理多分支呢？我的每一个存储代码块是否还得加一个tag标识它的branch，然后在搜索引擎里面支持完备地按tag过滤，省的不同branch的代码在同一个搜索引擎中返回？（然后发现branch name作为tag简直太烂了，它是一个完全动态的无限的集合）

鉴于恐怖的存储代码数量，github采用的搜索引擎相当简陋，甚至是弱化版本的完全匹配：3-grams索引

对于代码搜索，我们需要一种特殊类型的倒排索引，称为 ngram 索引，它对于查找内容的子字符串很有用。ngram 是长度为 n 的字符序列。例如，如果我们选择 n=3，则构成内容“limits”的 ngram 是 lim、imi、mit、its。(二元组的选择性不够，四元组占用了太多空间)

这个索引显然是非常大无法放入内存的，所以github采用了一些传统数据库里面的懒加载和流式优化技术，使得可以仅读取一个小子集完成搜索

而关于构建索引本身，github还有很多特殊设计，但这其实属于system/后端任务了，不细讲：

• 用Git blob object ID来分片，kafka分区

• 用path, branch, repository + 元信息(owner, visibility, etc.) 来构建增量索引key

• commit-level的一致性

• Github相当多的blob是相同的，使用增量编码很有吸引力, 这里用到了概率上的近似数据结构和一些分布式图（近似）算法

  To determine the optimal ingest order, we need a way to tell how similar one repository is to another (similar in terms of their content), so we invented a new probabilistic data structure to do this in the same class of data structures as MinHash and HyperLogLog. This data structure, which we call a geometric filter, allows computing set similarity and the symmetric difference between sets with logarithmic space. In this case, the sets we’re comparing are the contents of each repository as represented by (path, blob_sha) tuples. Armed with that knowledge, we can construct a graph where the vertices are repositories and edges are weighted with this similarity metric. Calculating a minimum spanning tree of this graph (with similarity as cost) and then doing a level order traversal of the tree gives us an ingest order where we can make best use of delta encoding. Really though, this graph is enormous (millions of nodes, trillions of edges), so our MST algorithm computes an approximation that only takes a few minutes to calculate and provides 90% of the delta compression benefits we’re going for.

Grep​

grep属实是在Coding Agent时代焕发了第二春，由于其系统级别自带+完美匹配Bash工具和Unix文本管道的特性，在现代的LLM之中都大量训练了如何写出各种米奇妙妙grep的数据

claude code这种经过更多优化的grep会更过分一点，它会有几个细节优化：

• 使用更现代的rg(riggrep)代替原始的grep
• 逆向cc源码可知，它的grep有七八个参数，分别对应grep里面的不同参数比如 -A -E -C , 除了一些呈现格式（比如带不带行号和文件名）之类的差别，主要的几个参数就是在匹配行前保留多少行、匹配行后保留多少行、和上下保留多少行
  • 如果读者熟悉coding agent的工作的话，其实早在swe-agent就已经探究过这个context window开多少的问题，原始论文的实验结论是50行

❯ tldr grep
grep
Find patterns in files using regular expressions.More information: https://www.gnu.org/software/grep/manual/grep.html.

 - Search for a pattern within a file:
   grep "{{search_pattern}}" {{path/to/file}}

 - Search for an exact string (disables regular expressions):
   grep {{[-F|--fixed-strings]}} "{{exact_string}}" {{path/to/file}}

 - Search for a pattern in all files recursively in a directory, showing line numbers of matches, ignoring binary files:
   grep {{[-r|--recursive]}} {{[-n|--line-number]}} --binary-files {{without-match}} "{{search_pattern}}" {{path/to/directory}}

 - Use extended regular expressions (supports ?, +, {}, (), and |), in case-insensitive mode:
   grep {{[-E|--extended-regexp]}} {{[-i|--ignore-case]}} "{{search_pattern}}" {{path/to/file}}

 - Print 3 lines of [C]ontext around, [B]efore or [A]fter each match:
   grep --{{context|before-context|after-context}} 3 "{{search_pattern}}" {{path/to/file}}

 - Print file name and line number for each match with color output:
   grep {{[-H|--with-filename]}} {{[-n|--line-number]}} --color=always "{{search_pattern}}" {{path/to/file}}

 - Search for lines matching a pattern, printing only the matched text:
   grep {{[-o|--only-matching]}} "{{search_pattern}}" {{path/to/file}}

 - Search stdin for lines that do not match a pattern:
   cat {{path/to/file}} | grep {{[-v|--invert-match]}} "{{search_pattern}}"

另一个有趣的事情是，现在的coding agent不约而同地使用了grep而不是rag作为其系统原生的工具，我觉得理由也是非常清晰的：

1. grep的输出是标准可预测的，而rag的输出依赖于 {基础模型， 分块方法，召回topk，重排模型} 等多个配置参数，一个标准的输出带来的好处是 可强化学习， 如果对一个 code llm + rag 的系统做RL，最后的搜索策略一定会是拟合到和rag的embedding模型和具体策略相匹配，丧失了可迁移性
2. 除此之外的好处也有很多，比如RL环境不需要embedding的额外开销（存储和计算上甚至编码成本上），整体轨迹可解释，精确匹配效果好，速度快...

rag的index开销其实相当大，学界不在乎这个，为了提升精度每个token一个embedding的方法也有，但一个embedding是一个1024维的向量，光存储开销就是4KB，对于百万行级别的代码仓库，其chunk可能在数万，达到了GB级别的存储开销

而工业项目有百万码仓，在TB级别的存储上进行高效地索引和查询着实压力很大，可以参考 美团和milvus/lancedb的相关文章 ，索引优化也有相当多的新实践，但这是做DB的人考虑的（雾

但Grep就是万灵药吗？并非如此

Grep提供了一个切面，能够让模型Agentic Search，根据搜索到的局部反馈调整搜索方法，从部分开始探索整个代码仓库——大部分需求的完成不需要对全仓的理解

——吗？

一个Grep的bad case是高阶语义的需求：

• 哪里导致了这个bug?
• 某个模块的核心逻辑是什么？
• 整体的代码结构？
• ...

模型要么老实cat，要么就只能在log中见到它尝试“猜”你的变量名字，比如你问“...的实现”就会开始Grep impl，如果你把所有变量换成abcde，它立刻就GG了

比起失败的搜索浪费的上下文更糟地是浪费的交互轮数 —— 长达几百轮的agent轨迹是相当稀少的训练数据，如果再配合没那么好的历史压缩方法，或是没有精心设计的防止模型死循环的额外环境反馈，连续失败的grep会让agent的性能迅速地劣化

基于这方面的需求，在推理阶段Grep还是得配合别的工具，比如deepwiki，比如CKG（代码知识图谱，例如每个函数的caller和callee），

比如Code RAG

这方面也有一些新的探索，例如 https://cognition.ai/blog/swe-grep 的RL并行工具调用（关键不在速度，关键在减少交互轮数！），比如在工程侧融合Grep和RAG如https://github.com/daimh/mgrep 和 https://github.com/zilliztech/claude-context ，以及我们将要发的一篇文章（自吹自擂一下，关注主包后续的工作谢谢喵）

code embedding​

主包主包，code embedding和文本的embedding有什么区别呢？为什么要强调code?

非常好问题，爱来自AI4SE。我认为code其实和图像比较像，某种意义上算是一种特殊的模态，不完全是文本——code某种意义上是“反语言常理”的，例如大部分语言的上下文有限，一句话很难和1000个字之前的某个东西形成强烈的联系，而这种长程交互在code之中非常常见——甚至有跨文件、跨模块、跨仓库的交互

而另一个很有趣的事情是，当我们在讲“某段代码的语义”的时候，这件事本身是模糊的，文本没有那么强的二义性，太阳就是太阳，月亮就是月亮，但一个递归斐波那契函数的语义到底是 “递归“ 还是 ”斐波那契“？这其实折射出了代码的某种特殊性，它同时具备字面义 ”斐波那契“ 和运行义 ”递归“（甚至”低效“、”算法“、“python”），而在一个代码仓库之中，代码还具备了上下游的属性：谁是我的caller，谁是我的callee?

这件事情为什么重要呢，因为传统的embedding向量相似度产出的是一个标量，它只能衡量一个维度的相似性！

• 当你在说“查找与function A相关的代码”时，你想要的到底是什么？
  • function A的字面义相关的代码？
  • function A的运行效果相关的代码？
  • function A的caller/callee?
  • ...

然后你就发现从这个角度上来说，Code2Code的向量搜是很诡异的一件事情，至少传统的cos相似度无法干这件事——

• 更悲伤（从学术研究的角度上来说或许是兴奋）的是，在现实需求中，我们真的不在意找到和一个function的字面意相关的function...假设你想要补全一段代码，你可能更需要关注谁会是它的caller，假设你需要优化一段代码，你可能搜索的方法是某种低效的pattern...而这些embedding相似度全部做不到
  • 据我所知，企业对这个接近摆烂了，只有MSRA有一个group还在研究，我之前溯源到的比较早的上下游建模技术是Order Embedding，感兴趣的或许可以试试做

直接结果是：我们只有NL2Code了

并且这个NL也只能关注一个方面...

什么样的NL才是真实会问会写的NL呢？Coding Agent的轨迹数据

没有轨迹数据怎么办？从大规模代码中挖掘注释作为NL

一个人写注释的方法和提问的方法不一样，这个语义空间的unmatch如何处理？各家自显神通

• 例如2025年5月快手的OASIS: Order-Augmented Strategy for Improved Code Search，认为现有的code embedding往往关注的是代码的字面相似性，即只把代码认为是一种特殊的“语言”，而忽略了代码的非文字意义上的相似性

  • 对代码片段（结合其他静态分析信息），用LLM产生其作用的描述文本
  • 计算这个描述文本和其他代码片段的相似性，以此来挖掘难负样本
  • 因为这个文本描述的是相对High Level的函数作用，能够一定程度上避免变量名字等带来的影响，专注于实际作用

• 24年12月的Nomic AI的cornstack

  • 强调<文档，代码>对的相关性重要性，并采用双重过滤：如果文档与代码间相似度低，或者并不在topK，只要有一个满足就筛掉
  • 动态硬负例挖掘策略：对于批内负样本挖掘，采用softmax概率采样，但是在训练过程中，逐步改变softmax的温度，前期温度高提高多样性，后期温度低，注重难负样本的区分

• 25年5月的BAAI Towards A Generalist Code Embedding Model Based On Massive Data Synthesis

  • 强调退火训练，第一阶段纯文本，第二阶段全数据训练text-code能力，第三阶段纯代码

码仓Index - DeepWiki/CKG​

这个说起来就比较简单了，deepwiki重要的始终是LLM的能力，而CKG则是静态分析的质量，开源的tree-sitter固然可用，企业也有一些统一各种语言的私有AST，静态分析已经日趋成熟，困难的是如何将这个信息给到LLM？

很早在Google的博客中就有论述: 现在的vibe coding就像是把一个几千行的代码粘贴到记事本里面，然后让程序员来修改bug —— LLM看到的就是 “记事本”，而不是程序员的带有各种Lint和跳转的IDE界面

AST分析树如此庞大，除了摆烂式地提供一个获取caller/callee的mcp工具给agent之外，还可以做些什么？

先前在web领域有一个llms.txt的旨在LLM-friendly的格式，代码领域却暂时缺乏哪怕是新兴的统一处理格式

AI-friendly IDE可能对于Coding Agent的能力提升相当重要，这也是moonbit社区他们宣传的，不过我没有实际上手用过，也不是学PL的，就不瞎讲了，感兴趣的可以看张宏波的演讲

【AI时代下的基础软件 | 张宏波 刘子悦 蚂蚁&MoonBit Meetup杭州站回放】

https://www.bilibili.com/video/BV1wL8DzgEXZ/

除此之外，可能我们原先认为不能搜索或者没必要搜索的部分，现在也正在发挥着额外的作用：

• python的package，众所周知（可能并非），pip包只是一个特殊的压缩包，可以直接看到文本格式的原始代码，现代的claude-sonnet-4等模型在环境出错的时候会主动读/搜 pyproject.toml, .venv等特殊文件，遇到import的不了解api还会尝试进入package观看源码
• 而某些binary风格或是一串神秘哈希引入的包可能对于LLM并不是很友好...

除此之外也有很多新兴的想法，例如注释本身可不可以作为一个天生的码仓Index? ...

CLI版本的Coding Agent好处是可以在各处方便的引用，尤其利于大规模并发采集数据

但IDE版本的Coding Agent则会更加地“懂人”，原因是AI IDE在背后做了一大堆不仅仅是diff等格式渲染的工作，用户环境信息，用户系统信息，... 这些都被从后台塞入了Coding Agent的system prompt，使得你在Linux上运行Copilot的时候，模型不会让你执行 brew install命令

但文本本身依然有着局限，或许在某个未来，我们能看到真正的code native架构，不在绞尽脑汁地想把编译器的报错，AST的分析等等原本结构化的东西转成markdown再塞入永远不够的agent上下文...

引子​

我们知道，在现在Agent需要处理的一大问题是长上下文下性能的开销问题，对此infra团队有非常多的优化，从attention架构的优化如各种windowed attention到kv的压缩重用如cacheblend和megicdec等都提出了一系列的解决方案，但有一个最本质的方法是：有没有可能直接减少上下文的长度(去掉不必要的上下文?) ，这就是Context Pruning的出发点。

而截止2025年8月，相关的方法已经发展了两三年了，大体上可以分成几个类别，本文会对此做一些简单的介绍和总结。

借用naver lab最新的相关论文里面的说法，现在的方法可以被一个四方格归纳：

其中，Hard和Soft代表裁剪方法是直接作用于token上（hard，相当于裁剪结束后，输入的是一个新的prompt），还是作用于token的embedding上（soft，相当于裁剪结束后，输入的是一个新的qkv和其他东西，无法还原出“原始”的token输入）

在线和离线一般代表着这个裁剪方案是否依赖于用户查询q，依赖q的方案是在线的，不依赖q的方案是离线的，可以提前做好。但传统上，如果你的裁剪方法也需要用到和原始模型一样大的LLM，也一般称之为离线，或许“是否会对在线推理造成明显时延影响”做划分更好一些

离线硬裁剪​

在最早期的时候，就有相关的一些朴素方法，例如直接对查询文本段做一次总结摘要，再用总结后的文本段去做后续的任务，这种方法是离线硬裁剪的典型代表。如果用的是llm就是离线的，如果用轻量级模型做摘要或者总结就是在线的

而在后面的时候，出现了例如微软的llmlingua这样的工作，直接用一个小模型(gpt2 small，llama-7b, etc)去预测哪些token是重要的，哪些token是不重要的，然后把不重要的token直接裁剪掉，这种方法也是离线硬裁剪的典型代表。(llmlingua2 换成了微调的 BERT 来做这个事情，所以可以说在线的)， 其出发点和常规的硬裁剪可能有部分地方不同，例如llmlingua认为，裁剪本身是可以得到一些人类不可读但是大模型可以理解的token序列的，所以可解释性上可能并没有想象的那么强。

离线软裁剪​

和硬裁剪同时推进的是软裁剪相关的工作，其想法很简单: 如果我牺牲解释性，直接调整prompt的embedding这类，即使产生的是不对应任何token的"fake embedding"，其在高维空间中也应该融合了多个token的语义，理应得到更高的压缩率(可以理解为，在训练过程中为llm 扩充为无限词表，然后定义了一些高效的"额外语言")

比较早期的工作是 xRAG， 其裁剪策略非常极端，将整个段落都压缩成1个embedding X，怎么训练呢？一个在此类论文中经常出现的是重建loss，即

压缩前$Doc + query \to x$

压缩后$Doc' + query \to x'$, $L=L(x',x)=D_{KL}(x',x)$， 即自蒸馏，希望压缩后依然能重建原始的输出，论文实际中可能会用变体版本来实现指令遵循等

xRAG的做法是，使用一个通用编码器E，把这个编码器E视作一个新的模态，仿照CLIP的方法直接用MLP projector做通用编码器和实际使用的LLM token embedding的模态对齐

但[大家实测下来](笔记：RAG 的相关优化方法之六（xRAG/PISCO） - 刀刀宁的文章 - 知乎 https://zhuanlan.zhihu.com/p/29292925032)，xRAG的效果并不好，而相对较好的是更新的Pisco方法

Pisco将检索到的文档D和memory tokens一起送到LLM中，产生embeddings

再将embeddings +query送到相同的LLM中，产生输出，这个 q+E 和原始的 q+D 比较， 计算交叉熵损失

这里有一些复杂的地方:

• 虽然叫解码和编码，但是Student LLM都是同一个LLM, 只是训练不同LoRA模块

• 交叉熵是怎么得出的? teacher模型和student模型都是采用的最大长度128的贪婪解码，就可以直接令 $L=-\sum 1logp + 0log(1-p) = - \sum_i log P(a_i|q,e,a_{<i},\theta_c,\theta_d)$， 优化目标是 $\theta_c$ 和 $\theta_d$ 还有 memory_tokens

• 如何理解memory token? 我觉得文章是借用了之前的一些研究比如ICAE, 在这些文章之中，训练的压缩机制是，将上下文压缩成一个定长的memory slot, 这里的memory token实际上只是多个embedding向量而已，而更关键的是LoRA微调的$\theta_c$，我的理解是，memory tokens只是一个后置的、可以看到Documents的所有信息（假设它没有魔改注意力）的语义位置，叫tokens也可以理解为直接扩了词表加入了l个特殊token，类似BERT里面的[BOS] ，只是decoder llm需要后置。

  • 文章并没有细说这里的注意力是怎么设置的，但从后文中发现的memory tokens具有明显的位置特性（例如1位mem token主要注意最开头一段），感觉应该是没改过

• 文章的另一个重要的实验结论是，微调student llm($\theta_d$)是必要的，之前的研究中没有相关模块，会导致性能的大幅度下降。这细想其实是一个很有趣的事情，可以注意到，压缩的时候是没有接触到query信息的（这也是为什么称为离线的原因），可以理解为某种意义上的LLM as an embedder，而加入了query和embedding再训练的时候，$\theta_d$一边学会了如何理解自己产生的embedding，另一方面学会了如何根据query去选择embedding，整体上类似于ColBERT架构的Reranker（前面是multi-vec embed, 后面是maxsim）

在线硬裁剪​

Provence

之前的裁剪方案只注重于“自然语言是有冗余的”，所以主要做的都是token-level的pruning，而provence则更注重实际一些，它发掘了一个问题是，其实现在RAG里面的 “Chunk” 是一个特别微妙的概念

如果chunk切得大了，那上下文自然就长了，甚至效果也会明显下降（详见ground truth在chunk中的不同位置的position bias相关的研究，现有embedder对这个bias耐受性不佳，会狠狠掉点）；但如果chunk切得小了，语义信息的丢失、检索的困难又是很恼人的事情（先不论检索，检索到了多个小块之后信息不够怎么办？一种是合并，但策略怎么定？另一种是Anthropic的Contextual Retrieval，把上下文放进来，本质上还是变成大块（我说这个a一串真是炒作勾啊.jpg））。

而Provence给了一个折中的方案，既然我们有句子级别的语义，为什么不用呢？分几步走

1. 训练一个接受q,d的BERT，给每一个token打0~1分，并根据用户指定的阈值进行二值化变为0/1, 表示删除/留下
2. 进行句子级别的聚类，裁剪掉0的token数量大于1的token数量的句子

如何训练呢？选取有5~10个句子的段（可以多次选取来拓展到更长的上下文），标上句子序号，让LLM选择相关句子来产生label，从而训练模型

这里其实做了很有意思的工程设计，

• 如果让LLM来打token-level的标，肯定是收集不到足够的样本的，并且真的无所谓多出来的几个token，更在意句意的完整性

• BERT带来了相当多的好处:

  • 这样进行的句子裁剪，每个句子都可以和整个chunk里面的所有上下文交互，使得一个句子的保留与否不仅取决于这个句子和查询的相关性，还取决于其于其他（和查询相关性高的）句子的相关性，这就使得这个方法必然会优于按句子切分的朴素方法

  • 我们的 reranker 也就是个BERT啊，完全可以训裁剪和训rerank一起进行，推的时候也一样，相当于和rerank overlap了

    

在线软裁剪​

Oscar

Pisco为代表的离线软裁剪有一个问题是，它的压缩需要微调，并且受限于难以对齐encoder-only架构的预训练编码器模态和实际推理使用的decoder LLM的模态，难以把压缩这一步在线做

Oscar就提出了一种方法是，我的对齐既然难做，我直接不对齐了，使用LLM的前L层 + memory token(他们也做了用Llama硬对齐的版本)，足以得到够好的embedding，文章最大的贡献其实是实验证明了这样表达能力已经足够，能训出来（太神奇了LLM）。当然，L越大效果越好

而还是复用Provence的工程技巧，把裁剪和rerank overlap起来，OSCAR的compressor留了一个RR头，在这个头和Teacher Reranker对齐，整体的Loss就是rerank loss + generation loss

而令LLM理解embedding这件事情还是通过LoRA adapter来做，这篇文章其实像是序列工作的延申，综合了PISCO的训练方法，把PISCO的压缩部分从LLM + LoRA换成目标模型的前N层transformer，然后压缩器全参微调、生成器LoRA微调，再使用和Provence相同的技巧进行rerank的overlap

异曲同工​

从HyDE到“投机解码”​

另一个有趣的工作是广义上的“裁剪”，或者就是更好的搜索吧。我们知道HyDE的思想是原始query一般都比较短，而生成的假设文档可能会更好地与索引文档对齐，所以使用 q‘ = q + generated d 来进行搜索。

而智谱的memorag 则提出了这样一种场景，我们是否能以低成本训练一个小模型，来根据源文本生成这个假设答案呢？（例如，使用Llama3-8B在哈利波特上训练比用Deepseek-R1在哈利波特上训练成本要低廉的多，将HyDE的生成方从R1自己换成小模型）这就非常像是投机解码的思想了

外接模块: memory decoder, catridges​

其实这种将memory训为embedding的方法确实不少，如果说前面的压缩器是在训一个meta network，能够从doc生成embedding的话，外接模块的工作就是在训练embedding本身 -> 我能否直接从一个大的文档库中训练出一个参数化的memory?

最近的memory decoder选择的是直接扭曲生成过程，将一个小模型在目标适配数据集上训练，在大模型生成token时，将小模型的概率和大模型的概率相加（再重归一化），认为这样会带来领域知识的纠正（比较暴力www）

而另一篇catridges 则是在使用类似P-tuning的方式训一个Prefix KVCache，在推理时实时加载，而希望这个KV中有相关的memory

包括一系列的kvcache evict的工作也是在做类似的东西，为了决定evict哪些甚至都把搜索又搬上来了，比如clusterKV的knn(笑)

总结​

总体而言，我感觉相关工作已经进入了深水区了，硬裁剪可能在某些程度上到头了，现在主流在探索一些牺牲解释性的，更能scale out的方法来进行参数化memory来解决长上下文、领域适配等一系列问题

而大家方法逐渐趋向于无标签学习的统一也再次证明了scale out能力在广义embedding能力的训练上的重要性

另一个很有意思的是，可以看到搜索中的多向量和多memory token有一些很有趣的相似性，或许在后续的一些工作中，我们能看到一些多向量的方法被用到memory之中，希望会让memory这个很多时候靠prompt编故事的领域更多可验证性吧

而从另一个方面，正如这里列出的部分文章说的，自从eagle在投机解码中得到了确实很好的效果之后，大家都开始用 token + embedding的混合来捕捉更强的信息了，还有HyDE和投机解码这种很有趣的对应

假如大伙接到一个需求，需要把claude code接入jupyter前端（例如，在jupyter前端直接输入魔法指令和claude code交互，而后台claude code展示claude code的一些关键节点，工具调用，费用开销，输出结果等），会怎么做？

一种想法是，将claude code的输出塞到一个文件里面去，起一个后台线程读取这个文件，尝试解析之中的某些部分，再以插件的形式加载到jupyter前端

但带来了一个问题是，效果（尤其是工具数量upup，上下文长度upup后的效果）不稳定，纯prompt的形式约束claude code及时向这个文件中写入以向前端通信，在经过长的交互过程后，claude经常会把这个文件忘掉

那claude code直接全塞前端呢？

在claude code里面问一个问题，可能就是几千上万token的交互，全塞前端，那用户体验就烂掉了。

另一个很容易想到的方案是，那我们不要让他输出文件了，直接当场处理把，定义一些特殊块叫 display 之类的东西，在prompt里面指定这个块里面是什么格式，让他如果想要和前端输出的话，放到这个块里面

这样看起来比文件好一些，但带来了新的问题没解决，长上下文下，display块的结构偶尔会有不稳定，会有不少特殊的渲染格式如html等由于几个字符的差异退化成了纯文本

如何修复这个呢？一个简单的方法，也是你能在任意一个现在的agent中看到的，是及时判错，再把把错误的部分发给模型让他修复一下，但又带来了额外的开销，并且前端的呈现也收到影响

有没有更优雅的办法呢？

如果你做AI应用比较多的话，肯定注意到了这实际上是一个结构化输出(约束解码)的场景，但现在的问题是，输出不止是一个json，而是正常文本块和display块的交错

（对于不了解约束解码的简单介绍一下，就是把上层的json等约束编译成状态机之后，用于动态建立llm output logits的mask，从而杜绝输出非法输出的技术）

看起来似乎不能约束解码？但display块本身是可以约束解码的，好恶心。

让我们打开vllm文档，翻到 Structured Outputs，你会发现，除了常见的regex约束解码之外，还有两种更强语义的解决方案，救赎之道就在其中，ebnf解码和structure tags解码

实际上，json解码只不过是ebnf解码的特殊情况罢了，毕竟实际都是状态机 （不知道ebnf是什么的同学，可以搜索一下编译前端，BNF范式，就能看懂下面的示例啦）

官方给的一个ebnf解码的例子如下, 用于执行一个简化sql的约束解码以提升sql正确率

simplified_sql_grammar = """
    root ::= select_statement

    select_statement ::= "SELECT " column " from " table " where " condition

    column ::= "col_1 " | "col_2 "

    table ::= "table_1 " | "table_2 "

    condition ::= column "= " number

    number ::= "1 " | "2 "
"""

completion = client.chat.completions.create(
    model=model,
    messages=[
        {
            "role": "user",
            "content": "Generate an SQL query to show the 'username' and 'email' from the 'users' table.",
        }
    ],
    extra_body={"guided_grammar": simplified_sql_grammar},
)
print(completion.choices[0].message.content)

如果放到这个问题，我们可以快乐地写出类似这样的定义

output := (display | normal text) *
display := (```display json ```)
json = ...
normal text = others

其中，display, json都是容易得到的，但恶心的地方在于什么是“others” 未拓展的ebnf是没有“非”定义的，从实操上虽然感觉可行（mask token取反），但这下已经没有支持了

（但ebnf解码肯定是有大用的，还是以Text2SQL举例，任何一个数据库都会给你他们的解析引擎的ebnf定义，都不需要你写）

怎么办呢，就带来了最后一个冷门工具，structured tags， 我先上代码，

def get_structural_tag_params(
    tags: list[StructuralTag], triggers: list[str]
) -> dict:
    return {
        "type": "structural_tag",
        "structures": [model.model_dump() for model in tags],
        "triggers": triggers,
    }

    model_v2 = ChatOpenAI(
        base_url=base_url,
        model=model_name,
        api_key=api_key,
        temperature=0.15,
        top_p=0.9,
        extra_body={
            "response_format": get_structural_tag_params(
                tags=[
                    StructuralTag(
                        begin="<block=text>",
                        end="</block>",
                        schema=TextMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=image>",
                        end="</block>",
                        schema=ImageMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=tool_use>",
                        end="</block>",
                        schema=ToolUseMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=todo_list>",
                        end="</block>",
                        schema=TodoListMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=html>",
                        end="</block>",
                        schema=HTMLMsgSchema.model_json_schema(),
                    ),
                ],
                triggers=["<block="],
            )
        },
    )

这个tags + triggers, 就是structured output的关键之处，它允许我们在trigger触发的时候才开始约束解码，在end结束的时候停止约束解码

至此，这个工作已经做完了

那约束解码和不约束带来的效果差距有多大呢，我在24B的Mistral-Small上做了个实验 最后的结果直接尝试解析后渲染到前端

Prompt如下，

sys_prompt = f"""

你是一个agent模型，你负责处理用户的问题，发起工具调用, 绘制图片、html、获取文本等。

由于你的token交互量很大，不是所有信息都需要展示给前端。

你可以正常思考和输出，但你需要将你认为需要展示给用户的有效信息包裹在 `<block={{tag}}> {{schema}} </block>` 中。

前端会将这部分内容进行渲染，交给用户。

你现在可用的tag有:

tags: "text", "image", "tool_use", "todo_list", "html"

对应的schema(pydantic格式)如下:

- {schemas_str}

例如，你可以先产生一个todo list，然后不断执行子任务，并更新todo list，直到所有任务完成。

由于你现在没有接入工具调用，所以对于所有工具调用交互，你只需要“假装”执行了工具调用并得到一个合理的响应就行，这是一个debug环境，

你需要根据用户的问题尽可能多的展示不同的block，并给出一个合理的响应。

"""

这个prompt下，<block=text>111</block> 这种就取代了上文所述的display块的效果

只定义了五种特殊的前端展示格式，文本，图片，TODO list，工具调用和HTML块

效果对比如下：

用户：帮我完成编写一个论坛帖子，打开浏览器的水源社区论坛，登录之后在discourse发帖的流程。

可以看到，左侧没有约束解码的模型，在这样的任务负载下，json 参数就已经频频出现失误了，而右边的即使是24B模型的fp8量化非思考版本，却跑出了几百B agent的气势，并且token开销是来回倒腾的几分之一

一点感想： 我们常说一个子领域的知识对于另一个子领域是用处寥寥的，然而，这不是拒绝新领域知识的理由啊，vllm和xgrammer、outlines这种框架都把几种更强大的结构化解码方法摆到人们的脸上了，还是能在知乎看到“ebnf好像是编译原理的内容，（作为后端程序员）跳过”，或者是在各种开源仓库中还在广泛使用的拿prompt指导llm输出，完全不考虑（甚至不知道）结构化输出这样的东西

现在的后端、infra、算法，又有多少更深的优化方案是独立的呢？今天在看snowflakes优化方案，真是把上层算法和底层infra相辅相成，只是缺乏探索性的人们，会拿"这不是我的工作，这是专攻模型/infra/算法的人的工作"搪塞，最后又堆起来一个prompt史山罢了

在现在的agent框架中，充斥的也是prompt的兜底方案，带来的是qwen3-coder几个问题爆掉用户百万token，带来的是claude code问个“你是谁”都要花一角钱，但有没有一种可能，我们本可以用更确定的东西呢？LLM是一种万能的模糊推理，但好钢也要用在刀刃上啊。

参考完整代码如下

# ruff: noqa: E501
# SPDX-License-Identifier: Apache-2.0
# SPDX-FileCopyrightText: Copyright contributors to the vLLM project

import argparse
import asyncio
import enum
import json
import os
import re
from pathlib import Path
from typing import Any

import colorlog
import openai
from langchain_core.messages import HumanMessage, SystemMessage
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field
from dotenv import load_dotenv

load_dotenv()


class StructuralTag(BaseModel):
    begin: str
    end: str
    schema: dict[
        str, Any
    ]  # JSON schema for validation, model_dump by pydantic model


class TextMsgSchema(BaseModel):
    text: str = Field(..., description="Text message")

    def to_html(self) -> str:
        """Render text message as HTML"""
        return f'<div class="text-message">{self.text}</div>'


class HTMLMsgSchema(BaseModel):
    raw_html: str = Field(..., description="raw html str, like <div></div>")

    def to_html(self) -> str:
        """Render HTML message as HTML"""
        return f'<div class="html-message">{self.raw_html}</div>'


class ImageMsgSchema(BaseModel):
    image_url: str = Field(..., description="Image URL")
    image_name: str = Field(..., description="Image name")

    def to_html(self) -> str:
        """Render image message as HTML"""
        return f"""<div class="image-message">
            <img src="{self.image_url}" alt="{self.image_name}" style="max-width: 100%; height: auto;">
            <p class="image-caption">{self.image_name}</p>
        </div>"""


class ToolUseMsgSchema(BaseModel):
    tool_name: str = Field(..., description="Tool name")
    args: dict[str, Any] = Field(..., description="Tool args")
    tool_output: dict[str, Any] = Field(..., description="Tool output")

    def to_html(self) -> str:
        """Render tool use message as HTML"""
        args_html = json.dumps(self.args, indent=2, ensure_ascii=False)
        output_html = json.dumps(self.tool_output, indent=2, ensure_ascii=False)
        return f"""<div class="tool-use-message">
            <h4>Tool: {self.tool_name}</h4>
            <div class="tool-args">
                <strong>Arguments:</strong>
                <pre>{args_html}</pre>
            </div>
            <div class="tool-output">
                <strong>Output:</strong>
                <pre>{output_html}</pre>
            </div>
        </div>"""


class TodoListMsgSchema(BaseModel):
    todo_list: list[tuple[bool, str]] = Field(..., description="Todo list")

    def to_html(self) -> str:
        """Render todo list message as HTML"""
        items = []
        for done, item in self.todo_list:
            checked = "checked" if done else ""
            item_class = "completed" if done else "pending"
            items.append(
                f'<li class="{item_class}"><input type="checkbox" {checked} disabled> {item}</li>'
            )
        items_html = "\n".join(items)
        return f"""<div class="todo-list-message">
            <h4>Todo List</h4>
            <ul class="todo-list">
                {items_html}
            </ul>
        </div>"""


def get_structural_tag_params(
    tags: list[StructuralTag], triggers: list[str]
) -> dict:
    return {
        "type": "structural_tag",
        "structures": [model.model_dump() for model in tags],
        "triggers": triggers,
    }


def parse_structured_response(response: str) -> str:
    """Parse structured response and convert blocks to HTML"""
    # Schema mapping
    schema_classes = {
        "text": TextMsgSchema,
        "image": ImageMsgSchema,
        "tool_use": ToolUseMsgSchema,
        "todo_list": TodoListMsgSchema,
        "html": HTMLMsgSchema,
    }

    def replace_block(match):
        tag_type = match.group(1)
        content = match.group(2).strip()

        if tag_type not in schema_classes:
            return match.group(0)  # Return original if unknown tag

        try:
            # Parse JSON content
            data = json.loads(content)
            # Create schema instance
            schema_instance = schema_classes[tag_type](**data)
            # Return HTML
            return schema_instance.to_html()
        except (json.JSONDecodeError, ValueError) as e:
            return (
                f'<div class="error">Error parsing {tag_type} block: {e}</div>'
            )

    # Replace all <block=type>content</block> with HTML
    pattern = r"<block=(\w+)>\s*(.*?)\s*</block>"
    return re.sub(pattern, replace_block, response, flags=re.DOTALL)


def create_comparison_html(response1: str, response2: str) -> str:
    """Create a comparison HTML page with both responses"""
    parsed_response2 = parse_structured_response(response2)

    css = """
    <style>
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
            margin: 0;
            padding: 20px;
            background-color: #f5f5f5;
        }
        .container {
            max-width: 1200px;
            margin: 0 auto;
            background: white;
            border-radius: 8px;
            box-shadow: 0 2px 10px rgba(0,0,0,0.1);
            overflow: hidden;
        }
        .header {
            background: #2563eb;
            color: white;
            padding: 20px;
            text-align: center;
        }
        .comparison {
            display: flex;
            min-height: 600px;
        }
        .column {
            flex: 1;
            padding: 20px;
            border-right: 1px solid #e5e5e5;
        }
        .column:last-child {
            border-right: none;
        }
        .column h3 {
            margin-top: 0;
            color: #1f2937;
            border-bottom: 2px solid #e5e5e5;
            padding-bottom: 10px;
        }
        .content {
            line-height: 1.6;
            color: #374151;
        }
        
        /* Schema-specific styles */
        .text-message {
            background: #f8fafc;
            padding: 15px;
            border-radius: 8px;
            margin: 10px 0;
            border-left: 4px solid #3b82f6;
        }
        .image-message {
            background: #f0fdf4;
            padding: 15px;
            border-radius: 8px;
            margin: 10px 0;
            border-left: 4px solid #10b981;
            text-align: center;
        }
        .image-caption {
            margin: 10px 0 0 0;
            font-style: italic;
            color: #6b7280;
        }
        .tool-use-message {
            background: #fefce8;
            padding: 15px;
            border-radius: 8px;
            margin: 10px 0;
            border-left: 4px solid #eab308;
        }
        .tool-use-message h4 {
            margin: 0 0 10px 0;
            color: #92400e;
        }
        .tool-args, .tool-output {
            margin: 10px 0;
        }
        .tool-args pre, .tool-output pre {
            background: #1f2937;
            color: #f9fafb;
            padding: 10px;
            border-radius: 4px;
            overflow-x: auto;
        }
        .todo-list-message {
            background: #fdf2f8;
            padding: 15px;
            border-radius: 8px;
            margin: 10px 0;
            border-left: 4px solid #ec4899;
        }
        .todo-list-message h4 {
            margin: 0 0 10px 0;
            color: #be185d;
        }
        .todo-list {
            list-style: none;
            padding: 0;
        }
        .todo-list li {
            margin: 5px 0;
            padding: 5px 0;
        }
        .todo-list li.completed {
            text-decoration: line-through;
            opacity: 0.7;
        }
        .html-message {
            background: #f5f3ff;
            padding: 15px;
            border-radius: 8px;
            margin: 10px 0;
            border-left: 4px solid #8b5cf6;
        }
        .error {
            background: #fef2f2;
            color: #dc2626;
            padding: 15px;
            border-radius: 8px;
            margin: 10px 0;
            border-left: 4px solid #dc2626;
        }
        pre {
            white-space: pre-wrap;
            word-wrap: break-word;
        }
    </style>
    """

    return f"""
    <!DOCTYPE html>
    <html lang="zh-CN">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>模型响应对比</title>
        {css}
    </head>
    <body>
        <div class="container">
            <div class="header">
                <h1>模型响应对比</h1>
                <p>左侧：无结构化标签 | 右侧：带结构化标签（已渲染）</p>
            </div>
            <div class="comparison">
                <div class="column">
                    <h3>无 Structure Tag</h3>
                    <div class="content">
                        <pre>{response1}</pre>
                    </div>
                </div>
                <div class="column">
                    <h3>Structure Tag（已渲染）</h3>
                    <div class="content">
                        {parsed_response2}
                    </div>
                </div>
            </div>
        </div>
    </body>
    </html>
    """


if __name__ == "__main__":
    base_url = "localhost:8000/v1"
    model = openai.OpenAI(base_url=base_url, api_key="sk-")
    schemas = [
        TextMsgSchema.model_json_schema(),
        ImageMsgSchema.model_json_schema(),
        ToolUseMsgSchema.model_json_schema(),
        TodoListMsgSchema.model_json_schema(),
        HTMLMsgSchema.model_json_schema(),
    ]
    schemas_str = "\n- ".join([json.dumps(s, indent=4) for s in schemas])
    sys_prompt = f"""
你是一个agent模型，你负责处理用户的问题，发起工具调用, 绘制图片、html、获取文本等。
由于你的token交互量很大，不是所有信息都需要展示给前端。
你可以正常思考和输出，但你需要将你认为需要展示给用户的有效信息包裹在 `<block={{tag}}> {{schema}} </block>` 中。
前端会将这部分内容进行渲染，交给用户。

你现在可用的tag有:
tags: "text", "image", "tool_use", "todo_list", "html"
对应的schema(pydantic格式)如下:
- {schemas_str}

例如，你可以先产生一个todo list，然后不断执行子任务，并更新todo list，直到所有任务完成。
由于你现在没有接入工具调用，所以对于所有工具调用交互，你只需要“假装”执行了工具调用并得到一个合理的响应就行，这是一个debug环境，
你需要根据用户的问题尽可能多的展示不同的block，并给出一个合理的响应。

    """
    base_url = "http://localhost:8000/v1"
    model_name = "stelterlab/Mistral-Small-3.2-24B-Instruct-2506-FP8"
    api_key = "sk-"
    model = ChatOpenAI(
        base_url=base_url,
        model=model_name,
        api_key=api_key,
        temperature=0.15,
        top_p=0.9,
    )
    print("-" * 50)
    logger = colorlog.getLogger("Agent")
    msgs = [
        SystemMessage(content=sys_prompt),
        HumanMessage(
            content="帮我完成编写一个论坛帖子，打开浏览器的水源社区论坛，登录之后在discourse发帖的流程。"
        ),
    ]

    model_v2 = ChatOpenAI(
        base_url=base_url,
        model=model_name,
        api_key=api_key,
        temperature=0.15,
        top_p=0.9,
        extra_body={
            "response_format": get_structural_tag_params(
                tags=[
                    StructuralTag(
                        begin="<block=text>",
                        end="</block>",
                        schema=TextMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=image>",
                        end="</block>",
                        schema=ImageMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=tool_use>",
                        end="</block>",
                        schema=ToolUseMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=todo_list>",
                        end="</block>",
                        schema=TodoListMsgSchema.model_json_schema(),
                    ),
                    StructuralTag(
                        begin="<block=html>",
                        end="</block>",
                        schema=HTMLMsgSchema.model_json_schema(),
                    ),
                ],
                triggers=["<block="],
            )
        },
    )

    logger.info("=== 测试开始 ===")
    response1 = model.invoke(msgs).content
    logger.info(f"=== 测试结束 ===\n{response1}")

    logger.info("=== 测试开始 ===")
    response2 = model_v2.invoke(msgs).content
    logger.info(f"=== 测试结束 ===\n{response2}")

    # 生成对比HTML文件
    comparison_html = create_comparison_html(response1, response2)
    Path("tmp/test_comparison.html").write_text(
        comparison_html, encoding="utf-8"
    )
    logger.info("已生成对比HTML文件: tmp/test_comparison.html")

    # 保留原有的Markdown文件
    with Path("tmp/test_diff.md").open("w", encoding="utf-8") as f:
        f.write("无structure tag: \n")
        f.write(response1)
        f.write("\n\nstructure tag: \n")
        f.write(response2)

rag那边最近看到的新的概念，现在prompt工程不叫prompt工程了，叫上下文工程 （context engineering）,笑

上下文工程概念的兴起主要是两个方面，一是更关注多轮和工具，prompt无法很好地概括这些部分，二是模型的能力并不能做到和声称的上下文一样（支持1M长度的模型，可能长度超过32K指标就会严重下滑）

上下文失败的几种情况，参考 How Long Contexts Fail | Drew Breunig

• 上下文中毒: 幻觉和错误进入上下文，并反复引用，这个主要来源于google在用智能体玩游戏时出现的一些现象（超长程规划）

An especially egregious form of this issue can take place with “context poisoning” – where many parts of the context (goals, summary) are “poisoned” with misinformation about the game state, which can often take a very long time to undo. As a result, the model can become fixated on achieving impossible or irrelevant goals.

• 上下文干扰 & 混淆 上下文干扰是指上下文变得太长，以致模型过度关注上下文，而忽略了在训练期间学到的内容。

The Berkeley Function-Calling Leaderboard is a tool-use benchmark that evaluates the ability of models to effectively use tools to respond to prompts. Now on its 3rd version, the leaderboard shows that every model performs worse when provided with more than one tool4. Further, the Berkeley team, “designed scenarios where none of the provided functions are relevant…we expect the model’s output to be no function call.” Yet, all models will occasionally call tools that aren’t relevant.

随着模型变小，问题变得越来越严重

问题是：如果你把某些东西放入上下文中, 模型就必须注意它。 它可能是无关的信息或不必要的工具定义，但模型会将其考虑在内。大型模型，尤其是推理模型，在忽略或丢弃多余上下文方面做得越来越好，但我们仍然看到无用的信息绊倒了智能体

关于信息之间和信息与问题的交互，google和其他机构都有不少的research paper，现在广泛认为，信息自己有几个“原子事实”不太重要，但信息之间的的一致性和独立性（相互cover不同部分以从根本解决信息冲突的问题）以及信息和query的相关性很重要

• 上下文冲突 A Microsoft and Salesforce team documented this brilliantly in a recent paper.

分阶段提供信息，模型的表现严重下降

We find that LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely. In simpler terms, we discover that when LLMs take a wrong turn in a conversation, they get lost and do not recover. 我们发现，LLM 们经常在早期阶段做出假设，并过早地尝试得出最终解决方案，而他们过度依赖这些解决方案。简而言之，我们发现，当 LLM 们在对话中走错方向时，他们会迷失方向，无法恢复。

Andrew Karpathy依然擅长炒作，他的观点是LLM as a new OS. Context is RAM

上下文工程：在上下文窗口中为下一步填充恰到好处的信息的科学

有哪些呢？

• Instructions
• Knowledge
• Tools

上下文工程策略：写入上下文，选择上下文，压缩上下文，隔离上下文

写入上下文：

• 临时笔记板，可以是会话的状态对象，也可以是简单的工具调用写文件 Anthropic 的研究表明，将“笔记板”工具与特定领域的提示配对使用可以带来显著的收益，与专业代理的基准相比，最高可提高 54%。这也称作上下文卸载（Context Offload）, 参考 The "think" tool: Enabling Claude to stop and think \ Anthropic

Anthropic identified three scenarios where the context offloading pattern is useful: Anthropic 确定了上下文卸载模式有用的三种场景：

Tool output analysis. When Claude needs to carefully process the output of previous tool calls before acting and might need to backtrack in its approach; Policy-heavy environments. When Claude needs to follow detailed guidelines and verify compliance; and Sequential decision making. When each action builds on previous ones and mistakes are costly (often found in multi-step domains).

• 记忆：跨模型、跨会话，独立存储。Reflexion + 定期整理记忆

选择上下文：

• 记忆选择：Langchain将记忆归为几种类别：Semantic, Episodic, Procedural 对应 Facts，Experiences和Instructions，一个挑战是选择相关记忆。Claude Code使用CLAUDE.md，Cursor和Windsurf使用规则文件
• 工具管理：例如对工具list用RAG，这个在现在的MCP中很多都在尝试，比如OSPP就有这样的项目

压缩上下文：Claude Code当交互占用超过上下文的95%之后，会自动压缩，总结用户-Agent的完整轨迹。可以是递归或者分层摘要。也可以在一些特定点添加摘要（如某些工具调用），Cognition为此使用微调模型 上下文修剪：启发式删除旧信息，provence作为上下文修剪器

隔离上下文：

• 拆分到子Agent之间，OpenAI Swarm动机是关注点分离，一组Agent完成各自的子任务
• 工具代码沙箱

LangGraph & LangSmith

LangGraph 在记忆（状态）上面做了努力，选择 上下文也通过这个State获取，压缩上下文通过状态对象进行自定义逻辑，隔离通过子图和节点

LangGraph基于状态机的实现倒是暗合了OS=状态机的观点，从一个比较底层的视角上为各种上层应用提供了可能，也可以复用业界关于状态机的一系列优化已有实践

而关于上下文管理的评估侧，一个比较热门的评估和观测系统Galieo设置了四种指标来评估一个RAG应用: Adherence,Completness, Utilization,Attribution 对上文的忠实度，上文本身对解答这个问题的完整性，答案对于上文的利用度，答案对于不同chunk的归因

在它的博客之中，给了一个非常真知灼见的观点是，过多的指标本身没什么意义，它选择这四个指标的原因是能定位出是链路的哪一块出现了问题，这个指标也只有low, medium, high三级，不做复杂的打分，倒是有点像是推荐系统里面的分桶离散特征

例如，如果整体利用度低，但完整度高，那么冗余信息太多了，减少chunk size和输入LLM的chunk数量N；如果整体忠实度高，但完整度低，则需要考虑是搜索的问题（多样性考虑不够）还是数据的问题（根本就没有足够多的文档）；而归因性可以用来调整chunk size，裁剪等参数；忠实度不够则主要从prompt和chunk数量入手......

与其他一切最终被广泛利用的策略相同，Galieo也蒸馏了一个小BERT来代替昂贵的LLM进行打分，以此提供一个本地托管的方案

另一个上下文管理的有趣的工作是直接进行暴力的token-level prompt压缩，来自微软的LLMLingua论文，其基于两个观察

• 自然语言有冗余
• 传统的信息熵指标只有单向上下文, 且与提示压缩指标不一致 因此，开蒸！总之也是训了XLM-RoBERTa-large & mBERT的模型替代LLM（可以发现现在的RAG基本就是 寻找问题-大模型蒸馏训练-用专业小模型代替-形成nlp管道 的范式，在几乎每一个组件都是如此，效果也好）

如何进行reranker微调？

之前我曾经花了一定时间找这个问题的经验，结果发现大部分reranker模型对于这个问题是一个回避状态，不愿意开源自己的训练集，更不提像OpenAI/Cohere的rerank/embed服务本身就在卖钱，而兜售rag解决方案的公司，更不肯将如何做领域适配这一赚钱核心逻辑公之于众

也就BAAI以一个非常开放的态度，公开了自己的微调方法和相关脚本和训练数据，但他们也更侧重与如何训练一个通用的模型，对于怎么微调，只知道构造正负样本，query，pos，neg，然后InfoNCE，至于为什么能work，pos/neg怎么选，可能觉得大家都知道，也没有多说

而兜兜转转的楼主最后在传统搜推里面找到了一整套硬负例挖掘方面的方案，rag整套方案其实都是抄搜推的一个劣化版本罢了 🤣

为什么采用的是正负对而不是交叉熵或者其他有label的损失？核心在于，搜推本身就是一个弱label的场景

乍一想，在有正负对的情况下的时候，交叉熵似乎也很自然，以01为例，两种损失项就是 $<user, item_+, 1>， <user, item_-, 0>$ ? 但一个随之而来的问题是哪来的01 label?

也就是说，这样做的前提是label的准确性，而在搜推场景中，负样本 $<user, item_-, 0>$ 的一个设置是曝光过但没被user选择的真负样本

但召回层的大部分样本根本没被曝光过，label噪声很大（召回层是一个几亿->几千->几十条的过程，只有最后的几十被曝光了），如果只依赖这样的负样本的话，根本无法支撑模型训练。所以正负样本的设计某种意义上是无奈之举，我无法知道这个样本和用户的真实关系，但我可以从用户的行为中得到一些偏好信号，召回算法往往采用Pairwise LearningToRank （LTR），建模排序的相对准确性，模型的优化目标变成正样本匹配度高于负样本匹配度

现在我们知道了为什么采用正负样本，但真正上手就会发现，正负样本这一件事并没有想象中的简单。

如果你采用随机的语料作为负样本，带来的一个问题是这个负样本对模型太easy了，模型只能区分猫和狗，但无法区分哈士奇和狼狗，即忽视了细节信息，也即是我们所说的rag的领域细节的缺失

而解决的方法，也在搜推里面早就提出了，硬负样本挖掘，即设置一部分的硬负样本，这部分是有难度的，来迫使模型学会根据细节进行区分

而在rag里面大家常常是拍脑门的硬负样本设计，让reranker带上一些业务目标，在搜推里面也早是被玩烂的东西了。

先说业务目标： 比起rag中，大部分的应用还局限在文本相似度，搜推早就进入到多个因素的融合和全链路目标指向的优化，例如，很多搜推业务需要考虑地域性（如外卖，酒店等），于是其正负样本会这样设计: 有基于业务逻辑的，核心是增强某个指标的相似性，让模型考虑其他指标做出区分，以房屋销售为例

• 增加与正样本同城的房间作为负样本，增强了正负样本在地域上的相似性，加大了模型的学习难度
• 增加“被房主拒绝”作为负样本，增强了正负样本在“匹配用户兴趣爱好”上的相似性，加大了模型的学习难度

针对模型只学地域特征信息就可以进行打分的easy neg，设计了同城的hard neg强迫考虑其他特征

绝大部分负样本还是随机采样生成的。但是，Airbnb发现，用户点击序列中的listing多是同城的，导致正样本多是同城listing组成，而随机采样的负样本多是异地的，这其中存在的bias容易让模型只关注“地域”这个粗粒度特征。

为此，Airbnb在全局随机采样生成的负样本之外，还在与中心listing同城的listing中随机采样一部分listing作为hard negative，以促使模型能够关注除“地域”外的更多其他细节。

在电商场景下，负样本的业务构造也有很多：

• 正样本：充足曝光下高点击ctr样本(如：ctr大于同query下商品点击率平均值)
• 负样本：
  • 同父类目的邻居子类目负采样。
  • 高曝光低点击类目样本：同一个query搜索下，根据全局点击商品的类目分布，取相对超低频类目样本作为负样本。
  • 充足曝光情况下，低于相应query平均曝光点击率一定百分比的样本做负样本。
  • 基于query核心term替换构造负样本：如，对于“品牌A+品类”结构的Query，使用“品牌B+品类”结构的query做其负样本。（这个lz当时在propilot构造领域词替换负样本的时候还觉得自己想到了个好方法，后来发现是早有之事）
  • 随机构造负样本：为增加随机性，该部分实现可在训练时使用同batch中其他样本做负样本，同时也可以引入经典的Hard Sample机制。（这部分涉及到很有趣的一个问题，后面讲）

不局限于业务，搜推还对RAG很少涉及的“如何选择hard neg”上面有非常久远的研究，如

• 高置信样本挖掘，避免搜索点击行为日志“点击但不相关”的问题。

• **定制化的负样本构造，避免模型收敛过快，**只能判断简单语义相关性，对难样本无法很好的区分。

• 关于短文本的定制化需求， 如美团提到的他们实践的一些难Case，“大提琴”→“小提琴”以及“葡萄酒”→“葡萄”这类字面编辑距离小的case，会根据搜索结果做分析，以搜索无结果作为bad case进行负样本生成

• 知识图谱也是被玩烂的东西

• 图结构也是被玩烂的东西，如在Pinterest中，基于GCN的PinSAGE

和Airbnb一样，我们可以认为被同一个user消费过的两个item是相似的，但是这样的排列组合太多了。

为此，PinSAGE采用随机游走的方式进行采样：在原始的user-item二部图上，以某个item作为起点，进行一次二步游走（item→user→item），首尾两端的item构成一条边。将以上二步游走反复进行多次，就构成了item-item同构图。

在这个新构建出来的item-item同构图上，每条边连接的两个item，因为被同一个user消费过，所以是相似的，构成了训练中的正样本。

• 在训练开始前，
  • 从item-item图上的某个节点u，随机游走若干次。
  • 游走过程中遍历到的每个节点v，都被赋予一个分数L1-normalized visit count=该节点被访问到的次数 / 随机游走的总步数。
  • 这个分数，被视为节点v针对节点u的重要性，即所谓的Personal PageRank（PPR）。
• 训练过程中
  • 针对item-item同构图上的某一条边u→v，u和v就构成了一条正样本，它们的embedding应该相近
  • 在图上所有节点中随机采样一部分ne，u和每个ne就构成了一条负样本，它们的embedding应该比较远。因为是随机采样得到的，所以ne是easy negative。
  • 除此之外，还将u所有的邻居，按照它们对u的重要性（PPR）从大到小排序，筛选出排名居中（e.g.论文中是2000~5000名）的那些item。这些item与u有几分相似，但是相似性又没那么强，从中再抽样一批item，作为"u"的hard negative。

....

• 利用传统nlp思路的

在airbnb中，用户的点击序列，如果用类似word2vec+窗口的想法看成是一个“共现”问题的话，用户点击序列中的项的不像语言那样有一个很明显的长程衰减，embedding都应该是相近的。 但这样的组合太多，所以回退到窗口的方式，拿中心项和邻居项组成正样本对。但因为最后一次下单的点击有最强的业务信号，所以拿它和整个序列的每一项组成正样本对，“增加final booked listing作为global context加入每个滑窗”

解决了如何构造硬负样本的问题，那应该选择多少硬负样本呢？如果自己跑过reranker的微调就会知道，过高的硬负样本比例甚至会让模型崩掉。而更是有拿调reranker的数据集拿来调embedder的神人（没错，就是我自己），BAAI官方的脚本中，这俩也没啥区别 🤣

然而，早在N年前Facebook的文章中，就给出了他们的经验教训

1. 将比例维持在easy:hard=100:1
2. 将rerank的数据拿来训embed(在搜推场景中是拿曝光未点击数据（rerank前列但未收到信号）来当召回（embed）的负样本)是完全错误的实践，离线数据可能不错但一上线就是一坨

这是为什么呢？因为召回不同于排序，在rag层要处理的文档没有那么多可能无感知，很多rag甚至没有排序层拿召回当排序，先下结论

如果说排序是特征的艺术，那么召回就是样本的艺术，特别是负样本的艺术。样本选择错了，那么上述的模型设计、特征工程，只能是南辕北辙，做得越卖力，错得越离谱。

明白了这个数据分布的区别之后，就会对前面硬负样本和简单样本的比例在不同阶段是不同的这一个特点有更深的理解，对于召回而言

hard negative并非要替代easy negative，而是easy negative的补充。在数量上，负样本还是以easy negative为主，文章中经验是将比例维持在easy:hard=100:1。毕竟线上召回时，库里绝大多数的物料是与用户八杆子打不着的easy negative，保证easy negative的数量优势，才能hold住模型的及格线。

所以，全样本随机采样的负例才会很重要

而推荐甚至走的更远好几步，例如，随机采样不等于等概率采样，推荐系统中会出现放大的效应，即热门的样本会更容易被点击，进而各种指标特征表现更高，变得更热门，为了不然模型退化到只推荐一类样本，在实践之中会对热门正样本降采样，对热门负样本升采样

还有对硬负样本带来的左脚踩右脚

当业务逻辑没有那么明显的信号的时候，就需要依赖模型自己挖掘, 都是用上一版本的召回模型筛选出没那么相似的对，作为额外负样本，训练下一版本召回模型。怎么定义“没那么相似”？文章中是拿召回位置在101~500上的物料

Q: 这样选择出来的hard negative已经被当前模型判断为“没那么相似”了，那拿它们作为负样本训练模型，还能提供额外信息吗 A: 上一版本中，这批样本只是相似度靠后，现在直接划为负样本，能更迫使模型进行区分

而rag在玩的全链路RL优化，是推荐系统几年前玩了一波后来又扔到垃圾桶的东西 🤣性能不稳定，模拟和实测差距大，等等问题

包括现在在rag系统的reranker中还未广泛见到的刷点技巧，对不同难度级别的负例单独训小模型，然后做embedding融合

在工程性上，RAG的路也更像是把所有搜推的路再走一遍，

• 如何解决冷启动问题？搜推已经证明了LR,FM这种一二阶特征就能得到一个不错的基线，并且可以将实数特征离散化，排0存储，排0计算进行O(N^2)到O(N)再二值化化乘为加得到在线级别的性能（用户每一次交互都是一次特征计算）

• 如何解决系统效率问题？网络上参数服务器+只传递特征id，实数特征的分桶离散化，特征的Field级别合并减少NN的维度，log的一套大数据系统+redis冷热缓存+bloomfilter+......

• 如何解决模型性能问题？在召回层禁止特征交叉，在排序层卷一系列现代架构，根据短文本特点进行深度语义层的裁剪，量化和蒸馏

• 如何解决可解释性问题？用加权的ML模型做基线，bad case定位和迭代，先把神经网络丢一边......

• 意图识别？训练NER任务，对查询做成分识别，丢掉不重要的词，在少无结果的时候做多级检索，甚至能把时延卷到10ms量级。BERT结合KG做领域词级别的mask而不是字符级别的mask，来达到对整个实体级别语义的理解效果

• 多样性？召回通道的消重系统

• 商业化？精排的广告插入......

• 规模化? 一键训推平台，业务算法提交数据后集群分卡自动运行和效果验证

• 稀疏样本？酒店这种看重订单率而不是相关性的就是最好的参考实践

现在传统RAG发现一个问题就是半结构化数据很难被embedding模型处理，但如果从这个角度反向想回去的话，搜推一直就是在处理结构化数据啊，还是走同一套特征离散化的逻辑，后面做Pooling和特征融合又可以复用各种实践，

• 普通的Mean/Max Pooling，代表算法YoutubeNet，先embedding再pooling
• Neural FM中，让属于同一field的feature embedding两两交叉，完成所谓的Bi-Interaction Pooling
• 加权平均 - Attention, 阿里Deep Intereset Network (DIN)，计算candidate item和用户各历史item的attention score，再根据这个score加权历史item的embedding，表示用户的历史偏好，使得用户的向量表达随着不同的candidate变化
• 加权+时序，DIEN

所以，我们真的需要一个劣化的RAG系统吗？很多时候只是我们维护不起一套完整的搜推系统罢了，没有人力和体系力量去维护一个结构化的数据组，AB test和实时的线上反馈，又不在意系统的时延，吹嘘着LLM神话，消耗着大量的token，最后效果也就那样，还得根据线上信号进行优化，做来做去发现前人早就做过了（笑）。

但是anyway，如果你需要做点rag的话，搜推这边的方法可能需要大规模人力物力不一定能用得上，但这边踩过的坑，再踩一次就是猪头了,也算是理解了为啥网上有做搜推的转RAG讲说从LLM转过来的完全不理解上线难点在哪里，会踩很多坑，或者永远停留在离线的状态

Langchain needle in haystack 实验​

长上下文之后，越后面的部分的事实性细节越容易找，尤其是多事实的情况下

引发的一个思考是 rerank 时是否需要将最关注的块放在 prompt 的最后面，也就是倒序？

• 后补: 但其实又有attention sink相关的研究，可能还是需要具体任务具体测试分析

Maybe recency bias in LLMs：只记得最近的了

No retrieval guarantees

query analysis：将 question 联系到正确的文档​

routing (to right DB)

full doc -> summary -> embedding： doc 中噪声非常大, summary 是必要的，语义层次的保留 level 通过 prompt 保证

self-reflection 听起来很美好，但实际常常用不到，太慢了，并且搜不出来更多是前期处理没做好，再换着花样也很难搜出来

HyDE 对于高度 Domain Knowledge 和抽象性理解的任务基本没用:

一些自己的解释

1. 能否生成正确的假设文档， 难
2. 即使通过先行的小批量搜索教导 LLM 根据这些 example 生成假设文档，也很难让 LLM 从这些文档中抽取某个泛化的问题，经常会 过度 specific 而导致后续漏掉文档
3. 目前实验下来垂域脏文档类型最好的解决方案还是 reranker，embedder 如果不微调分布太接近了，例如全部的 chunk 都在 0.5~0.6 之间，意义寥寥

和数据分析的结合:

分析波动->(数据分析)找出波动的阶段-> 对每个波动的阶段做查询

GraphRag 这种 KG-based 的方法经常强调“对整个数据集信息的整合”

但这个要分领域，例如，个人知识库之中，这是好的

但垂域的知识文档常常是相似的格式，固定的路由，同时信息的整合关键不在“多实体”的关系上，而是在于“单个实体随时间的变化”上。

又或者说实体关系 $R(e_1, e_2)$ 本身应该建模成一个包含时间的 $R(e_1, e_2, t)$

如果仅仅是靠新加入的文档来动态更新 KG 的话，滞后性会很强

在这种半结构化的模板式文档中，LLM 实际上在干一个 Fuzzy DB manager, 提取信息，充当一个搜索引擎

利用 KG 进行某种意义上的多跳推理本质上也只是对文档的多次检索，推理跳数越多，关系越复杂，离线生成 KG 就越难，不是所有领域都像是法律一样有一个明确的 A 判例引用 BCD 法条的连接关系的，这样复杂的 KG 在要想随时间变化也更不可能

从某种意义上来说，KG 是在横向生成，而类似金融这种领域的 RAG 做的是纵向的 Timeline, 这部分对于关键实体是有数据的，并且可能数据都不需要自己做（例如各种行情的图），而离线准备好这些 timeline 之后，如何在 timeline 上进行一个跳跃和查询分析才是关键的。

如果从 DB 的角度上分析的话，金融领域这种关注点快速变化的 RAG 系统（with cache）也就相当于 lazy generated timeseries DB 了，例如问了一个 A 的价格变化，就像是生成了一个 time, delta_price, event(detail) 的 timeseries DB 表，把生成 reason 这样的 LLM 工作 lazy 化了而已

chunk 的前总结和后总结(离线在线)​

离线总结最大的问题在于总结哪些方面，实际上是文档预处理的一个部分

最简单的方法就是整个提示模板每个 chunk 问一次 LLM，有 langchain 的 map reduce 等稍微 high level 一点的工具可以支持这个事情

对长文档总结更有效一些的做法是利用好 embedding，先对 chunk embedding 做聚类，再每个聚类里面抽几个 chunk, 从而保证多样性和 chunk 数量的平衡

后总结，或者说 query-based 总结大体上是用 LLM 做比较多，但对于时延和开销的增加太高了，一个比较新的方法是 paragraph sentence-level mask bert（自己造的词），在段落中根据 q, d 的交叉编码得到句子级别的二进制掩码，从而删除无关部分。有一篇 ICLR2025 基于 bge 训了个，https://huggingface.co/blog/nadiinchi/provence

provence效果非常好，又快又几乎对齐例如GPT4.1这种顶级模型的效果

另一个思路就是绕过这个问题，切小块，依赖 rerank 和重新合并乃至知识图谱检索之类的策略保证相关性，也就是在查询完之后是合并还是切分的思路差距

半结构化数据​

https://docs.superlinked.com/getting-started/installation 聚焦半结构化的异构数据，例如朴素 embedding 方案对数字的理解不足，无法建模 1-99 的相似度分数与 higher/lower 这种文本的关系

https://github.com/microsoft/multifield-adaptive-retrieval 做多字段的权重学习(自适应选择查询应该着重的权重)

embedding 相关的调优​

colbert架构是一个better embedding的方向，其核心在于将文档的token level embedding保存下来，对于每一个query token，计算maxsim算子得到单token的score，再求和

对比朴素embedding方案，它在token level进行计算可以很好的带来类似关键词匹配的效果，有效避免长文档下，embedding过于平均化余弦相似太不敏感的问题

对比rerank方案，它的优点又在嵌入矩阵可以离线计算，不需要完全在线的交叉编码器

引入方案： https://python.langchain.com/docs/integrations/providers/ragatouille/

Prompt​

基本没有什么特别通用的工作，但值得一提的是将prompt作为一个优化变量，使用LLM在Trajatory上进行采样和跑各种论文的“prompt优化算法”的解耦框架dsPy https://dspy.ai/ 用户以类似类型/对象系统的简短注释提供给dspy作为“初始意图”，而后续复杂的提示由dspy生成，核心思想是让用户专注于编程

class CheckCitationFaithfulness(dspy.Signature):
    """Verify that the text is based on the provided context."""

    context: str = dspy.InputField(desc="facts here are assumed to be true")
    text: str = dspy.InputField()
    faithfulness: bool = dspy.OutputField()
    evidence: dict[str, list[str]] = dspy.OutputField(desc="Supporting evidence for claims")

context = "The 21-year-old made seven appearances for the Hammers and netted his only goal for them in a Europa League qualification round match against Andorran side FC Lustrains last season. Lee had two loan spells in League One last term, with Blackpool and then Colchester United. He scored twice for the U's but was unable to save them from relegation. The length of Lee's contract with the promoted Tykes has not been revealed. Find all the latest football transfers on our dedicated page."

text = "Lee scored 3 goals for Colchester United."

faithfulness = dspy.ChainOfThought(CheckCitationFaithfulness)
faithfulness(context=context, text=text)

DSPy 中的不同优化器将通过为每个模块合成良好的小样本示例 （如 dspy.BootstrapRS 1 ） 来调整程序的质量；为每个提示提出并智能地探索更好的自然语言指令 （如 dspy.MIPROv2 2 ） ，以及为您的模块构建数据集并使用它们来微调系统中的 LM 权重 （如 dspy.BootstrapFinetune 3 ）

LLM评估​

测试不可靠：有多少答案是被记忆出来的？

有多篇相关的paper在讨论这个问题，然后采用了一些方法来衡量这个事情，例如，在数学问题题集中，替换无关的描述、修改数字等等，看看模型性能变差多少

类似数学问题集这种在网络上数据中很难过滤干净，还需要考虑多语言影响

另一些评估指标如ARC-AGI通过抽象图像智力问题集来评估模型的推理能力，相对来说泄题风险小一些(并且有隐藏test set)

• 丢给LLM的时候不是图像，而是矩阵，用数字表示不同颜色

Chatbot Arena: 让全世界的人都来进行判断哪个模型好​

但还是有办法hack: 更fit人的倾向（粗体字、分点、emoji.....）

Elo Score 考虑除了人的直接倾向之外其他因素的影响，在BF模型计算时加上一项$\beta_0$, $\frac{1}{1 + exp(\beta_i - \beta_j + \beta_0)} = E_{ij}$, $E_{ij}$ 是模型i和j的胜率，$\beta_i$ 是模型i的真实评分，$\beta_0$ 是一个全局偏差项，表示人类评估者的偏好。通过最大化似然函数来估计参数$\beta_i$和$\beta_0$，从而得到模型的真实评分。

$\beta_0 = \gamma_1 * 长度差 + \gamma_2 * emoji个数差 + \gamma_3 * ...$

可以看到，考不考虑这个$\beta_0$，模型的排名差别很大

Goodhart's Law​

一旦一项指标被用作目标，它就不再是一个好的指标

http://becomingahacker.org/integrating-agentic-rag-with-mcp-servers-technical-implementation-guide-1aba8fd4e442

However, traditional RAG has limitations: it usually queries a single data source and only performs one retrieval pass, so if the initial results are poor or the query is phrased oddly, the answer will suffer 但是，传统的 RAG 存在局限性：它通常查询单个数据源，并且只执行一次检索传递，因此如果初始结果不佳或查询措辞奇怪，答案将受到影响

There’s no built-in mechanism for the system to reason about how to retrieve better information or to use additional tools if needed. 系统没有内置机制来推理如何检索更好的信息或在需要时使用其他工具。

关于结构化输出的另一篇特别好的文章: https://www.boundaryml.com/blog/schema-aligned-parsing

推理加速：是对的，例如huggingface-text-embedding项目，将各种转trt/onnx 可以让吞吐提升5x

H100 bge-reranker-v2-m3 1024 * 512char sentence， 13s -> 2.3s

关键词抽取​

基于主题LDA，词典等

小模型方法：先用spaCy、hanLP等得到语法树，再从语法树中拿到名词性关键词等

无监督，经典如YAKE！综合考虑词频，词位，共现等。可以考虑https://github.com/JackHCC/Chinese-Keyphrase-Extraction

一篇非常有insight的blog：上下文相关!=上下文充足，定量充足性和它的应用​

https://research.google/blog/deeper-insights-into-retrieval-augmented-generation-the-role-of-sufficient-context/

如果简单引入语义搜索，那么第一时间想到的肯定是向量搜索的方法

先不论小的优化，向量方法现在大体上就是两种架构，单塔和双塔，对应Cross-Encoder和普通的Encoder模型。

双塔模型如下，查询$q$和文档$d$分别通过两个独立的编码器，得到向量表示$q_v$和$d_v$，然后计算相似度（内积，余弦，等等）。

而单塔模型则是将查询和文档拼接在一起，输入到一个交叉编码器中，这个交叉编码器很多时候就直接输出相关性得分score了，即为我们所说的reranker

单塔虽然精度远高于双塔，但有无法离线计算的缺点

而双塔的一大精度困境在于，当编码的文档变长时，文档的大部分内容可能都和查询没什么关系，这会导致查询向量和文档向量的相似度计算不准确。实际上，在楼主之前的一些实验之中，一整个很大的文档集合内，和某个查询最无关和最相关的文档的余弦相似度相差也就0.2左右，这就是长文档带来的问题。

但客观地讲，长文档是无法避免的，如果把文档切成更细粒度的句子，在上下文补齐语义，后续合并等麻烦可能更多，并且会出现"长文档实际上是在让相似度检索考虑上下文"这样的情况，一个例子是，问题是"上海交大的用户论坛中，...."，而文档可能是"...水源社区是上海交大的用户论坛。水源社区....." 如果仅在句子等短文本上面匹配，那缺少了上下文的情况下，"水源社区"当然和"上海交大"没什么关系。

那么，如何保证精度的同时又能离线计算呢？

ColBERT的思路是，使用双塔模型来计算相似度，但在编码文档时，使用了一个更细粒度的向量表示。

ColBERT给每个token一个向量表示，而不是给每个文档一个向量表示。这样，查询和文档的相似度计算就可以在token级别进行。

如下图，ColBERT在拿到最后一层的输出之后（这一层有非常多的语义信息！），将每一个token对应的vector都存下来，这一部分是离线的。

而在计算相似度的时候，将query的tensor和文档的tensor进行一个$MaxSim$算子

$MaxSim$是一个最大池化操作，取出每个token的向量中与查询向量最相似的那个向量，然后计算相似度。

ColBERT的性能是逼近reranker的，这个也很好理解，毕竟交叉编码器的优势就是可以考虑$q,d$之间的交互，而ColBERT除了保留语义嵌入之外，比起更暴力的加大embedding维度，更重要的是它保存了上下文次序的信息

而ColBERT的最后一层MaxSim，而没有采用神经网络的方案，让他带来了良好的可解释性

那看了上面立刻就会想到，这每一个token保存一个768/1024/...维的向量，存储开销不会很大吗？

ColBERT也考虑到了这个问题，因此在ColBERTv2中，采用了这样质心编码的方法来降低存储开销，能降低8倍

1. 对每个token的向量进行聚类，得到$k$个质心（k是一个预定义的数字）

2. 对每个token的向量，找到距离最近的质心，并将其索引存储下来，也就是从 $(v_d, ) ->(1,)$

3. 将质心向量库构建ANN索引，例如FAISS, ScaNN

4. 在计算相似度时，查询向量也进行同样的处理，找到距离查询最近的质心索引，然后从质心向量库中取出对应的质心向量进行相似度计算

在实际使用的时候，商业rag公司甚至对大规模检索做更狠的二值化向量压缩（说实话这也能检索出来真的有点现代模型神力了），让ColBERT的开销可以和单独的embedding媲美

二值化的说法是这样的:

压缩方法通过将正维度表示为 1、负维度表示为 0 来简化文档标记向量。这种二进制表示有效地指示了文档标记向量中重要语义特征的存在与否。 正维度有助于增加点积，表明相关的语义相似性，而负维度则被忽略。

ColBERT的使用上，很多公司都有了支持，例如vespa, jina等等，开源方案则有早期的ragatouile和后来的上下游如milvus，llamaindex的支持

但是，文档ColBERT还不是它发挥全部潜能的时候，据说SPLADE算法就比他效果好不少（这个我没有实测过），它在图像又活出了第二世，即所谓的ColPali架构

ColPali是MRAG、MLLM那边的新论文和解决方案，几个月的时间砍了1.9k star，ColPali的想法是这样的

• OCR的多个组件和分块带来误差传播，且预处理流程耗时也长，能不能直接端到端一次使用文档截图解决
• 但是如果将整页的文档编码成一个向量，肯定精度不够
• 我的ViT等视觉编码器会将整页文档变成一系列的patch（可以理解为子图），进而变成一系列视觉token，那我重用ColBERT，不就又有了多向量吗？并且这个存储和交互上比每个token存一个向量更合理! 子图本身就有很多的空间位置信息

并且，你会发现ColBERT的强可解释性在图像上有更关键的作用！模型在文本中关注了什么可能是某个词，还需要人进行一点逻辑推理来判断关系是否合理，而图像中关注了什么，直接看图就知道了！

作为一种新的RAG范式，ColPali从源头上解决了复杂的OCR和切块的问题

虽然其在重文字领域上的泛化性还留待验证，精度的提升也依赖于未来VLM的发展，但无疑社区已经认同了这个想法的价值

基于 OCR 的文本提取，以及随后的布局和边界框分析，仍然是重要文档 AI 模型（例如 LayoutLM）的核心。例如， LayoutLMv3 对文档文本进行编码，包括文本标记序列的顺序、标记或线段的 OCR 边界框坐标以及文档本身。这在关键的文档 AI 任务中取得了最佳成果，但前提是第一步——OCR 文本提取——能够顺利完成。

但通常情况并非如此。

根据我最近的经验，OCR 瓶颈导致现实世界生产文档档案中的命名实体识别 (NER) 任务的性能下降近 50%。

目前例如ColQwen2这种ColBERT + Qwen2.5-VL-3B-Instruct的方案也很火，很多榜上都刷到了SOTA，感兴趣的同学也可以自己试试