一个刻意收窄边界的RAG库

每一篇 RAG 库的发布文章，开篇都在讲能力。我们选择先讲清楚范围，因为真正决定一个库是否适合你的项目的，恰恰是它的能力边界——而大多数发布文章都会悄悄略过这一点。

聚焦明确边界的技术考量

ragleap-rag 专注于检索增强生成。它不提供 Agent 式工具调用、多步骤编排，也不提供 human-in-the-loop 审批机制。这并不是什么需要我们为之道歉的 v1.0 局限，而是一条有意划定的边界。因为把 Agent 推理能力硬塞进一个检索库，往往意味着两部分都做不好。

如果你确实需要这些能力，路线图中规划了独立但尚未构建的软件包（ragleap-agents、ragleap-flows），而不是在当前这个包里放进一个只实现了一半的功能。

v0.11.1 实际提供了什么

检索：混合使用稠密检索（pgvector cosine）与稀疏检索（Postgres full-text），并通过 Reciprocal Rank Fusion 融合结果。如果只想执行一次查询而不是两次，可以设置 hybrid=False，仅使用稠密检索。

重排序：通过 ONNX Runtime 运行 cross-encoder，仅使用 CPU，大小约为 23MB。不需要 torch，也不需要 CUDA——即使你从来不用 GPU，大多数重排序库默认拉取的模型也会带来超过 2GB 的安装体积。

向量后端：共支持 6 种，并已直接合并进核心代码，不再作为独立软件包维护。目前，pgvector 和 FAISS 已经在真实服务上完成实际验证。Pinecone、Weaviate、Qdrant 和 Milvus 的代码已经完成，但尚未经过真实环境测试——在完成测试之前，我们不会声称它们达到了同等支持水平。

可靠性：支持链式 fallback，而不只是单个 fallback；从 provider 自己的响应中提取每次调用真实的 token 用量和成本数据；每个方法都有对应的 async 版本；支持连接池；支持以 Redis 为后端的分布式查询缓存，适用于多进程部署。

数据摄取：支持 28 种文件格式；支持 URL，并通过 trafilatura 进行干净的内容提取；支持图片，包括 OCR 和 vision captioning；支持音频和视频，包括通过 ffmpeg 提取内容并使用可插拔的转录方案；支持并发摄取多种类型的批量数据，并能隔离单个条目的失败，避免影响其他条目。

测试：包含 238 个自动化测试，每个 PR 都会运行真正的 CI；相比上一个重要里程碑时的 72 个测试，数量有了显著提升。

python pip install ragleap-rag

from ragleap import RagLeap, ProviderConfig, EmbeddingConfig

rag = RagLeap( database_url="postgresql://user:pass@localhost/mydb", embedder=EmbeddingConfig(provider="gemini", api_key="..."), primary=ProviderConfig(provider="gemini", api_key="..."), ) rag.init_schema()

result = rag.ingest("handbook.pdf", raw_bytes) answer = rag.ask("What's our PTO policy?")

接下来是什么

路线图中的下一步是 ragleap-graph（通过 Neo4j 实现知识图谱增强检索）和 ragleap-integrations（MCP-native + 精选 connectors）。ragleap-agents 和 ragleap-flows 会在此之后推出——这是有意安排的开发顺序，而不是为了制造一条与 LangChain 功能对等的宣传标题，就仓促把它们塞进来。

代码仓库：github.com/antonyrag/ragleap-core
PyPI：pypi.org/project/ragleap-rag

我们真心想知道，当你把它用到真实场景中时，哪些地方会出问题——issue tracker 正是为此而设。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。