Chonks：跨语言代码库的无LLM检索工具
Chonks: code RAG for codebases that span several languages, no LLM in the pipeline
提供了一套完整的跨语言代码RAG工程方案，特别是无LLM介入的架构设计与图扩展策略，对做Agent开发的同学极具参考价值。
What I did
我所做的
Chonks indexes a large codebase into one local SQLite file and serves it to Claude Code, or any MCP harness, as retrieval tools.
Chonks 将大型代码库索引为一个本地 SQLite 文件，并将其作为检索工具提供给 Claude Code 或任何 MCP 框架。
I built it for codebases that are cross-language by nature. A game engine is C++, with C# tooling on top, HLSL shaders, and Python in the build. A call path runs through all four.
我为天生跨语言的代码库构建了它。一个游戏引擎由 C++ 构成，上层有 C# 工具链、HLSL 着色器以及构建过程中的 Python。一条调用路径会贯穿这四种语言。
10 languages get full AST parsing, symbols and graph edges. C, C#, C++, GDScript, HLSL, JavaScript, Lua, Python, TSX, TypeScript.
10 种语言获得完整的 AST 解析、符号和图边。包括 C、C#、C++、GDScript、HLSL、JavaScript、Lua、Python、TSX 和 TypeScript。
That is the gap I kept hitting. Almost every benchmark in this space is single-language, mostly Python, so nothing measures retrieval across boundaries.
这就是我反复遇到的差距。该领域几乎所有的基准测试都是单语言的，主要是 Python，因此没有任何东西能衡量跨边界检索的效果。
One constraint: no LLM anywhere in the pipeline. Not at index time, not at query time. No summaries, no query expansion, no reranking. The agent does the thinking.
一个约束条件：整个流程中不使用任何 LLM。无论是在索引阶段还是查询阶段都不使用。没有摘要、没有查询扩展、也没有重排序。由智能体负责思考。
Chunks are tree-sitter AST nodes. Functions, classes, shader blocks. Search is hybrid semantic plus BM25. On top sits a typed cross-reference graph, so a hit expands along real symbol edges instead of text similarity.
块（Chunks）是 tree-sitter AST 节点。包括函数、类、着色器块。搜索采用混合语义加 BM25。在其之上是一个类型化的交叉引用图，因此命中结果会沿着真实的符号边进行扩展，而不是基于文本相似度。
How I measured
我的测量方法
Loc-Bench, 100 instances. Acc@5 64, Acc@10 73. The ids were chosen before any tuning and never used for it. They're published in the repo.
Loc-Bench，100 个实例。Acc@5 为 64，Acc@10 为 73。这些 ID 是在任何调优之前选定的，且从未用于调优。它们已发布在仓库中。
Godot, 20 questions, 50-chunk budget. Flat hybrid search gets 0.678 feature-set coverage; adding graph expansion gets 0.843. Head to head that's 12 wins, 8 ties, 0 losses for expansion.
Godot，20 个问题，50 个块预算。扁平混合搜索获得 0.678 的特征集覆盖率；加入图扩展后达到 0.843。直接对比显示，扩展方案取得了 12 胜、8 平、0 负的成绩。
Open Questions
待解决的问题
The graph is expensive. On Godot it costs about 458 MB of a 785 MB index. The embeddings cost 49 MB. So I tested without it.
图的成本很高。在 Godot 上，它占用了 785 MB 索引中的约 458 MB。嵌入向量占用了 49 MB。因此我测试了不使用图的情况。
Loc-Bench did not move. 64/100 either way. Those repos are all Python.
Loc-Bench 的结果没有变化。无论是否使用图，结果都是 64/100。这些仓库全部是 Python。
Godot lost a quarter of its recovered neighbourhood. R@50 (Recall) fell from 0.39 to 0.29. Godot is C++. The two runs use different metrics, so I cannot pin this on the language yet.
Godot 恢复的邻域范围减少了四分之一。R@50（召回率）从 0.39 下降到 0.29。Godot 是 C++。这两次运行使用了不同的指标，因此我还不能将此归因于语言差异。
My guess: Python call edges resolve, so the inferred layer is redundant. C++ templates and member calls resolve to nothing, so the graph actually finds them.
我的猜测：Python 的调用边能够解析，因此推断出的层是多余的。C++ 模板和成员调用无法解析，因此图实际上找到了它们。
I have been improving retrieval by adding structure. I am running out of ideas in that direction. How do you handle embedding and retrieval in such large codebases?
我一直通过添加结构来改进检索效果。在这个方向上我已黔驴技穷。你们是如何处理如此大型代码库中的嵌入和检索问题的？
Link to my project
项目链接
github.com/mgonzalez01/Chonks
github.com/mgonzalez01/Chonks
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力