在大语言模型应用场景中，检索增强生成（RAG）早已成为标准范式。然而，传统的向量检索面临一个根本性局限：它只能回答「相似度」问题，无法表达实体之间的关联关系。当业务场景需要追问「这家公司的上游供应商有哪些」「某篇论文引用了哪些先行工作」时，纯向量检索往往力不从心。Antfly 试图解决这个问题的思路值得深入探讨 —— 它将全文检索、向量检索和图遍历三种能力融为一体，并在写入数据时自动完成关系抽取，让图索引不再是事后手动构建的负担。
架构根基：基于 etcd Raft 的分布式多 Raft 设计
Antfly 的定位是一个分布式搜索引擎，底层依赖 etcd 的 Raft 库实现共识协议。与常见的单 Leader 架构不同，它采用了多 Raft 组的策略：集群中存在一个元数据 Raft 组负责表结构、分片分配和集群拓扑的管理，同时每个数据分片对应一个独立的存储 Raft 组，各自处理该分片内的数据写入、索引构建和查询请求。这种设计的直接好处是避免了元数据成为性能瓶颈 —— 写入密集型场景下，元数据变更的频率远低于数据变更，将其独立出来可以让存储节点更专注于数据处理。
分片层面的 Raft 组实现了完整的 ACID 事务语义，这是许多搜索引警所不具备的能力。在实际工程中，这意味着可以将对同一实体的多次修改打包为一个事务：例如更新文档内容的同时更新其关联的图索引，避免出现数据不一致的状态。当分片内的数据量增长到一定阈值后，系统会自动触发分片分裂（Shard Split），将一个大的分片拆分为两个较小的分片，整个过程由 Raft 协议保证一致性。
混合检索：从 BM25 到 SPLADE 的三层融合
Antfly 的查询引擎支持同时利用多种检索方法：传统的 BM25 全文检索、稠密向量（Dense Vector）语义检索，以及稀疏向量（SPLADE）检索。这三种方法各有其适用场景：BM25 对于精确关键词匹配仍然最可靠，SPLADE 能捕捉到关键词之间的隐含关联而无需显式的向量化训练，稠密向量则在语义相似度上表现最好。Antfly 在执行查询时将这些结果通过 Reciprocal Rank Fusion（RRF）算法进行融合，开发者无需手动决定各类检索的权重配比。
在 RAG 场景中，这种混合检索的价值尤为明显。用户的自然语言查询往往既包含意图性的语义成分，又包含实体性的关键词成分。如果只用向量检索，检索结果可能因为语义模糊而遗漏关键文档；如果只用全文检索，则无法召回那些表述不同但含义相近的相关内容。混合检索通过融合多路结果，显著提升了召回率的上限。
一个典型的调参场景是设置 Score Pruner。Antfly 支持两种剪枝策略：min_score_ratio 用于保留分数不低于最高分一定比例的结果，max_score_gap_percent 则用于检测分数曲线中的「拐点」，自动切断分数断崖式下降的位置。在 Wikipedia 这样的开放域数据集上，建议的起始参数是 min_score_ratio: 0.01 用于初筛，配合 max_score_gap_percent: 40 来过滤噪声结果。当进入 RAG 流程后，可以将 min_score_ratio 调整为 0.6 以确保进入生成阶段的上下文具有足够的相关性。
图索引机制：写入时自动构建关系
Antfly 最具差异化的特性在于它的图索引（Graph Index）。与大多数需要在应用层手动维护关系数据的系统不同，Antfly 在数据写入时就会自动分析文档内容，提取实体和它们之间的关系，构建图索引结构。这一能力由可配置的 Enrichment Pipeline 提供支撑：写入文档时，系统会依次执行分块（Chunking）、向量化（Embedding）和关系抽取（Relationship Extraction）等步骤，最终生成可供图遍历查询的数据。
这种设计的工程意义在于：图查询不再是独立于搜索的另一种数据访问方式，而是与检索完全融合的能力集合。开发者可以先通过向量或全文检索找到候选文档，再利用图索引探索这些文档之间的关联路径。例如，在一个技术文档系统中，用户可以先检索到某篇关于 Kubernetes 的文章，然后通过图查询找出它引用了哪些基础文档、又被哪些进阶指南所引用。这种「检索 + 探索」的组合是单一向量检索无法提供的。
图遍历查询目前支持基本的路径发现和邻居查询。在实际应用中，这可以用于构建问答系统的引用链 —— 当 RAG Agent 生成答案时，不仅能给出最终结果，还能追溯答案涉及的实体关联路径，提高结果的可解释性。
RAG Agent：搜索与生成的深度集成
Antfly 内置的 Retrieval Agent 将混合检索、重新排序（Re-ranking）和语言模型生成串联为一个完整的管道。与独立使用 LangChain 等框架不同，Antfly 的 Agent 在同一进程内完成检索和生成，减少了进程间通信的延迟，也避免了数据在多个系统间流转时的序列化开销。
在检索阶段，Agent 会先用混合检索召回候选文档，然后通过交叉编码器（Cross-Encoder）重新排序以提升相关性排序的质量。Termite 是 Antfly 内置的机器学习推理引擎，预置了针对 CPU 优化的 ONNX 运行时，可以本地运行 embedding、reranking 和 generation 模型而无需调用外部 API。一个生产可用的组合是：embedding 使用 BAAI/bge-small-en-v1.5，reranking 使用 mixedbread-ai/mxbai-rerank-base-v1，生成模型使用 onnxruntime/Gemma-3-ONNX。这套组合在消费级 CPU 上即可运行，延迟控制在秒级。
生成阶段的上下文管理同样支持可落地的参数调优。max-context-tokens 参数控制输入模型的上下文窗口大小，配合前述的 score pruning 可以在保证相关性的前提下将 token 消耗控制在合理范围。Agent 还支持流式输出（Streaming），在生成过程中实时返回 token，避免等待完整响应带来的体验问题。
对于需要结构化输出的场景，可以关闭流式模式获取 JSON 格式的答案和来源引用，这在需要程序化处理回答结果时非常有用。Agent 还内置了评估能力，可以对检索质量和生成质量分别打分，支持的指标涵盖传统的召回率、精确率、NDCG，也支持 LLM-as-Judge 模式的忠诚度、相关性等主观指标。
多模态扩展：图像与音频的原生支持
除了文本数据，Antfly 还支持对图像、音频、视频等多模态数据的索引和检索。系统内置了 CLIP 模型用于图像的语义嵌入 —— 这意味着可以用自然语言描述来搜索图片，也可以用图片来检索语义相近的文档。CLIP 模型的向量维度为 512，支持通过 Antfarm Dashboard 直接体验。
对于音视频数据，Antfly 集成了 CLAP 等模型进行音频嵌入，并通过转录（Transcription）将语音内容转换为可检索的文本。这种多模态统一索引的能力在企业知识管理场景中尤为实用：一份产品介绍文档可能包含产品图片、产品介绍视频和产品手册音频，传统方案需要为每种媒体分别建立索引并分别检索，Antfly 则可以在同一个查询中同时覆盖所有媒体类型的候选结果。
部署与运维：从本地开发到 Kubernetes 生产
对于本地开发，antfly swarm 命令可以一键启动包含元数据节点、数据节点和 Termite 推理引擎的单节点集群。启动后访问 http://localhost:8080 可以进入 Antfarm Dashboard，在图形界面中完成表创建、索引配置、查询测试和 RAG 对话等操作。这种「开箱即用」的设计显著降低了学习成本。
生产环境推荐使用 Antfly 官方维护的 Kubernetes Operator 进行部署。Operator 会自动处理节点的发现、分片的分配和副本的调度，与 Kubernetes 的声明式 API 风格保持一致。对于大规模数据，Antfly 支持将底层存储对接 S3 或兼容 S3 的对象存储（如 MinIO、Cloudflare R2），这样分片分裂时的数据迁移可以借助对象存储的带宽优势更快完成，同时降低存储成本。
选型考量与适用边界
Antfly 的设计目标很明确：在一个系统中提供从数据写入、索引构建、混合检索、图查询到 RAG 生成的完整能力链。这对于希望简化技术栈、避免拼接多个专用系统（Elasticsearch + Neo4j + LangChain）的团队具有吸引力。但需要注意几个实际约束：当前项目整体采用 ELv2 许可证，核心服务器代码不可用于商业托管服务；多模态模型（尤其是图像和音频）的推理性能高度依赖硬件，在没有 GPU 的环境下大规模图像搜索可能面临延迟挑战；图索引的自动关系抽取质量取决于内置模型的精度，对于特定领域的专业术语可能需要微调或自行扩展 Pipeline。
总体而言，如果你正在构建一个需要同时满足语义搜索、实体关系探索和多模态内容管理的 AI 应用，Antfly 提供了一种一体化解决的工程思路 —— 从写入时的自动图构建，到查询时的混合检索融合，再到 RAG 阶段的端到端 Pipeline，都在同一个分布式系统中完成。这种架构简化了运维复杂度，也为探索「搜索即图谱、图谱即记忆」的下一代 AI 数据基础设施提供了有价值的实践参考。
资料来源：Antfly 官方 GitHub 仓库（https://github.com/antflydb/antfly）