最新

嘿，HN！我和大学朋友正在开发HelixDB——一个原生支持图形和向量类型的数据库。 它专为AI驱动的应用而设计，如RAG、向量搜索、代码索引和代理框架，这些应用需要明确的关系和相似性。 在过去的一周里，我们扩展了查询语言，发布了向量类型以及两个SDK（Python和TypeScript），使得插入和查询数据变得简单。HelixDB是开源的，超级容易自托管，我们还提供托管服务。 如果你正在构建任何涉及检索的项目，我们非常希望听到你的反馈！ 我们是如何构建HelixDB的： 在用Rust构建图数据库的一个副项目时，我们想出了Helix的构思。在阅读一些关于RAG设置的研究论文时，我意识到要开始需要很多基础设施的搭建。你需要自己的服务器、一个图数据库、一个向量数据库，以及一些定制的中间软件来将它们连接起来。 在研究向量如何工作后，我发现可以（某种程度上）将其抽象为图。向量实际上就是带有坐标的节点！边则表示邻接关系。我意识到可以将其与当前的图基础设施连接起来，从而实现遍历与相似性搜索的结合。 Helix的底层工作原理是，你有四种主要类型，分别存放在各自的表中。你有图节点、图边、向量节点和向量边。向量边对开发者来说是无关紧要的（它们只是存储相似性算法的邻接链接）。向量节点的工作方式与在Pinecone或Qdrant中使用向量的方式相同，利用HNSW。同样，图节点的工作方式与在Neo4J或Neptune中的方式相同。然而，图边的地方就有趣了；你可以定义图节点之间的关系，也可以定义向量之间的关系，这意味着你可以在向量和节点之间建立明确的依赖关系，反之亦然。 因此，你可以运行相似性搜索，然后遍历图以获取更结构化的上下文。或者反过来。 Helix的工作原理： 当你运行Helix时，它会作为自己的服务器启动（就像一个Docker容器）。要查询它，你只需访问一个自动生成的API端点。 出于无知，我曾经认为数据库会编译它们的查询并像函数一样运行——就像在普通编程中一样。结果发现并不是这样，我从未理解为什么这不是常态。因此，像SpaceTimeDB所做的那样，我们使Helix查询可部署。你写一个查询，它会直接构建到数据库中，作为自己的端点。这避免了通过网络发送整个查询字符串的开销，并大大减少了延迟（同时也防止了注入攻击）。 我在这个项目上投入了大量的工作，所以如果你能给我的Github点个星并分享一下，我将非常感激。