rag

让AI用你自己的数据回答问题：RAG应用实战

你有没有遇到过这种尴尬：问AI一个关于你自己公司文档的问题，它一本正经地编造答案？这种"幻觉"问题让大模型在企业场景里寸步难行。而 neuml/rag 项目用一种优雅的方式解决了它——让AI回答问题前先去检索你的数据，再基于真实上下文生成答案。

图1：neuml 组织头像，该项目是 txtai 生态的核心应用之一

背景：为什么RAG如此重要

这个项目由 neuml 开发和维护，作者同时也是 txtai 框架的创建者。neuml 在 GitHub 上有多个相关项目形成完整生态：txtai（向量搜索+LLM框架）、paper-qa（论文问答）、basechain（链式调用）等。

RAG（Retrieval Augmented Generation，检索增强生成）是一种解决大模型"幻觉"问题的核心技术。原理很直观：用户提问时，系统先通过向量搜索引擎找到最相关的文档片段，再用这些真实内容作为上下文注入LLM的提示词，让AI"照着材料答题"而非"凭记忆发挥"。这比微调成本低、实时性高、可控性强，成为当前企业落地LLM应用的主流架构。

核心技术架构

该项目是一个基于 Streamlit 的 RAG 可视化应用，核心技术栈如下：

txtai 框架 是整个应用的核心依赖。它封装了从文本嵌入（Embeddings）到语义搜索的全流程。代码中默认使用 intfloat/e5-large 作为向量模型，这是一个支持双编码（query和passage分开编码）的稠密向量模型，通过 instructions 参数分别给查询和文档加上前缀标识（query: 和 passage: ），能显著提升召回精度。

两种RAG模式 是本项目区别于普通RAG应用的亮点：

第一种是向量RAG（Vector RAG），这是最经典的方式。用户输入问题后，系统在 Embeddings 向量索引中执行语义相似度搜索，找出最匹配的N条文档，然后将这些文档作为上下文传给LLM生成答案。代码中用 RAG pipeline 将 Embeddings 和 LLM 两个组件串联起来：

self.rag = RAG(
    self.embeddings,
    self.llm,
    system="You are a friendly assistant.",
    template=template,
    context=self.context,
)

第二种是图谱RAG（Graph RAG），这是更前沿的方案。当用户输入以 gq: 开头或包含 -> 路径符号时，系统会触发图谱查询模式。它使用 Cypher 查询语言在 NetworkX 图数据库中执行多跳路径搜索，将路径上的节点作为上下文。这对于需要跨文档关联推理的场景（比如"谁在A公司认识B并介绍给了C？"）特别有效。

Textractor 管道负责内容提取。项目支持从本地文件目录或URL中自动提取文本内容，支持 PDF、Word、HTML 等多种格式。这一步是数据入库的前置工作：

self.textractor = Textractor()
sections = self.textractor(inputs)

LLM 默认配置。代码默认使用 Qwen/Qwen3-4B-Instruct-2507 作为大语言模型，用户可以通过环境变量 LLM 切换到任意支持 OpenAI 兼容接口的模型（如 GPT-4、Claude、Llama 等）。这保证了架构的灵活性，不绑定特定供应商。

部署方式

项目提供两种快速部署路径：

Docker 部署（推荐）：项目根目录包含一个单阶段 Dockerfile，基于 neuml/txtai-cpu 镜像构建。官方镜像已经预装了 txtai 及所有依赖项，用户只需：

git clone https://github.com/neuml/rag.git
cd rag
docker run -d --gpus=all -it -p 8501:8501 neuml/rag

启动后访问 http://localhost:8501 即可看到 Streamlit Web UI。GPU 加速需要配置 --gpus=all 并确保 NVIDIA Docker 运行时可用。

本地 Python 环境：如果不想用 Docker，也可以手动安装依赖：

git clone https://github.com/neuml/rag.git
cd rag
pip install -r requirements.txt
streamlit run rag.py

requirements.txt 依赖项精简为三个包：matplotlib（图谱可视化）、streamlit（Web框架）、txtai[graph,pipeline-data,pipeline-llm]（核心框架，含图谱、LLM管道和数据处理扩展）。

配置参数：通过环境变量控制核心行为：

• LLM：指定大模型（默认 Qwen/Qwen3-4B）
• EMBEDDINGS：指定向量模型或预索引路径（默认 neuml/txtai-wikipedia-slim，一个基于维基百科预构建的轻量索引）
• DATA：本地数据目录路径，有此参数时自动索引该目录
• CONTEXT：传给LLM的上下文文档数量（默认10）

局限与风险

使用前需要了解几个限制：

GPU 几乎是必需的。虽然 CPU 模式下 txtai 可以运行，但向量搜索和 LLM 推理在无 GPU 环境下会非常缓慢。默认的 e5-large 模型约 560M 参数，Qwen3-4B 约 4B 参数，没有 CUDA 加速基本无法流畅使用。

没有 Docker Compose 配置。项目没有提供 docker-compose.yml 文件，持久化数据（上传的文档、生成的向量索引）需要在运行时挂载卷。此外也没有 Kubernetes 部署清单，对 k8s 环境不友好。

向量模型固定。Embedding 模型默认使用 e5-large，这是一个中等规模的模型，在某些垂直领域的召回效果可能不如 fine-tuning 后的专业模型。切换模型需要修改代码。

行业意义

RAG 是当前大模型落地最成熟的技术路径之一。本项目的价值在于将 txtai 框架的 RAG 能力以可视化应用的形式呈现，降低了技术门槛。同时其独特的 Graph RAG 实现，展示了将向量检索与知识图谱结合的前沿方向，这在需要复杂多跳推理的场景（如金融风控、法律分析、科研综述）中具有重要参考价值。

作为 neuml/txtai 生态的一部分，它与该作者的其他项目（paper-qa 论文问答、txtai 核心框架）形成互补，共同构成一个完整的语义搜索+LLM应用工具链。对于希望快速搭建本地 RAG 系统的开发者，这是一个值得研究的参考实现。