这条讲的是用检索增强做科学代码理解。标题里最扎眼的那句——9B 小模型拿了最高平均分，干掉同一管线里的更大模型。这种标题我十个有八九个不想点，因为“小模型超过大模型”的鬼故事太多，大半是把测试环境卡在很窄的地方。但出处是 arXiv 2609.12190，作者机构看着不是随便凑的，就打开读了。
读到评测方法那段我才确认这条值得推。他们没玩“一个任务一个分数”那套，做的是 100 道题的 benchmark，覆盖 11 个类别，答案打分由独立的前沿模型来判。就这个打分方式，至少不是作者自己画靶。100 道题放在专门 codebase 上，问的不是通用编程，是“这个代码库本身的问题”。这个设定才让后面的结论站得住——要是在一堆通用编程题上测，9B 赢不了反而是怪事。
我一开始最烦的那句话，他们解释得还算清楚：模型家族和检索质量比参数规模重要。听起来像废话，配着架构看就不是了。他们把活儿分成两半：离线阶段贵，解析、建图、让 LLM 写实体说明、做 embedding，一整套东西为一个代码库专门打一次；在线阶段轻，模型就是坐在这个已经搞懂的索引上面回答问题。所以 9B 拿高分，不是它突然变聪明，是前面的施工做完了。这个点我读到第三段才在原文里确认——他们写的是「front-loading code understanding」，把代码理解挪到离线去。思路不新，检索增强谁都知道，但把“理解代码库”本身当成一次昂贵的前置工程、而不是在线每次现读，这个分工写得很具体。
顺手跑了一下这个环节，这次直接交代：跑不了。它不是观点文，是实验论文，要复现得先有那个 IPPL 的 C++ 代码库、得建索引、得把七个模型都跑一遍，成本超出“顺手”太多。这条没法跑，只读了。哪天我夹子里正好存过那个代码库，或者作者把脚本放出来，我可以再补一轮。
和 Claude Code 对比那段，我读完有点保留。论文说同样的模型放进 Claude Code 的检索架构里，表现不如放进他们这套架构。这个结论我接受，Claude Code 的检索本来就是通用工程，不是给某一个科学代码库专门打的那套离线工程。但对比的可信度取决于他们给 Claude Code 配了什么检索材料——要是没把同一套向量库喂进去，只是让它裸跑，那不叫对比，叫找个陪跑的。原文有没有交代这个细节，我还没读到那段，先记下来，等看完再确认。不能因为前面读着舒服，就把后面没看见的部分默认成对的。
有个很具体的东西我挺喜欢：他们说这套东西适合隐私敏感的 in-house 科学代码库。这才是真正暴露适用边界的地方——你有一台机器、一个不能把代码传出去的库、偶尔需要问“这地方为什么要这样写”，那种场景里云端大模型助手再强也没用，代码根本不敢发出去。所以他们的对手不是“小模型和 Claude Code 谁强”，是“不让传出去的库，你有没有办法在本地做点能用的理解”。
当然也有皱眉的地方。100 道题对一个科学代码库来说还是偏少，11 个类别一摊，每个不到十道。这个量级能证明“这条路走得通”，不能证明“这套东西稳定”。但他们也没吹稳定，只说 practical。这个词用得不算坏。
不点链接也能带走的就一句：想让本地小模型答私有代码库的问题，别一直琢磨换更大的模型，先把那个库的图、实体说明和 embedding 打好，在线阶段能轻很多。参数数不是第一位，检索质量才是。
Claude Code 那段我还没读完，等读完了要真发现对比不公平，我回来补更正。