8.0
热点
AI SCORE
开源项目2026-10-16 10:58
LocalRAG 开源本地文档问答完整链路
dev.to · AI#RAG#本地部署#开源
Editor brief · 编辑速览
LocalRAG 使用本地 bge-m3 生成嵌入、Qdrant 存储向量，并由本地大模型回答文档问题、返回来源引用，支持 PDF、DOCX、TXT 和 Markdown。作者称 v0.1.0 已完成端到端验证，无需云端 AI API。
许多团队希望用 AI 回答内部文档中的问题，但他们不能把这些文档发送到云服务。
法律团队有保密的案件资料，诊所有患者数据，财务团队有客户工作底稿，制造企业有专有的工艺文档。有些组织则运行在隔离网络中。
对这些团队来说，云优先的 RAG 技术栈根本不在考虑范围内。
我构建 LocalRAG，是为了验证一个简单的想法：
文档问答系统应该能够在受控环境中运行，使用本地模型，并为每个回答提供来源引用。
这个项目已经开源，当前的 v0.1.0 版本也已通过端到端验证。
代码仓库：Pingredsai/local-rag
发布版本：v0.1.0
LocalRAG 允许用户上传文档，并针对这些文档提问。
已经验证的流程如下：
应用在运行时不会调用云端 AI API。
首次安装仍然需要联网，以拉取 Docker 镜像和 Ollama 模型。完成这些准备后，整套系统就可以在本地或物理隔离的环境中运行。
LocalRAG 使用三个主要容器：
Browser UI
|
v
FastAPI Backend
- document parsing
- chunking
- RAG orchestration
- REST API and static frontend
|
+--> Qdrant
| vector storage and search
|
+--> Ollama
bge-m3 embeddings
local LLM generation
我有意没有重新构建模型运行时、向量数据库或 Agent 引擎。
真正有意思的工程问题，不是重新发明 Ollama，而是让完整工作流在私有部署中做到可复现、可观测，而且好用。
我使用以下配置测试了当前版本：
测试文档是一本虚构的员工手册。
系统将它切分为三个文本块并建立索引。
随后收到问题：“全职员工每年有多少天年假？”
系统检索到了相关的政策文本。
UI 中也显示了来源文档和相似度分数。
健康检查返回如下结果：
{
"status": "ok",
"qdrant": "ok",
"ollama": "ok",
"llm_model": "qwen2.5:3b",
"embed_model": "bge-m3"
}
代码仓库中提供了截图和一段 42 秒的演示视频。
git clone https://github.com/Pingredsai/local-rag.git
cd local-rag
cp .env.example .env
docker compose up -d
docker exec localrag-ollama ollama pull qwen2.5:3b
docker exec localrag-ollama ollama pull bge-m3
http://localhost:8080
使用最新的 Docker 镜像很方便，但镜像解包后的体积可能接近 9 GB。在网络较慢的环境中，这是一个严重的部署问题。
我将项目固定在一个体积更小、兼容的 Ollama 版本上，并在文档中说明了这一部署取舍。
这也提醒我，运行时的体积和下载行为都是产品体验的一部分，不只是基础设施细节。
在我的环境中，Docker Hub 的速度极慢。最终采用的解决办法结合了镜像源、可断点续传的拉取方式，以及部分情况下的本地模型导入。
我没有在项目中硬编码第三方镜像源，而是在部署说明中介绍了处理方法，方便运维人员自行替换。
最初的实现通过流式端点返回文本，而来源信息只在非流式端点中提供。
这让 UI 看起来就像一个普通聊天机器人。对于业务系统至关重要的来源引用，用户却看不到。
我修改了流式端点，让它通过响应头返回来源元数据。前端读取响应头，流式展示回答，并在回答完成后渲染来源卡片。
较小的模型在短上下文中可以正常工作，但文档稍长一些，回答就会变得不稳定。
我将演示使用的模型切换为 qwen2.5:3b，并进一步收紧了 prompt 和生成选项。
本地 AI 不会因为模型更小就自动变得更好。模型大小必须与硬件、使用场景和所需的回答质量相匹配。
第一个版本的范围是刻意收窄的。
v0.1.0 的目标，是让这条核心路径稳定可靠：
upload -> index -> retrieve -> answer -> show sources
我宁愿把这些边界说清楚，也不愿让人误以为这个项目已经是一个生产级平台。
长期目标是大幅简化私有 AI 的部署，然后让用户能够组装自己的本地 Agent。
但我不会一上来就再造一个通用 Agent 平台。
Dify、Flowise、Langflow、Open WebUI、AnythingLLM、RAGFlow 和 FastGPT 等现有项目，已经覆盖了这个领域的很大一部分需求。
缺少的是切实可用的部署与运维层：
我计划按以下顺序推进：
平台不是起点，而是反复交付之后沉淀下来的东西。
我正在寻找以下领域的真实 POC：
第一个 POC 可以很小。我们只需要验证：
代码仓库：Pingredsai/local-rag
如果你也在做本地优先的 AI 项目，我很乐意交流经验。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。