@MaximeRivest: 当前的LLM架构很蠢（如果不算蠢，至少也是浪费）。以下三个包含4个上下文块的提示词：…

X AI KOLs Following 新闻
llm-architecture inference-efficiency context-caching order-invariance context-encoding

摘要

一条推文批评了当前LLM架构因依赖顺序的上下文而导致浪费的重计算，并提出将上下文单元分开编码，以实现与顺序无关的高效缓存和生成。

当前的LLM架构很蠢（如果不算蠢，至少也是浪费）。 以下三个包含4个上下文块的提示词： [file A][file B][task][tool specs] [tool specs][file B][file A][task] [task][file B][file A][tool specs] 它们的顺序应该是无关的，在这些上下文字段内部，顺序很重要，但在外部则不然。 这破坏了缓存，导致当代码库中单个文件发生变化时，或者只有生成任务发生变化（文件和工具不变）时，需要重新计算很多东西。 而且，很难廉价地将上下文修剪到必要内容。更难检索上下文块并以节省计算的方式仅显示相关的块。 应该可以对这些上下文块进行编码，以便实现以下功能： u1=encode(Unit(name="file_a.py", content=...)) u2=encode(Unit(name="file_b.py", content=...)) u3=encode(Unit(name="tool_specs.yaml", content=...)) model.generate( task="provide diff for fixing file_a.py file_b.py is irrelevant", ctx_units=[u1, u2, u3] ) 在这种情况下，u2（file_b）之前已经被编码，它对任务FLOPs的影响应该会很快消失，因为神经网络的前几层会判断出它与任务无关。 而且，u1和u3都与任务相关，但它们的顺序并不重要。 有没有人训练过类似的东西？ 感觉就像是用于生成的丰富晚期交互。
查看原文
查看缓存全文

缓存时间: 2026/06/10 15:53

当前的LLM架构很糟糕（如果不算愚蠢，至少也是浪费的）。

举个例子，考虑以下3个包含4个上下文块的提示：

[file A][file B][task][tool specs] [tool specs][file B][file A][task] [task][file B][file A][tool specs]

这些块之间的顺序本应无关紧要——在上下文块内部，顺序至关重要，但块与块之间的顺序却应该无关紧要。

然而，当前架构破坏了缓存，当我们更改代码库中某个文件时，或者仅仅是生成任务改变了（而文件和工具未变）时，就得重新计算大量内容。

此外，这种方式难以低成本地精简上下文至核心内容，也难以检索上下文块并以节省计算的方式仅展示相关部分。

理想情况下，应该能够对这些上下文块进行编码，使得以下操作可行：

u1=encode(Unit(name=“file_a.py”, content=…)) u2=encode(Unit(name=“file_b.py”, content=…)) u3=encode(Unit(name=“tool_specs.yaml”, content=…))

model.generate( task=“提供修复 file_a.py 的差异，file_b.py 无关”, ctx_units=[u1, u2, u3] )

在这种情况下，u2（file_b）会被预先编码，它对该任务算力的影响应该会随着神经网络早期层识别出它与任务无关而迅速衰减。

同时，u1和u3虽然都相关，但它们的顺序也不重要。

有人训练过类似的东西吗？

感觉就像是针对生成任务的丰富后交互（rich late interaction）。

相似文章

引用布莱恩·坎特里尔

Simon Willison's Blog

布莱恩·坎特里尔批评LLM缺乏人类懒惰带来的优化约束，认为LLM会不必要地使系统复杂化而非改进，并强调人类时间限制推动了高效抽象的发展。

@oneill_c: https://x.com/oneill_c/status/2077453217609453784

X AI KOLs Timeline

一位研究人员讨论了LLMs中的持续学习挑战，将其比作健忘的实习生，并探索了扩展上下文窗口、构建有状态记忆以及将上下文压缩为潜在表示等方法，引用了他们在Still上的工作。