百万token上下文的大模型，依然找不到代码文件的关联关系

1百万token上下文依然找不到文件关联，测试对象为Kimi k3，测试场景是完整的单代码仓库。

一次请求就用满了1百万token上下文，总参数2.8万亿的月之暗面模型，依然无法说出哪两个文件存在关联。

多数开发者直接把代码全扔给Kimi，只希望注意力机制能发挥作用。

检索增强生成（RAG）不是知识图谱，更大的上下文窗口也不能替代实体关联。

大型语言模型的扁平上下文窗口会把所有内容平铺处理，Kimi k3每次API调用都要重新推导所有关系，不断消耗token。

导入关系图、调用图、类型图、模式、工单、拉取请求、配置关联这些信息，都无法以结构化形式保留。

当关联跳转步数超过一步时，Claude、Cursor和Kimi都会遇到同样的问题。

知识图谱只需做一次实体抽取，就能免费遍历多步关联，存储成本逻辑和上下文窗口完全不同。

100个实体有4950种可能的配对，1000个实体就有49.95万种候选配对，1万个实体的配对检查就接近5000万次。

没有任何上下文窗口能装下完整的关系图，它只能存储整个代码仓库的平铺文本，寄希望于模型自己找出实体关联。

实体消歧才是核心难点，朴素字符串匹配在真实语料和生产代码仓库中的准确率约为70%。

经过两步关联后准确率降到49%，三步后就只剩34%。

你的检索增强生成结果看起来没问题，但答案其实在数据输入阶段就错了，不是查询阶段出问题。

指代重叠、别名、重命名变更这些问题都可能打乱路径，比如同一个服务对应三个不同字符串标签，一次错误合并就会出错。

这套成本结构的核心思路是，先做低成本分组关键词，再通过嵌入和向量搜索缩小范围，只对候选短列表做近似最近邻搜索和余弦计算。

Kimi k3只处理占比不到5%的模糊配对，不需要对仓库里每一组配对都消耗token。

多数人现在还是会把整棵代码树粘贴到百万token的提示词里，寄希望于模型一次提取出正确结果。

正确的路径是先识别实体，解决难点问题，再像遍历基础设施一样遍历关系图。

数一数你的知识图谱里有多少实体，再数一数你真正需要的实体数量，两者的差距才是真实准确率，和Kimi k3的上下文窗口大小无关。

下次再推出百万token窗口产品前，可以记住这个结论：模型的优势不是更多token，而是已经梳理好的实体关联本身。