为什么向量RAG在大规模AI编程代理中失败（以及我如何使用Neo4j图来解决它）

Reddit r/ArtificialInteligence 工具
ai-coding retrieval-augmented-generation neo4j graph-database vector-search open-source local-first

摘要

一款名为Writ的新开源工具采用混合检索流程，结合BM25、本地ONNX向量和Neo4j图遍历，为AI编程代理提供上下文规则，将令牌膨胀减少726倍，并通过bash钩子强制计划审批。

每个人都把AI编码记忆当作“第一周”问题，只需将[`CLAUDE.md`](http://CLAUDE.md)文件转储到上下文中。一旦遇到数千条冲突的企业规则，这种方法就会崩溃。渐进式披露仍然会消耗数千个令牌。我想将匹配决策完全移出代理。我强迫一个LLM帮助我构建一个名为Writ的工具。它位于Claude Code之上，使用5阶段混合检索流程（BM25 + 本地ONNX向量 + Neo4j图遍历），在0.55毫秒内返回上下文规则，同时将令牌膨胀减少726倍。最棒的部分？它使用实际的本地bash终端钩子，在有效的计划和测试骨架获得批准之前，剥夺AI的写入权限。不再有AI代理撒谎或幻觉依赖。它完全开源且本地优先。查看架构，并告诉我图遍历逻辑是否有意义：[https://github.com/infinri/Writ](https://github.com/infinri/Writ)
查看原文

相似文章

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

Reddit r/LocalLLaMA

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

我们构建并开源了 Caliby：一款面向 AI Agent 的嵌入式高性能向量数据库（性能是 pgvector 的 4 倍，磁盘性能超越 FAISS） --- ## 背景 我们在构建 AI Agent 时，一直在为向量存储苦苦寻觅合适的方案。 - **pgvector** 性能太慢，且需要运行一个完整的 PostgreSQL 实例 - **FAISS** 速度很快，但完全基于内存，无法持久化，而且 API 非常底层，难以使用 - **Chroma / Qdrant / Weaviate** 功能强大，但都是独立的服务，对于嵌入式使用场景来说过于重量级 我们真正需要的是类似 **SQLite** 的东西——一个无需独立服务、直接嵌入应用程序的向量数据库，同时兼顾速度与易用性。 于是，我们动手构建了它。 --- ## Caliby 是什么？ **Caliby** 是一款嵌入式向量数据库，专为 AI Agent 和本地 AI 应用设计。 **核心特性：** - 🚀 **高性能** — 查询速度是 pgvector 的 4 倍，磁盘模式下超越 FAISS - 💾 **嵌入式** — 无需独立服务，像使用 SQLite 一样简单 - 🔍 **混合搜索** — 同时支持向量搜索与元数据过滤 - 📦 **持久化存储** — 数据落盘，重启后不丢失 - 🔧 **简洁 API** — 专为开发者体验而设计 --- ## 快速上手 ```python from caliby import VectorDB # 初始化数据库（本地文件存储） db = VectorDB("my_agents_memory.db") # 插入向量 db.insert( id="doc_1", vector=[0.1, 0.2, 0.3, ...], metadata={"source": "arxiv", "topic": "AI"} ) # 语义搜索 results = db.search( query_vector=[0.1, 0.2, 0.3, ...], top_k=5, filter={"topic": "AI"} ) ``` --- ## 性能基准测试 我们在 100 万条向量、维度为 1536（OpenAI embedding 维度）的数据集上进行了测试： | 数据库 | 查询延迟（P50） | 查询延迟（P99） | 内存占用 | |--------|----------------|----------------|----------| | **Caliby** | **2.1ms** | **4.8ms** | **低** | | pgvector | 8.7ms | 21.3ms | 高 | | FAISS（内存模式） | 1.9ms | 3.2ms | 非常高 | | FAISS（磁盘模式） | 6.4ms | 15.7ms | 低 | > FAISS 内存模式确实更快，但需要将全部数据加载到 RAM 中。Caliby 在磁盘模式下实现了接近内存的速度。 --- ## 技术实现 Caliby 的底层采用以下技术： - **HNSW 索引**（Hierarchical Navigable Small World）用于近似最近邻搜索 - **内存映射文件**（mmap）实现高效磁盘访问 - **Rust 核心引擎**，通过 Python 绑定暴露接口 - **WAL（预写日志）** 保障数据持久化与崩溃恢复 --- ## 适用场景 - 🤖 **AI Agent 记忆系统** — 让 Agent 记住过去的对话与经验 - 📚 **RAG 应用** — 检索增强生成的本地知识库 - 🔍 **语义搜索** — 为应用添加语义检索能力 - 🧪 **原型开发** — 无需部署复杂基础设施，快速验证想法 --- ## 开源地址 项目已在 GitHub 开源，欢迎 Star、提 Issue 或参与贡献： 👉 **[github.com/caliby-db/caliby](https://github.com/caliby-db/caliby)** --- 我们很想听听大家的想法： - 你们目前在 AI 项目中使用什么向量数据库？ - 有哪些功能是你们最迫切需要的？ 欢迎在评论区留言交流！🙌

Reddit r/LocalLLaMA

Caliby 是由 Sea-Land AI 与麻省理工学院 Michael Stonebraker 团队联合开发的开源嵌入式向量数据库，提供高性能向量检索能力（速度比 pgvector 快 4 倍），支持 HNSW、DiskANN 和 IVF+PQ 索引，专为 AI Agent 和 RAG 场景设计，只需通过 pip install 即可快速安装使用。