共计 2720 个字符，预计需要花费 7 分钟才能阅读完成。
处理 PDF 文档是很多人日常工作里的高频任务——研究报告、技术手册、合同文件、学术论文，这些东西往往又长又密，真正有用的信息可能只藏在某个角落。传统的做法是关键词搜索加手动阅读，效率低、容易漏。用 AI 直接问文档是个更好的方向，但很多 RAG 工具有一个共同问题：它给你一个答案，却不告诉你这个答案来自文档的哪一页哪一段，你无从验证，也无从深入阅读。Kotaemon 在这个点上做得比大多数同类工具要好。
Kotaemon 是什么
Kotaemon 是一个基于 [[RAG]]（Retrieval-Augmented Generation，检索增强生成）的开源文档问答 Web 应用，由 Cinnamon AI 开源，目前 GitHub 上积累了超过 25000 颗星，使用 Apache-2.0 协议。整体用 Python 构建（占约 92% 代码量），UI 基于 [[Gradio]] 框架。
它的定位是面向三种用户的：直接使用预构建应用的终端用户、把 Kotaemon 导入自己项目的开发者，以及参与改进代码库的贡献者。这种分层设计意味着它既可以开箱即用，也支持深度定制，不同需求的人都有对应的切入方式。
与很多 RAG 工具相比，Kotaemon 有一个让我印象最深的差异：它内置了一个浏览器端 PDF 查看器，AI 给出的每条引用都会在原始 PDF 里高亮显示，并且附上相关性评分。你不仅能看到答案，还能立刻定位到文档里的具体位置，确认 AI 是从哪里得出这个结论的。这对于需要核实信息准确性的场景非常关键。
核心功能拆解
混合检索管道（Hybrid RAG Pipeline）是 Kotaemon 检索效果的基础。它同时使用全文搜索和向量检索，再通过重排序（re-ranking）对结果进行精选，比单纯的向量检索准确率更高。面对同一个问题，混合检索能覆盖更多相关段落，减少遗漏。
多模态文档理解让 Kotaemon 不只是处理文字段落，还能理解文档里的图表和表格。很多技术文档和研究报告里最关键的数据恰恰在图和表里，这项能力让它在处理这类文档时有明显优势。解析引擎方面支持多个选项：本地的 Docling 和 PaddleOCR，以及云端的 Azure Document Intelligence 和 Adobe PDF Extract，可以根据需求和预算选择。
GraphRAG 支持是一个高级特性。普通 RAG 把文档切成段落做向量检索，而 GraphRAG 还会提取文档里的实体和关系，构建知识图谱，在处理需要跨段落推理的复杂问题时效果更好。Kotaemon 集成了三种 GraphRAG 实现：NanoGraphRAG（官方推荐，集成最顺畅）、LightRAG 和 MS GraphRAG。
复杂推理能力方面，Kotaemon 支持问题分解——当一个问题太复杂时，它会先把问题拆成子问题分别回答，再合并推理。同时支持 ReAct 和 ReWOO 两种 Agent 推理模式，应对需要多步骤思考的场景。
多用户支持让它适合团队部署，不同成员可以有各自的账号，文件集合可以设为私有或公开，对话记录也可以共享。这些功能让它超出了"个人工具"的范畴，可以作为一个小团队的共享文档问答平台运行。
LLM 与模型支持
Kotaemon 对模型提供商的支持比较全面，云端和本地都覆盖到了。
云端方面支持 OpenAI（GPT 系列）、Azure OpenAI、Cohere 和 Groq。本地方面通过 [[Ollama]] 接入兼容 OpenAI API 的本地服务，或者用 llama-cpp-python 直接加载 GGUF 格式的量化模型。官方推荐入门本地模型是 Qwen1.5-1.8B-Chat-GGUF，体积约 2GB，在普通机器上也能跑。
向量存储方面同样灵活：ChromaDB、LanceDB、Milvus、Qdrant、Elasticsearch 和内存模式都支持，根据数据量和部署场景选择合适的方案。
支持的文档格式核心版本包含 .pdf、.html、.mhtml、.xlsx，安装 Unstructured 扩展后可以额外支持 .doc、.docx 等更多格式。
安装与部署
Docker 是最推荐的安装方式，官方提供了三个镜像变体以适应不同需求：
main-lite：轻量版本，适合只用主流文档格式的场景main-full：包含 Unstructured，支持更多文档格式main-ollama：打包了 Ollama，完全本地私有的 RAG 环境
启动后访问 http://localhost:7860/，默认用户名和密码都是 admin，第一次进入后记得改掉。
如果不想用 Docker，也可以直接从源码安装：
git clone https://github.com/Cinnamon/kotaemon
cd kotaemon
uv sync --python 3.10
source .venv/bin/activate
python app.py
这里用了 uv 作为包管理器，如果没有的话也可以用 conda 或 pip。
配置方面，首次运行前可以在根目录创建 .env 文件预设 API Key 和模型端点，避免每次在界面里手动填写。flowsettings.py 控制更底层的设置，比如向量存储选择、是否启用多模态 QA、推理管道的选型。应用数据统一存储在 ./ktem_app_data 目录，便于备份和迁移。
几点使用建议
第一次上手时，如果觉得本地模型配置太麻烦，可以先用 Groq 的免费 API——速度快、上手零成本，适合快速感受 Kotaemon 的核心体验，之后再考虑换成 Ollama 本地模型或其他方案。
文档的解析质量直接影响检索效果。对于扫描件 PDF 或图表密集的文档，开启 Docling 或 PaddleOCR 这类本地 OCR 解析引擎会有明显改善，但会增加处理时间；如果文档是可直接提取文字的 PDF，默认解析器就够用。
GraphRAG 功能很强大但也更消耗资源，适合在数据量较大、需要复杂跨文档推理时启用。日常快速问答用标准 RAG 管道反应更快，两种模式各有适用场景，不必总是开最重的模式。
Kotaemon 也开放了开发者接口，如果你有定制需求，可以在 libs/ktem/ktem/reasoning/ 目录下新增自定义推理管道，或者直接 import kotaemon 在自己的项目里调用其检索和问答能力。
最后
Kotaemon 在文档问答工具这个细分赛道里打磨得相当扎实。带高亮引用的 PDF 查看器、混合检索管道、GraphRAG 支持、多用户文件集合，这些功能叠在一起，让它既能应付个人研究场景，也能在小团队里作为共享知识库工具使用。如果你日常需要和大量 PDF 文档打交道，或者想给团队部署一套内部文档问答系统，Kotaemon 值得认真试一试。相比那些功能单一的 RAG 工具，它更像一个可以持续投入使用、随着需求扩展能力的平台。
