QAnything

1. 项目/产品概览

2. 它主要能做什么

QAnything 的核心是一条完整的 文档解析 → 向量索引 → 两阶段检索 → LLM 生成 流水线，用户只需上传文件即可获得基于文档内容的准确回答。

2.1 文档解析能力（有道核心积累）

2.2 OCR 能力

有道翻译/OCR 的技术积累是 QAnything 区别于其他国产 RAG 方案的核心壁垒。对于中文扫描件 PDF（图片型 PDF），QAnything 的 OCR 识别准确率显著优于通用 OCR 引擎。v2.0 中 OCR 作为独立服务可单独调用（HTTP）。

2.3 两阶段检索（核心架构差异化）

QAnything 使用自研 BCEmbedding 模型（Apache-2.0 开源），包含两个组件：

• 一阶段 Embedding（bce-embedding-base_v1）：MTEB 评测综合得分 59.43，显著优于 BGE-large-zh-v1.5（54.21）、M3E-base（53.54），中文跨语种场景尤其突出
• 二阶段 Rerank（bce-reranker-base_v1）：Reranking 得分 60.06，优于 BGE-reranker-large（59.69）
• 组合效果 SOTA：在 LlamaIndex RAG 评测中，BCEmbedding + BCReranker 的组合达到当前最优

两阶段检索的核心价值：知识库数据量越大，一阶段 Embedding 检索会出现"检索退化"问题，Rerank 重排能逆转趋势，实现"数据越多、效果越好"。

2.4 混合检索 & 其他功能

3. 适用场景

4. 不太适合的场景

5. 核心能力清单

6. 架构/部署/集成方式

整体架构

用户上传文档（PDF/Word/PPT/...）
    │
    ▼
文档解析层（PDF Parser / OCR / 格式转换器）
    │
    ▼
文本分块 + 元数据提取
    │
    ▼
向量化索引（Embedding 服务 + Elasticsearch/Milvus 等）
    │
    ▼
用户提问 → 一阶段 Embedding 检索（粗筛）
    │
    ▼
二阶段 Rerank 重排序（精排）
    │
    ▼
LLM 生成回答（OpenAI 兼容接口）
    │
    ▼
返回答案 + 溯源引用

部署模式

硬件要求

模型集成

• LLM：所有兼容 OpenAI API 的模型（Ollama、通义千问 DashScope、DeepSeek、GLM 等）
• Embedding + Rerank：默认 BCEmbedding（自研，可替换）
• 向量存储：Elasticsearch（内置中文分词器 IK）

API 支持

提供 RESTful API，可通过 API 进行文件上传、知识库管理、问答等全部操作。v2.0 版本中 Embed、Rerank、OCR、PDF 解析均支持独立 HTTP 调用。

7. 怎么用

Docker 一键部署（推荐）

# 克隆项目
git clone https://github.com/netease-youdao/QAnything.git
cd QAnything

# 启动服务（根据操作系统选择 compose 文件）
# Linux
docker compose -f docker-compose-linux.yaml up -d

# Mac
docker compose -f docker-compose-mac.yaml up -d

# Windows
docker compose -f docker-compose-win.yaml up -d

# 访问 Web UI
# 浏览器打开 http://localhost:5052

配置 LLM

在 Web UI 前端设置页面配置：

• API_BASE：LLM 服务的 API 地址（如 https://api.openai.com/v1 或 Ollama 的 http://localhost:11434/v1）
• API_KEY：API 密钥
• MODEL：模型名称（如 gpt-4o、qwen-plus、deepseek-chat）

API 调用示例

import requests

# 上传文件到知识库
url = "http://localhost:5052/api/local_doc_qa/upload_files"
files = {"files": open("contract.pdf", "rb")}
data = {"kb_id": "KB123456", "user_id": "user001"}
resp = requests.post(url, files=files, data=data)

# 问答
url = "http://localhost:5052/api/local_doc_qa/local_doc_chat"
payload = {
    "question": "这份合同的关键条款是什么？",
    "kb_ids": ["KB123456"],
    "user_id": "user001"
}
resp = requests.post(url, json=payload)
print(resp.json()["response"])

使用 BCEmbedding 独立组件

# BCEmbedding 是 Apache-2.0 协议，可单独使用
from BCEmbedding import EmbeddingModel, RerankerModel

# Embedding
embed_model = EmbeddingModel(model_name_or_path="maidalun1020/bce-embedding-base_v1")
embeddings = embed_model.encode(["什么是RAG?", "RAG是检索增强生成"])

# Rerank
reranker = RerankerModel(model_name_or_path="maidalun1020/bce-reranker-base_v1")
scores = reranker.compute_score(["什么是RAG?"], ["RAG是检索增强生成技术"])

8. 售前可以怎么讲

8.1 一句话定位

"QAnything 是网易有道出品的文档智能问答系统——把中文扫描件扔进去，秒出准确答案。"

8.2 客户痛点 → 解决方案

8.3 差异化卖点

vs RAGFlow（InfiniFlow 开源）：

• QAnything 优势：有道 OCR 积累 → 中文扫描件/表格 PDF 解析效果更好；BCEmbedding 双语跨语种 SOTA；纯 CPU 部署更轻量
• RAGFlow 优势：DeepDoc 解析引擎更全面（支持布局识别 YOLOv8）；v0.21+ 引入 Ingestion Pipeline 可编排；更新非常活跃（2025-2026 持续高频迭代）；Apache-2.0 协议更友好
• 结论：如果客户核心需求是"海量多样格式的复杂文档深度解析 + 可编排 Pipeline"，选 RAGFlow；如果是"中文扫描件/表格 PDF 问答 + 简单部署"，QAnything 更精准

