1. 项目概述为你的AI助手打造一个私有的、本地的知识大脑如果你正在使用Claude、Cursor或者本地运行的Ollama模型有没有想过为什么它们不能像ChatGPT那样“记住”你的个人文档、公司资料或者研究论文答案很简单它们缺少一个专属的、可检索的知识库。这就是RAG检索增强生成技术要解决的问题但传统的RAG方案要么需要将你的敏感数据上传到云端API要么配置过程繁琐得让人望而却步。今天要聊的这个项目——mcp-rag-server——完美地解决了这两个痛点。它是一个基于MCP模型上下文协议的服务器核心目标就一个让你手头的任何AI助手瞬间拥有一个基于你本地文档的、私密的、开箱即用的知识库和联网搜索能力。你只需要把文档扔进一个文件夹启动服务器你的AI就变成了你专属领域的专家。最硬核的一点是从文档解析、文本切片到向量嵌入整个过程都在你的机器上完成你的数据从未离开过你的硬盘。我花了几天时间深度把玩了这个项目它给我的感觉是“优雅的务实”。整个核心逻辑就封装在两个Python文件里加起来不到700行代码但实现了一个从文档加载、向量化存储到智能检索的完整闭环。对于开发者、研究团队或者小公司来说这几乎是一个零门槛的私有知识库解决方案。下面我就带你从里到外拆解一遍看看它是如何工作的以及你该如何用它来武装你的AI工作流。2. 核心设计思路为什么是“MCP服务器” “本地RAG”在深入代码之前我们得先搞清楚两个关键概念MCP和本地RAG。理解了它们你就能明白这个项目的设计哲学和独特价值。2.1 MCP让AI助手拥有“可插拔”的工具能力MCP全称Model Context Protocol你可以把它想象成AI世界的“USB协议”。在MCP出现之前如果你想给Claude、Cursor这类AI应用增加新功能比如查数据库、控制智能家居往往需要等待应用官方开发支持或者进行复杂的插件开发集成。MCP定义了一套标准允许外部服务器以“工具”的形式向AI客户端提供服务。mcp-rag-server就是一个标准的MCP服务器。它启动后会通过标准输入输出stdio与AI客户端如Claude Desktop通信并宣告“嗨我这儿有三个工具可用knowledge_base_search搜你的本地文档、web_search联网搜索和ingest_document实时添加新文档。” 客户端识别到这些工具后用户就可以在对话中直接使用了。这种设计带来了巨大的灵活性工具服务器和AI客户端完全解耦。你可以用Python写一个工具服务器然后被Claude、Cursor、Continue.dev等多种客户端同时使用无需为每个客户端单独开发。2.2 彻底的本地化隐私与可控性的终极选择RAG的核心是将文档转化为向量一串数字然后通过计算向量间的相似度来找到相关内容。绝大多数方案会调用OpenAI或Cohere的云端API来生成向量这意味着你的每一份文档都需要上传到别人的服务器。对于内部技术文档、合同、未公开的研究资料来说这是不可接受的风险。mcp-rag-server选择了另一条路完全本地化的向量嵌入。它使用了nomic-ai/nomic-embed-text-v1.5这个开源模型。你第一次运行时会从Hugging Face下载这个约550MB的模型文件之后所有嵌入计算都在本地完成。这意味着绝对隐私你的数据生命周期完全在你的设备上。离线可用一旦模型下载完成知识库搜索功能无需网络。零成本没有按次调用的API费用。这种选择也带来了技术上的挑战比如需要管理本地模型文件、确保嵌入速度等但项目通过sentence-transformers库很好地封装了这些细节对用户完全透明。2.3 双工具模式与智能路由模拟人类的“先内后外”查询逻辑这个项目设计了一个非常巧妙的“双工具模式”knowledge_base_search内部知识库和web_search外部网络。这不仅仅是提供了两个功能更是设计了一种智能的查询路由逻辑。想象一下当你被问到一个专业问题时你会先回想自己掌握的知识内部记忆如果找不到或不确定才会去翻书或上网查外部搜索。这个服务器通过MCP协议向AI客户端发送“指令”建议它遵循同样的流程先搜索本地知识库。如果知识库返回的结果相关性分数低于预设的阈值默认0.66服务器会明确返回“未找到相关信息”。AI客户端尤其是像Claude这样推理能力强的模型能理解这个信号并自动切换到web_search工具去联网查找。这个设计对于本地大语言模型如Ollama来说价值巨大。因为本地LLM本身没有任何外部工具能力既不能读文件也不能上网。通过连接mcp-rag-server一个本地模型瞬间就获得了“私有记忆”和“联网眼睛”两大核心能力实用性呈指数级提升。3. 从零到一的部署与配置实战理论讲完了我们动手把它跑起来。整个过程非常顺畅体现了“零仪式感”设计的理念。3.1 环境准备与项目初始化首先确保你的环境有Python 3.10或更高版本。我推荐使用conda或venv创建独立的虚拟环境避免依赖冲突。# 1. 克隆项目代码 git clone https://github.com/agarwalvishal/mcp-rag-server.git cd mcp-rag-server # 2. 创建并激活虚拟环境以Linux/macOS为例 python3 -m venv venv source venv/bin/activate # Windows用户请使用venv\Scripts\activate # 3. 安装依赖 pip install -r requirements.txt注意requirements.txt里包含了几个关键依赖sentence-transformers用于本地嵌入模型、qdrant-client向量数据库、pymupdf4llmPDF解析、mcpMCP协议库等。第一次安装可能需要几分钟取决于你的网络。3.2 添加你的第一批文档项目根目录下有一个data/文件夹。这就是你的知识库仓库。服务器启动时会自动扫描这个文件夹处理里面的所有支持格式的文档。项目自带了一些示例文档一个虚构初创公司的技术文档非常适合用来做首次测试。# 查看示例文档 ls data/ # 你可能看到adr-auth-middleware.md, api-reference.md, onboarding-guide.md 等 # 添加你自己的文档直接复制进去即可 cp /path/to/your/document.pdf ./data/ cp /path/to/your/notes.md ./data/支持的文件格式有三种Markdown (.md)支持最好能利用#标题进行语义化分块。纯文本 (.txt)按段落分块。PDF (.pdf)通过pymupdf4llm解析能识别字体大小层级作为标题并保留页码信息。一个重要的实操细节服务器只在启动时一次性加载data/目录下的所有文档。如果你在服务器运行期间向data/添加新文件这些文件不会被自动索引。你需要要么重启服务器要么使用ingest_document工具实时添加。对于需要频繁更新的知识库建议将“添加文件到data/目录”作为标准流程并配合定时重启或使用ingest_document工具。3.3 连接到你常用的AI客户端这是让工具生效的关键一步。你需要告诉你的AI客户端“去找这个MCP服务器用它提供的工具。” 配置方式因客户端而异。对于Claude Desktop用户macOS找到配置文件~/Library/Application Support/Claude/claude_desktop_config.json用文本编辑器打开添加mcpServers配置节。关键点在于command和args的路径必须是绝对路径。{ mcpServers: { rag-knowledge-base: { command: /Users/yourname/path/to/mcp-rag-server/venv/bin/python, args: [/Users/yourname/path/to/mcp-rag-server/mcp_server.py], env: { FIRECRAWL_API_KEY: fc-xxxxxx // 如果需要联网搜索在此填入Firecrawl的API密钥 } } } }保存文件完全退出并重启Claude Desktop。重启后你会在输入框上方看到新的工具图标或者直接在对话中尝试让Claude搜索你的知识库。对于Cursor/VS Code用户在你的项目根目录下创建或编辑文件.cursor/mcp.json加入类似的配置{ mcpServers: { rag-knowledge-base: { command: /absolute/path/to/mcp-rag-server/venv/bin/python, args: [/absolute/path/to/mcp-rag-server/mcp_server.py] } } }重启Cursor或VS Code。之后在编辑器的AI对话中你就可以使用知识库搜索功能了。对于本地LLM用户Ollama Continue.dev 这是最能体现本项目价值的场景。假设你用Ollama在本地运行llama3.1模型并通过Continue.dev插件在VS Code里使用它。编辑Continue的配置文件~/.continue/config.json在models配置好Ollama后添加mcpServers部分{ models: [ { title: Ollama Llama3.1, provider: ollama, model: llama3.1 } ], mcpServers: [ { name: rag-knowledge-base, command: /absolute/path/to/mcp-rag-server/venv/bin/python, args: [/absolute/path/to/mcp-rag-server/mcp_server.py] } ] }配置完成后你的本地Llama模型就奇迹般地获得了搜索本地文档和联网如果配置了API KEY的能力。重要提示为了让AI客户端更“听话”地优先使用知识库工具强烈建议在客户端的自定义指令Claude Desktop的“Project Instructions” Cursor的.cursorrules文件中加入一句“在回答问题时请优先使用‘rag-knowledge-base’工具搜索我的知识库如果知识库中没有找到相关信息再考虑使用其他方法或进行网络搜索。” 这能更好地引导AI遵循设计好的查询路由逻辑。3.4 首次运行与模型下载当你第一次运行服务器无论是通过客户端连接触发还是直接命令行运行python mcp_server.py会看到类似下面的输出INFO:root:Loading documents from ./data... INFO:sentence_transformers.SentenceTransformer:Load pretrained SentenceTransformer: nomic-ai/nomic-embed-text-v1.5 INFO:sentence_transformers.SentenceTransformer:Did not find folder nomic-ai/nomic-embed-text-v1.5 locally. Downloading from Hugging Face hub. Downloading (…)lve/main/config.json: 100%|████| 571/571 [00:0000:00, 1.70MB/s] Downloading (…)nce_bert_config.json: 100%|████| 53.0/53.0 [00:0000:00, 238kB/s] ... INFO:root:Loaded 5 documents, split into 42 chunks. INFO:root:Connected to Qdrant in local mode. INFO:root:Server started. Tools: knowledge_base_search, web_search, ingest_document这个过程会下载Nomic嵌入模型约550MB到~/.cache/huggingface/目录下并完成所有文档的解析、分块、向量化和索引。之后再次启动就很快了因为模型已经缓存。4. 核心组件深度解析文档处理与向量检索理解了整体流程我们深入到两个核心文件mcp_server.py和knowledge_base.py中看看魔法是如何发生的。4.1 文档加载与智能分块策略在knowledge_base.py的load_documents函数中项目对不同格式的文件采用了不同的解析器Loader。但比解析更关键的是分块Chunking策略。糟糕的分块会把完整的句子或思路切断严重影响检索质量。这个项目没有采用简单的按固定字符数切割而是实现了基于段落边界的分块。核心逻辑是先按双换行符\n\n分割成自然段落然后以chunk_size默认500字符为目标在尽量不打断段落的前提下合并小段落形成语义相对完整的块。如果单个段落就超过了chunk_size才会不得已按字符数切割。chunk_overlap默认50字符确保了块与块之间有一定的上下文重叠避免信息在边界丢失。# 简化版的分块逻辑示意 def split_text(text, chunk_size500, chunk_overlap50): paragraphs text.split(\n\n) chunks [] current_chunk for para in paragraphs: if len(current_chunk) len(para) chunk_size: current_chunk para \n\n else: if current_chunk: chunks.append(current_chunk.strip()) # 处理超长段落 if len(para) chunk_size: # 按字符切割并添加重叠 start 0 while start len(para): end start chunk_size chunk para[start:end] chunks.append(chunk) start end - chunk_overlap current_chunk else: current_chunk para \n\n if current_chunk: chunks.append(current_chunk.strip()) return chunks对于Markdown和PDF项目还会尝试提取标题结构并将标题信息作为元数据Metadata附加到每个块上。这样在返回搜索结果时不仅能给出内容还能告诉你“这个信息出自《API参考文档》的‘速率限制’章节”极大提升了结果的可追溯性和可信度。4.2 本地向量化与Nomic v1.5模型的选择向量化的核心在KnowledgeBase类的_get_embedding方法中。它调用sentence_transformers库加载nomic-ai/nomic-embed-text-v1.5模型。为什么是Nomic v1.5这是一个经过深思熟虑的选择非对称编码这是最关键的特性。大多数嵌入模型对文档和查询使用相同的编码方式。但Nomic v1.5引入了任务前缀。为文档生成向量时会在文本前加上search_document:前缀为查询生成向量时则加上search_query:前缀。模型针对这两种不同的任务进行了优化使得“查询向量”和“文档向量”在向量空间中的匹配更精准显著提升了检索质量。强大的基准性能在MTEB大规模文本嵌入基准等公开评测中Nomic v1.5表现 consistently strong尤其在检索任务上。适中的尺寸与速度768维的向量在精度、内存占用和计算速度之间取得了很好的平衡。550MB的模型大小在现代开发机上运行推理毫无压力。嵌入过程完全在本地进行from sentence_transformers import SentenceTransformer model SentenceTransformer(nomic-ai/nomic-embed-text-v1.5) # 为文档块生成向量 doc_embedding model.encode(search_document: chunk_text) # 为查询生成向量 query_embedding model.encode(search_query: user_question)这种设计确保了从文本到向量的整个转换流程你的数据都不会离开本地环境。4.3 Qdrant向量数据库灵活的可扩展存储生成的向量需要被存储和高效检索。项目选择了Qdrant作为向量数据库。Qdrant的一个巨大优势是它提供了统一的API但支持多种部署模式这让mcp-rag-server可以适应从个人试用到大团队协作的不同场景。local模式默认Qdrant作为一个嵌入式库运行数据持久化在本地目录默认./qdrant_data/中。无需安装Docker或单独的服务开箱即用数据在重启后依然保留。这是绝大多数个人用户的理想选择。memory模式所有数据存储在内存中进程退出即消失。非常适合快速测试、CI/CD流水线或者当你需要完全干净的环境时。server模式连接到一个独立运行的Qdrant服务器通常通过Docker部署。这种模式支持多客户端同时连接和查询适合团队共享知识库的场景。你可以先用local模式验证数据量大了再无缝迁移到server模式。在knowledge_base.py的初始化中根据配置的模式创建Qdrant客户端if qdrant_mode memory: client QdrantClient(location:memory:) elif qdrant_mode local: client QdrantClient(pathqdrant_local_path) elif qdrant_mode server: client QdrantClient(urlqdrant_url)这种抽象使得上层的搜索、插入代码完全不用关心底层存储是内存、文件还是远程服务。4.4 确定性ID与幂等操作避免重复数据的智慧在向量数据库中每个向量块都需要一个唯一ID。一个常见的坑是每次重启服务器重新索引文档即使文档内容没变也会生成全新的随机ID导致数据库中堆积大量重复数据。mcp-rag-server通过UUID5基于名称的UUID巧妙地解决了这个问题。UUID5通过对一个命名空间和一个名称进行哈希来生成UUID。在这里命名空间是固定的名称则由“文档文件路径块内容”的哈希值构成。这意味着同一份文档的同一个块无论索引多少次其ID永远相同幂等性。重启服务器时新生成的块ID会和数据库中已有的ID匹配Qdrant的upsert操作会更新已有记录而非创建重复项。你修改了文档内容对应的块ID就会改变从而实现增量的更新。这个细节体现了工程上的成熟思考确保了系统的稳定性和数据的一致性。5. 搜索流程与智能路由的工程实现当你在AI客户端提问时整个调用链是如何工作的我们拆解一下knowledge_base_search这个核心工具。5.1 语义搜索的执行链路查询向量化你的问题如“我们的API速率限制是多少”被加上search_query:前缀送入Nomic模型生成一个768维的查询向量。向量检索在Qdrant中使用余弦相似度Cosine Similarity作为度量标准查找与查询向量最相似的K个文档块K由search_top_k配置默认3。相关性过滤计算出的相似度分数在0到1之间。项目设置了一个search_score_threshold默认0.66。只有分数高于此阈值的块才会被返回。这个阈值不是随便定的而是作者通过分析相关查询和不相关查询在样本文档上的分数分布后选取的一个能较好区分两者的分界点。结果格式化返回的每个结果块会附带丰富的元数据源文件标题、所在的章节标题如果解析到、PDF页码、以及最重要的——相关性分数。这些信息一方面帮助AI模型更好地理解和引用结果另一方面也让你作为用户能追溯到原始出处。5.2 阈值与智能路由的配合search_score_threshold0.66这个值扮演着“守门员”的角色。它的核心作用不是追求绝对精确而是提供清晰的决策信号。如果用户问“我们的API速率限制是多少”系统在技术文档中找到高度匹配的块分数可能是0.78高于阈值结果返回。如果用户问“怎么煮意大利面”系统在所有技术文档中搜索最相似的块分数可能只有0.55低于阈值。此时knowledge_base_search工具会返回一个明确的消息“I couldnt find a relevant answer in the knowledge base for this query.”这个“未找到”的消息至关重要。通过MCP协议AI客户端特别是像Claude这样指令遵循能力强的模型能识别出这是一个“知识库无法回答”的信号。结合服务器在初始化时发送的“建议优先使用知识库”的指令AI就会自然地触发下一步调用web_search工具去互联网上寻找答案。这就实现了一个完全基于模型推理的、柔性的智能路由而不是写死的if-else逻辑。5.3 联网搜索的集成web_search工具的实现相对直接它是对Firecrawl API的一个封装。Firecrawl是一个将网页内容转换为结构化数据的服务。你需要在其官网注册并获取一个API密钥然后通过环境变量FIRECRAWL_API_KEY提供给服务器。当AI决定进行联网搜索时它会调用此工具。服务器将查询转发给Firecrawl获取搜索结果摘要和链接再返回给AI进行整合回答。这为本地LLM或需要最新信息的场景提供了强大的补充。6. 配置详解与高级调优指南项目的所有行为都通过config.yaml文件控制并且支持环境变量和命令行参数覆盖灵活性很高。6.1 核心配置参数解析# config.yaml 示例 data_dir: ./data # 文档目录。可以放绝对路径。 file_types: [md, txt, pdf] # 支持的文件后缀。注意不带点。 qdrant_mode: local # 存储模式local, memory, server qdrant_local_path: ./qdrant_data # local模式下的数据存储路径 qdrant_url: http://localhost:6333 # server模式下的Qdrant服务地址 collection_name: knowledge_base # Qdrant中的集合名类似数据库表名 embedding_model: nomic-ai/nomic-embed-text-v1.5 # 嵌入模型。可替换为其他sentence-transformers模型或本地路径。 chunk_size: 500 # 目标块大小字符数。影响检索粒度。 chunk_overlap: 50 # 块间重叠字符数。避免上下文断裂。 search_top_k: 3 # 每次搜索返回的最相关结果数量。 search_score_threshold: 0.66 # 相关性分数阈值。高于此值的结果才返回。 log_level: INFO # 日志级别DEBUG, INFO, WARNING, ERROR优先级顺序从高到低命令行参数如python mcp_server.py --data-dir /my/docs --chunk-size 800环境变量前缀MCPRAG_如MCPRAG_CHUNK_SIZE800config.yaml文件中的设置代码中的默认值6.2 关键参数调优建议根据你的文档类型和需求调整以下参数可以显著提升效果chunk_size和chunk_overlap默认值500, 50对于大多数技术文档、维基页面是合适的。如果你的文档段落很长如法律条文、研究论文的连续论述可以考虑增大chunk_size到800-1000以确保一个完整论点的完整性。如果你的文档信息点非常密集、独立如QA对、代码片段可以减小chunk_size到300并适当减小overlap让检索更精准。黄金法则调整后用一些典型问题测试观察返回的块是否包含了回答该问题所需的完整上下文又不会掺杂太多无关信息。search_score_threshold默认0.66是一个保守的起点旨在减少误报返回不相关结果。如果你发现很多相关查询也返回“未找到”可以尝试逐步调低阈值比如0.6、0.55。观察日志中相关查询的分数分布。如果你发现返回了太多无关结果干扰了AI的判断则应该提高阈值比如0.7。调试方法在启动服务器时加上--log-level DEBUG然后进行搜索。日志会输出所有候选块的分数帮助你确定合理的阈值区间。search_top_k默认3意味着每次搜索返回最相关的3个块。对于大多数事实性问答这足够了。如果你的问题可能需要从文档多个部分综合信息例如“总结我们项目目前面临的主要挑战”可以增加到5或7给AI模型提供更全面的上下文。注意增加top_k会略微增加检索时间和AI处理上下文的负担。6.3 存储模式的选择与迁移从memory或local迁移到server模式首先使用Docker启动一个Qdrant服务器docker run -p 6333:6333 qdrant/qdrant然后以server模式启动你的mcp-rag-server并指向该地址python mcp_server.py --qdrant-mode server --qdrant-url http://localhost:6333服务器会自动在新的Qdrant实例中创建集合并索引文档。注意local模式下的数据文件./qdrant_data/无法直接用于server模式。你需要重新索引文档。团队协作场景使用server模式让Qdrant在服务器上运行。团队每个成员的AI客户端配置都可以指向同一个MCP服务器需要将mcp_server.py部署为常驻服务或者各自运行MCP服务器但连接同一个Qdrant后端。后者更灵活但需要确保文档目录同步。7. 常见问题排查与实战经验分享在实际部署和使用中你可能会遇到一些问题。这里我总结了一些常见坑点和解决思路。7.1 连接与配置问题问题AI客户端如Claude Desktop启动后看不到新工具。检查1配置文件路径和格式。确保claude_desktop_config.json或.cursor/mcp.json文件在正确的位置并且是合法的JSON格式可以用在线JSON校验器检查。一个多余的逗号就会导致整个配置被忽略。检查2Python解释器路径。command字段必须是虚拟环境中Python的绝对路径。在终端中进入你的项目目录激活虚拟环境然后执行which pythonLinux/macOS或where pythonWindows来获取绝对路径。检查3脚本路径。args中的mcp_server.py路径也必须是绝对路径。检查4重启客户端。修改MCP配置后必须完全退出并重启AI客户端而不是仅仅刷新页面。检查5查看客户端日志。Claude Desktop通常有日志文件在配置文件夹的Logs子目录内查看其中是否有MCP服务器启动失败的错误信息。问题服务器启动失败提示端口被占用或Qdrant连接错误。如果是local模式检查qdrant_local_path目录是否被其他进程锁定或者尝试换个路径。如果是server模式检查qdrant_url指定的Qdrant服务是否真的在运行。可以用curl http://localhost:6333测试。7.2 搜索效果不理想问题搜索返回的结果似乎不相关。确认文档已被正确加载查看服务器启动日志确认你的文档文件被列出并显示了正确的分块数量。如果文件未被识别检查文件后缀名是否在file_types列表中以及文件编码是否为UTF-8。调整分块策略默认的按段落分块可能不适合你的文档结构。例如如果你的文档是每行一个独立条目的列表按\n\n分块可能失效。你可以考虑修改knowledge_base.py中的split_text函数或者预处理你的文档格式。检查嵌入模型虽然Nomic v1.5是通用性很强的模型但对于某些非常专业的领域如生物医学、法律术语领域特定的嵌入模型可能效果更好。你可以在config.yaml中将embedding_model替换为其他sentence-transformers支持的模型比如BAAI/bge-large-en-v1.5。注意更换模型后需要删除原有的Qdrant数据./qdrant_data/目录或清空集合重新启动服务器以重建索引。问题AI总是忽略知识库直接用自己的知识或去联网搜索。强化客户端指令这是最常见的原因。确保你已经在AI客户端的自定义指令Project Instructions,.cursorrules等中明确写入了“优先使用rag-knowledge-base工具”的提示。指令要具体、强硬。检查阈值是否过高如果search_score_threshold设得太高可能导致很多查询都返回“未找到”AI习惯了这一点后可能会跳过知识库步骤。尝试适当调低阈值或使用DEBUG日志查看典型查询的分数。验证工具是否被正确调用在Claude Desktop中当你提问时观察输入框上方是否有工具被调用的动画或图标。也可以让AI“展示一下你的工具”看它是否列出了knowledge_base_search。7.3 性能与资源问题问题首次启动或添加大量文档时速度很慢。嵌入计算是主要瓶颈。Nomic v1.5模型在CPU上编码速度尚可但文档量很大如数百个PDF时索引过程会耗时较长。这是本地隐私保护的代价。可以考虑分批添加文档或者使用ingest_document工具在需要时动态添加。确保模型已缓存第一次下载模型后后续启动不应再出现下载日志。如果每次启动都下载检查~/.cache/huggingface/目录的写入权限。问题内存占用过高。主要内存占用来自1) 加载的嵌入模型 (~550MB) 2) Qdrant向量索引。对于非常大的文档集数万块local模式的Qdrant可能会占用较多内存。如果遇到问题可以考虑切换到server模式将Qdrant部署到拥有更多内存的服务器上。7.4 进阶技巧与扩展思路动态文档更新虽然服务器启动后不会自动监听data/目录但你可以利用ingest_document工具构建一个简单的自动化流程。例如写一个脚本监控某个共享文件夹当有新文档时调用该工具的APIMCP协议是JSON-RPC over stdio理论上可以编程调用将其添加到当前会话的知识库中。混合搜索策略当前是纯语义向量搜索。对于某些包含精确代码、版本号或ID的查询关键词匹配可能更有效。你可以扩展knowledge_base.py在语义搜索结果的基础上再用正则或简单关键词过滤进行重排序Rerank提升精确匹配的优先级。元数据过滤Qdrant支持在搜索时按元数据如文件类型、创建日期、作者进行过滤。你可以修改文档加载逻辑提取更多元数据如从PDF的XMP信息或从文件名中解析出项目名、版本号并将其存入Qdrant。然后扩展knowledge_base_search工具增加可选的过滤参数实现“搜索第三季度关于‘认证’的PDF报告”这类复杂查询。多知识库支持目前只有一个knowledge_base集合。你可以修改配置和代码支持多个集合如project_a_docs,company_policies并让工具允许用户指定搜索哪个集合实现知识库的逻辑隔离。这个项目的魅力在于其简洁和可扩展性。两个核心文件构成了一个坚实可用的基础而几乎每一个组件——加载器、分块器、嵌入模型、向量数据库、搜索逻辑——都可以被替换或增强以适应你特定的需求。它不是一个黑盒SaaS而是一个清晰的蓝图告诉你一个注重隐私、开箱即用的本地RAG系统应该如何构建。