小上下文窗口 + 知识图谱：仅序列化格式就将我的多跳准确率翻倍（对10种格式进行了基准测试）

Reddit r/LocalLLaMA 工具
small-context-windows knowledge-graphs serialization-format multi-hop-accuracy local-models isongraph rag

摘要

对10种图序列化格式的基准测试表明，冗长格式会浪费令牌，而表格布局能提高准确率；作者构建了ISONGraph，这是一种专为LLM理解优化的属性图格式，令牌减少70%，采用MIT许可。

运行本地模型意味着每个令牌都很重要——当您将图上下文塞入RAG提示时，8K或16K的窗口很快就会填满。我对10种图序列化格式（JSON、GraphML、RDF变体、边列表等）在令牌计数和推理准确性上进行了基准测试，结果令我惊讶： - 冗长格式大约浪费70%的令牌在纯语法上——花括号、引号、重复的键。在8K本地模型上，这意味着您的图预算比需要的要小约3倍 - 仅凭格式变化，多跳准确率就从约40%跃升至约80%——相同的图、相同的模型、相同的问题 - 表格/关系型布局（模型在训练中经常看到的模式）始终优于嵌套标记 基于这些发现构建了ISONGraph——一种专为LLM理解优化的属性图格式：令牌减少约70%，遍历准确率92%，可完全离线运行于本地模型。采用MIT许可，提供Python、JS/TS、Rust、Go、C++、C#实现。包含基准测试方法的仓库：github.com/isongraph/isongraph 好奇这里的人们在本地模型中使用什么格式处理图上下文——如果有人拥有某种不同格式胜出的问题集，我愿意用它来测试。
查看原文

相似文章

我们尝试了向量、抽象语法树（AST）以及粗暴地堆砌上下文以进行代码检索。带有大语言模型（LLM）生成语义的图结构效果最佳。以下是我们的经验总结。

Reddit r/LocalLLaMA

作者们详细描述了他们在构建代码索引系统的经验，最终得出结论：使用大语言模型（LLM）生成语义的图检索方式在性能上优于向量嵌入和纯抽象语法树（AST）解析。他们将该系统开源，命名为 Bytebell，它利用 Neo4j 存储语义上下文，以实现高效且精确的代码检索。