JetBrains构建Air Context：语义代码搜索实战
Building a RAG Pipeline for Semantic Code Search
我们曾致力于构建最佳的语义代码搜索平台，最终推出了Air Context。在将原型转化为生产级系统的过程中，我们发现传统的grep和关键词搜索无法满足Coding agents的需求，因为它们无法理解代码的深层含义。本文记录了我们在解析、分块和向量化阶段的实战经验：如何利用JetBrains Code Engine进行结构感知的分块，避免固定行数切割带来的语义割裂；如何在存储成本与搜索质量之间寻找平衡，通过优化向量维度来应对海量代码库的挑战。这是一份关于如何让LLM agents精准定位代码片段的开发者日记。
问题不在于Agent能否完成任务，只要给予足够的时间和Token资源它终将完成，而在于生成生产级结果需要多少时间、努力和引导。
- keeda
我觉得类似这样的东西将是提升代码代理（coding agents）质量的关键。许多人观察到的一个非常普遍的问题（也许是最主要的问题）是：代理经常生成大量重复和冗余的代码；多种抽象、方法、类、数据结构等，服务于同一目的的不同微小变体……有时甚至出现在同一个文件中！
我的理论是，这是因为这些模型在执行特定任务时存在某种“隧道视野”，就像刚加入公司的工程师一样，他们会重复同样的事情，直到他们摸清了“地形”，发现类似的问题在其他地方已经解决过了。
在上一份工作中，我的团队负责内部的多仓库代码搜索工具，它是我们内部最受欢迎的工具。后来另一个团队添加了一个类似的语义搜索功能。这非常令人兴奋，但我离开时还没能看到它在实际生活中效果如何。
比如，你会进行关键词搜索，探索是否需要某个需要大量工作的核心功能模块，或者当你遇到一个仓库中不存在的抽象代码并想深入了解时。但当你处于心流状态，正在发明较小的抽象（比如一个类或工具方法）时，你未必会想到去搜索它。更糟糕的是，即使你搜索了，也无法有效找到，因为可能存在一个名称、术语略有不同，或者包含拼写错误的类似内容，而关键词搜索会漏掉这些。不出所料，在规模扩大时……
- duhhhhh1212
https://www.pangram.com/history/c901e80e-9cb7-46e4-bf10-7348...
我不想说“别浪费时间了”，毕竟前半部分是人工写的。想问问作者：你们是不是只是写累了，心想“去他的，让 LLM 把剩下的写完吧”？还是说其中一人用 LLM 写了后半部分，而另一人用自己的话写的？
- simianwords
又来了，业界基本上已经放弃 RAG 了。事实上，我几乎没见过 grep 的效果不如 RAG 的情况。