资料处理与检索生态
比较文档框架、存储、表示模型和成品检索系统的任务边界。
资料链路决定比较对象
资料问答由解析、分块、表示、存储、受权检索、重排及生成组成。解析失败会丢失表头、阅读顺序或正文；检索失败会遗漏证据；生成失败会误读已取出的资料。工具覆盖其中哪些环节，需要分别比较。同一个框架支持很多 connector，无法据此证明某个文档集的问答质量。
| 管线候选 | 侧重 | 采用时的条件 |
|---|---|---|
| LlamaIndex Python | 文档、索引、retriever、Workflows，LlamaParse 服务连接 | 组件版本、解析云上传及商用费用 |
| LangChain TS/Python | loader、splitter、retriever 与 agent 集成 | 包边界、metadata 转换及生命周期 |
| Haystack | 显式组件与 Pipeline 的资料处理链路 | 需要自己组织数据流、存储和运维 |
| Mastra RAG | TS 的文档处理、切分和数据库集成 | 是否已采用 Mastra；包与模型层兼容 |
| AI SDK 加官方客户端 | 嵌入／重排等模型接口加应用管线 | 自行维护文档、权限和引用契约 |
| DSPy | 定义模块与用评测优化提示／程序 | 可靠训练／验证集、优化费用及保留测试 |
| txtai | 较紧凑的嵌入搜索和工作流 | 部署、扩展及数据需求是否匹配 |
Mastra 的 MDocument 与切分／metadata 提取可缩短 TS 接线；AI SDK 的 embedMany 批量生成向量仍需存储和失败恢复；LlamaIndex.TS 的归档维护信号应在采用前复查，不能用 Python 生态的能力与热度证明 TS 实现同样完整。LlamaIndex、LangChain 检索、Haystack、Mastra RAG、DSPy、txtai、AI SDK 嵌入。
解析器与成品平台
Docling、Unstructured 支持本地文档解析及相应服务；LlamaParse 提供托管解析，LiteParse 是需单独核对的本地路线。选择时用实际 PDF、表格、扫描件和嵌套标题检查位置、脚注、公式、OCR、阅读顺序、失败率与吞吐，并核对文档上传和保留条款。某个解析器在结构化 PDF 上较好，不能直接推广到扫描档案。Docling、Unstructured、LlamaParse。
RAGFlow 提供 DeepDoc、引用及应用界面，适合需要成品系统的团队；深层修改需要理解其整套存储与运行结构。LightRAG 使用图与向量的结合，Microsoft GraphRAG 用社区组织和摘要回答全局问题，索引阶段可能增加大量模型调用。Graphiti 的时态图侧重持续更新与 agent 记忆。图链路只有在问题确实需要实体关系或全局组织时才值得新增抽取、更新和治理成本。RAGFlow、LightRAG、GraphRAG、Graphiti。
数据库如何进入已有系统
| 候选 | 组织及查询特点 | 重点比较的代价 |
|---|---|---|
| PostgreSQL + pgvector | SQL、事务、RLS、JOIN 与向量查询共处 | 索引内存、过滤后召回、写入维护和现有数据库负载 |
| Qdrant | payload 过滤、稠密／稀疏及查询组合 | 分片、索引、部署和客户端版本 |
| Weaviate | schema、向量器模块及 hybrid 查询 | 模块供应商依赖、集群与 alpha 等查询配置 |
| Milvus | 分布式向量检索与混合查询 | 存储组件、分区、部署规模和运维 |
| Pinecone | 托管索引服务 | 区域、计费、过滤与数据所在地 |
| turbopuffer | 对象存储结合检索的托管路线 | 冷数据延迟、更新、费用口径与云地域 |
| Chroma | 本地或服务化的文档／向量集合 | 目标部署的并发、认证、备份及服务版本 |
| FAISS | 近邻算法库 | 持久化、授权、过滤、备份及服务需另建 |
| LanceDB | 嵌入式与相应云产品，列式资料及向量 | 本地文件并发、版本与云组件差异 |
既有搜索团队可考察 Elasticsearch／OpenSearch／Vespa 的全文和向量能力；已有 MongoDB Atlas 可考察其搜索集成。Upstash Vector、Cloudflare Vectorize 是对应云的选项，sqlite-vec、PGlite 更适合嵌入式或本地约束；Marqo 提供多模态搜索路线。这些候选减少某种接线成本，同时继承所属平台、部署与许可边界。pgvector、Qdrant、Weaviate、Milvus、Pinecone、turbopuffer、Chroma、FAISS、LanceDB、Vespa、Marqo。
TS 客户端的 package 与数据库服务端版本分别核对。例如 pgvector 的 Node 包可提供类型解析与序列化，索引能力来自 PostgreSQL 扩展；有 SDK 的集合管理入口不代表自托管与托管服务全部功能相同。Mastra／LangChain 的 libsql、Turso、D1、S3 Vectors、Redis、ClickHouse、DuckDB、Convex、OpenSearch 等集成提供接线入口；数据库本身的过滤、事务、部署与许可仍逐项判断。Dify、n8n、RAGapp 等可视化或产品路线可减少部分拼接，前端使用 TS 无法证明整套运行环境也是 TS。
无需为每种规模规定唯一数据库。“数亿条必须分布式”“已有 Postgres 额外成本为零”“某产品低十倍成本”都缺少统一负载的证明。按向量维度、过滤选择率、top-k、更新频率、可用性与目标延迟测量，比较软件、存储、运维和迁移的完整成本。
表示与重排模型的选择
归档包含托管 OpenAI text-embedding-3 small／large、Cohere Embed、Voyage、Jina，以及本地 BGE-M3、Qwen3-Embedding、sentence-transformers／fastembed／Transformers.js 路线。维度缩减、稀疏或多向量、长文本、代码与多模态能力需从实际模型配置和接口确认；API 与本地权重的质量、批量和费用分别测量。BGE-M3 的多种表示需要存储与查询共同支持，不能只用单个稠密向量便宣称实现了全部能力。OpenAI 嵌入、BGE-M3、Qwen Embedding、Cohere、Voyage、Jina、fastembed。
重排候选包括 BGE-Reranker-v2-m3、Qwen3-Reranker、mxbai-rerank、Jina、Cohere 与 Voyage 服务。cross-encoder 成对评分和 listwise 整组评分承担不同输入及计算；长窗口不保证复杂整组评分可靠。模型在 MTEB、CMTEB 或某中文集合表现较好，不能证明在本地文档上的排序最好；多语言列表也无法推出中文任务质量。固定资料与问题，对照检索和重排后的召回、相关性、答案支持率、延迟及成本。BGE reranker、Qwen3-Reranker、Cohere Rerank、Voyage rerank。
本地 TS 的 ONNX／WebGPU 路线受模型转换、内存和后端算子影响，适用性需测量；归档“本地 rerank 不可行”不作通用结论。Python 的可用模型较多，也有转换、启动和算力成本。
增强策略按问题验证
递归、结构化、语义、父子块及 late chunking 的收益与文档和问题共同决定。归档的 512–1024 token、10–20% overlap 可作为初始搜索区间，长度不构成固定最优。Contextual retrieval 为块补文档上下文，新增生成和存储成本；厂商展示的召回改善比例仅支持其报告中的集合与配置。Anthropic contextual retrieval。
agentic RAG 把查询改写、多跳和资料工具交给运行循环，同时增加错误传播、延迟与预算控制。小语料可试全量长上下文，仍需核对权限、时效和证据定位。RAGAS、Phoenix 或模型评分只能测定义的代理指标，权限泄漏、删除闭环、事实依据和重要答案应另查。
本页没有重跑表示或重排榜单；“64% 生产系统使用重排”“百万查询每天的成本分界”来自归档中样本方法未公开的第三方数字，不能承担选型阈值。
最后更新于