AI导哈

多代理RAG检索系统

一个本地优先的多代理RAG检索系统，结合Ollama本地LLM运行和Qdrant向量数据库，支持动态路由上下文和模块化组件交换。

  • by adrianzevenster
  • Python
  • 本地部署
  • 更新于
在 GitHub 查看 adrianzevenster/multi-agent-mcp-server

使用说明

多代理RAG MCP

多代理RAG MCP是一种 本地第一代理+RAG堆栈 围绕：

  • 奥拉玛 用于在本地运行LLM
  • Qdrant 作为用于检索的矢量数据库
  • 一个轻量级的API/UI层，用于测试、迭代和发布代理驱动的检索（而不仅仅是“提示之上的UI”）

此回购侧重于 代理驱动的检索，动态路由上下文 并使系统保持足够的模块化，以便在不重写整个应用程序的情况下交换模型、嵌入、分块和检索策略。

这个项目做什么

  • 将文档摄取到 向量索引 （Qdrant）
  • 跑动 语义搜索+检索 对于用户提示
  • 构建a 固定上下文块 （RAG背景）
  • 将提示+检索到的上下文发送到 Ollama托管模型
  • 返回一个偏向的答案 忠诚 （从检索到的来源回答）

高层体系结构

User/UI
|
v
API (chat endpoint)
|
+--> Retriever (Qdrant) ----> Top-k chunks
|
+--> Prompt builder --------> Grounded context prompt
|
+--> LLM runtime (Ollama) --> Final response

关键组件

1） Qdrant（矢量数据库）

Qdrant商店：

  • 嵌入
  • 大块文本
  • 元数据（来源、文档名称、页面/部分、时间戳、标签）

用于：

  • Top-k最近邻检索
  • 按元数据过滤/路由（启用时）

2） Ollama（LLM运行时）

Ollama提供：

  • 本地模型服务
  • 可预测的延迟和成本
  • 跨模型的简单实验（例如，llama3.x、mistral等）

3） RAG格式化工具

有一个小的格式化层来构建模型使用的一致的“检索上下文”块。

检索是如何建立的

该系统的设计使模型：

  • 答案 首先从检索到的块中
  • 避免在缺少上下文时发明细节
  • 在适当的时候可以明确地说“在检索到的上下文中找不到”

这就是“RAG作为UI功能”与 检索作为一级系统行为.

在本地运行

先决条件

  • Docker+Docker组合
  • Ollama已安装（或在容器中运行）
  • Python 3.10+（如果在Docker之外本地运行服务）

启动Qdrant

如果使用Docker：

docker run -p 6333:6333 -p 6334:6334 qdrant/qdrant

启动Ollama

如果在本地运行：

ollama serve

拉一个模型：

ollama pull llama3.1

运行应用程序

根据您的repo的连接方式，其中之一将适用：

python app.py

或者（如果是FastAPI/Uvicorn）：

uvicorn app:app --reload --host 0.0.0.0 --port 8000

环境变量

创建一个 .env 本地配置文件。典型变量：

# Ollama
OLLAMA_BASE_URL=http://localhost:11434
OLLAMA_MODEL=llama3.1

# Qdrant
QDRANT_URL=http://localhost:6333
QDRANT_COLLECTION=Multi Agent RAG MCP

# Retrieval
TOP_K=8
MIN_SCORE=0.2

# Chunking / Embeddings (if applicable)
EMBEDDING_MODEL=...
CHUNK_SIZE=...
CHUNK_OVERLAP=...

将秘密和本地路径从git中删除。使用 .gitignore 为了 .env.

摄入管道（典型流量）

  1. 从PDF/docs中提取文本
  2. 分成语义单位
  3. 嵌入每个块
  4. 使用元数据插入Qdrant

Qdrant有效载荷中存储的示例结构：

{
  "text": "chunk content...",
  "doc_id": "medical_ai.pdf",
  "source": "local",
  "page": 12,
  "section": "intro",
  "created_at": "2025-12-23T10:00:00Z"
}

查询管道（典型流程）

  1. 用户提示到达 /chat
  2. 计算提示的嵌入（或使用Ollama嵌入模型（如果已配置））
  3. 查询问题： top_k
  4. 构建RAG上下文块
  5. 呼叫Ollama /api/chat
  6. 返回响应+可选检索源

是什么让这个“代理”（不仅仅是RAG）

  • 检索不是一个固定的步骤，它可以被路由：
    • 每个意图的不同收藏
    • 每种查询类型的不同top-k
    • 当用户指定域时，元数据会进行筛选
  • “代理人”可以决定：
    • 何时检索vs直接回答
    • 何时要求跟进（如果缺少上下文）
    • 如何支持索赔与对冲

项目目标

  • 本地优先，成本可控的RAG堆栈
  • 模块化组件（交换模型、嵌入、分块器、检索器）
  • 接地输出，幻觉风险低
  • 准备稍后扩展到多代理路由+评估循环

故障排除

Ollama港口已在使用中

如果你看到： bind: address already in use

检查端口的使用情况：

lsof -i :11434

停止进程或更改端口。

Qdrant连接问题

确认Qdrant可用：

curl http://localhost:6333/collections

下一步改进（实用路线图）

  • 添加基于元数据的路由（按文档/类型筛选）
  • 在回复中添加引用（源块ID）
  • 添加块级重新分级
  • 添加eval工具（忠诚度+相关性）
  • 添加Ollama的流媒体响应
  • 为每个域添加多集合索引

相关 MCP