vs MaxKB（1Panel 开源）：

• QAnything 优势：检索模型更强（BCEmbedding SOTA vs MaxKB 基础检索）、文档解析更深度（尤其 OCR/表格）、企业版有商业支持
• MaxKB 优势：Stars 更多（20,600+）、协议友好（GPL-3.0 with MaxKB EULA）、有工作流编排和 MCP 工具调用、社区活跃度高很多、与 1Panel 运维生态深度整合
• 结论：MaxKB 更适合作为通用平台型 Agent 底座；QAnything 更聚焦"文档→问答"这一条路走到极致

vs Dify：

• QAnything 是"文档问答专用工具"；Dify 是"AI 应用开发平台"
• Dify 有可视化工作流编排、丰富的工具和插件生态，但文档解析深度不如 QAnything
• QAnything 适合不需要复杂编排、只需文档问答的客户；Dify 适合需要自定义 AI 应用的企业

核心差异化总结：有道 OCR + BCEmbedding + 纯 CPU 部署 + 扫描件友好

8.4 客户价值故事线

1. 切入："你们公司有很多扫描版的合同/档案/报告，想用 AI 问答但 OCR 效果不好？"
2. 共鸣："通用 OCR 引擎对中文扫描件识别率低，表格跨页后内容断裂，分栏布局读错顺序——这些都是常见坑。"
3. 演示：上传一份中文扫描版 PDF 合同（含表格），提问"违约责任条款是什么？"——QAnything 准确识别扫描文字、解析表格、定位答案、溯源原文
4. 进阶：从单文档 → 批量上传建立企业知识库 → 自定义 Bot（销售助手/法务助手/技术顾问）→ API 集成到 OA 系统
5. 收尾："网易有道 20 年 OCR 技术积累，14,000+ GitHub Stars，3000+ 微信社群用户——在这个细分赛道上没有更强的开源方案了。"

9. 常见客户问题

10. PoC 建议

推荐 PoC 方向：中文扫描件 PDF 问答

这是 QAnything 最核心的差异化场景，建议 PoC 聚焦于此以最大化展示其不可替代性。

验证指标：

• OCR 文字识别准确率 > 95%（中文扫描件）
• 表格数据提取完整率 > 90%
• 端到端回答准确率 > 85%（基于文档事实性验证）
• 平均响应时间 < 5 秒（纯 CPU 环境）
• 答案溯源准确（引用的文档位置与答案匹配）

PoC 注意事项：

• 务必用客户自己的真实文档，不要用干净排版的测试文档
• 如果客户对 AGPL 协议有顾虑，PoC 阶段就应明确：开源版仅用于技术验证，商用需企业版授权
• 提前告知客户纯 CPU 模式下大规模文档的索引速度预期

11. 风险和注意事项

12. 我的售前判断

推荐度：谨慎推荐（极适合特定场景，但整体风险较高）

理由：

1. 不可替代的差异化优势：有道 OCR + BCEmbedding 的组合，在处理中文扫描件 PDF 这个细分场景上，目前没有更好的开源方案。如果客户正好是这个场景，QAnything 就是最优选。
2. 部署友好：Docker 一键启动、纯 CPU 运行、镜像 4.88GB，对没有 GPU 的中小企业极其友好。
3. 功能完整且稳定：虽然不再更新，但 v2.0 已经是一个成熟可用、功能齐全的文档问答系统。
4. 但是——AGPL 和维护停滞是两颗雷：法务风险 + 技术停滞 = 售前必须充分告知客户，不能回避。

推荐客户画像：

• 核心诉求精准命中"中文扫描件/表格 PDF → 本地问答"
• 纯内网部署，不对外提供文档问答服务（可规避 AGPL 风险）
• 对功能更新频率要求不高，v2.0 现有功能已能满足需求
• 预算有限但需要 OCR 优势（开源版即可满足）
• 或有预算购买企业版（商业授权 + 更强能力）

不推荐的情况：

• 客户法务明确禁止使用 AGPL 协议 → 直接排除开源版，推企业版或换 RAGFlow/MaxKB
• 需要长期持续的功能迭代和社区支持 → 推荐 RAGFlow（更新最活跃）
• 需要工作流编排、多 Agent、插件生态 → 推荐 Dify/MaxKB
• 文档以英文或非扫描件为主 → OCR 优势不明显，推荐 RAGFlow 或 Haystack
• 高并发对外服务（且不想付费） → AGPL 风险不可接受

售前策略建议：

• 先判断客户文档类型：有大量扫描件 → QAnything 为第一推荐
• 再确认 AGPL 立场：法务 OK 且内网使用 → 直接推开源版 PoC
• 法务不 OK 或需对外服务 → 推企业版或 BCEmbedding 自建方案（BCEmbedding 是 Apache-2.0！）

13. 参考资料

• GitHub 仓库：https://github.com/netease-youdao/QAnything
• 官网 / 在线体验：https://qanything.ai
• BCEmbedding（检索模型，Apache-2.0）：https://github.com/netease-youdao/BCEmbedding
• 有道速读（在线试用）：https://read.youdao.com
• FAQ（中文）：https://github.com/netease-youdao/QAnything/blob/qanything-v2/FAQ_zh.md
• 需求反馈：https://qanything.canny.io/feature-requests
• HuggingFace 模型：https://huggingface.co/maidalun1020
• 企业版商务联系：AIcloud_Business@corp.youdao.com / 010-8255-8901

分析日期：2026-07-02 | 数据时效：GitHub 信息实时拉取，官网内容来自 qanything.ai，竞品对比基于 2026 年最新数据