Infino AI：一份Parquet搞定向量与SQL检索

AI Agent 的检索需求正在变得复杂：既要做关键词匹配，又要做语义向量搜索，还要能跑 SQL 做聚合分析。传统做法是分别部署 Elasticsearch、向量数据库和 OLAP 引擎，数据被复制多份，同步延迟和运维成本随之上升。Product Hunt 上排名第 15 的 Infino AI 提出了一条不同的路径——只保留一份 Parquet 数据副本，把 BM25 和向量索引直接写进文件里。

一份数据，三种检索

Infino 的定位是面向 AI Agent 的开源检索引擎。它的核心设计决策是：数据以 Parquet 格式存放在 S3 或本地磁盘上，索引不再独立于数据之外，而是内嵌在 Parquet 文件之中。Agent 可以针对同一份数据发起关键词搜索（BM25）、向量搜索、混合搜索以及 SQL 查询。

这意味着不再需要把数据从湖仓复制到搜索引擎、再复制到向量库。对于需要频繁调用检索能力的 Agent 应用来说，数据路径缩短，一致性维护的复杂度也随之下降。项目采用 Apache-2.0 协议开源，同时提供 Infino Cloud 的正式版本，并设有免费额度。

Parquet 是一种列式存储格式，最初由 Twitter 和 Cloudera 合作开发，现为 Apache 顶级项目。它采用列式压缩，支持嵌套数据结构，并内嵌丰富的元数据（如 schema、统计信息），非常适合大数据分析场景。Parquet 文件通常存放在 HDFS、S3 等分布式存储上，被 Spark、Presto、Hive 等查询引擎广泛支持。由于列式存储天然具备高压缩比和按列读取的特性，它在 OLAP 场景中性能优异。Infino 选择 Parquet 作为数据底座，意味着可以直接复用现有的数据湖生态，避免数据迁移。

BM25 是一种经典的稀疏检索算法，基于词频（TF）和逆文档频率（IDF）计算查询与文档的相关性，并引入文档长度归一化。它是 Elasticsearch 和 Lucene 的默认评分算法，在关键词匹配场景中表现稳定。BM25 与向量检索互补：前者擅长精确匹配和术语查询，后者擅长语义相似度。Infino 将 BM25 索引嵌入 Parquet，使得关键词检索可以直接在文件层面执行，而无需借助外部搜索引擎。

向量索引（如 HNSW、IVF）用于加速高维向量的近似最近邻搜索。传统向量数据库需要独立存储原始向量和索引结构，而 Infino 将向量索引也内嵌至 Parquet 文件，实现了索引与数据的物理统一。这减少了一次数据复制，但同时也对索引的更新和查询性能提出了新的工程挑战。

为什么"索引进文件"值得关注

把 BM25 和向量索引放进 Parquet 文件内部，实际是在挑战一个长期存在的架构惯例：索引与存储分离。分离架构的好处是各自独立扩展，代价是数据搬运和双写一致性。

Infino 的选择更适合"数据已经在对象存储上、检索作为下游消费"的场景。Agent 的工作负载往往具有突发性和多样性——同一个 Agent 可能先做关键词过滤，再对候选集做向量重排，最后用 SQL 统计分布。如果每类查询都要访问不同的系统，编排逻辑会迅速膨胀。单一 Parquet 副本加上多模态索引，让这类组合查询可以在一个引擎内完成。

当然，这种架构也有其边界。对象存储的延迟特性、索引更新的粒度、以及高并发下的缓存策略，都是需要在实际负载中验证的工程问题。素材中没有披露具体的性能指标，社区的真实反馈还需要时间积累。

开源 + 云服务的双轨策略

Infino 采取 Apache-2.0 开源加托管云服务的模式。对开发者而言，可以本地或自有 S3 上跑完整功能；对希望减少运维投入的团队，Infino Cloud 提供开箱即用的选项，并有免费层可以试用。

这种双轨策略在数据库和检索领域已经相当常见，关键在于开源版本是否保留足够的核心能力。从项目描述看，关键词、向量、混合、SQL 四类检索都在开源范围内，云服务更多是托管便利性的差异，而非功能阉割。

适合谁，不适合谁

Infino 的目标用户是构建 Agent 应用的开发者，尤其是那些数据已经沉淀在 Parquet/对象存储上、不想再维护多套检索系统的团队。对于查询模式以单一向量检索为主、数据量不大的场景，引入新引擎的收益可能有限；而对于需要跨模态组合查询、且对数据副本数量敏感的中大型 Agent 项目，这个思路值得评估。

项目在 Product Hunt 获得 89 票、9 条评论，处于早期曝光阶段。作为开发者工具，它的实际价值最终取决于查询延迟、索引构建效率和生态集成度，这些都需要在真实项目中检验。

常见问题

Infino 支持哪些查询类型？ 关键词（BM25）、向量、混合以及 SQL 查询，均针对同一份 Parquet 数据。

数据可以存在哪里？ 支持 S3 或本地磁盘，索引内嵌在 Parquet 文件中。

是否开源？ 是，采用 Apache-2.0 协议。同时提供 Infino Cloud 托管服务，含免费额度。

和现有向量数据库的区别是什么？ 主要差异在于不复制数据、索引与数据同文件，减少多系统间的数据同步。

背景补充

在传统架构中，索引与存储分离意味着原始数据存放在数据湖（如 S3），而索引（如倒排索引、向量索引）存放在专门的搜索引擎或向量数据库中。这种分离带来了水平扩展的灵活性，但也引入了数据同步的复杂性：当原始数据更新时，索引需要异步重建，可能导致短暂的不一致，且双写逻辑增加了应用层的负担。此外，多份数据副本也推高了存储成本和运维开销。

对象存储（如 Amazon S3）具有高持久性、低成本和高扩展性，但延迟通常高于本地磁盘，且对频繁的小文件读写不友好。将索引内嵌到 Parquet 文件后，查询时可能需要从对象存储拉取整个文件或部分列，这对索引的局部性提出了更高要求。常见的优化手段包括：利用 Parquet 的列裁剪和谓词下推减少读取量，以及在计算节点部署缓存层来降低延迟。这些工程细节直接影响“索引进文件”架构的实际可行性。