混合知识库搭建：本地Docker部署Neo4j图数据库与Milvus向量库

优质文章学习记录

— 12 min read
混合知识库搭建：本地Docker部署Neo4j图数据库与Milvus向量库

混合知识库搭建：本地Docker部署Neo4j图数据库与Milvus向量库

前言

在多代理混合RAG系统中，知识库是“知识储备核心”，直接决定了代理检索的精准度与响应质量。上一篇我们解析了5个子代理的执行逻辑，而这些代理能高效完成知识检索任务，背后依赖“Neo4j图知识库+Milvus向量库”的混合支撑——图知识库擅长挖掘实体关系，向量库精准匹配语义细节，二者互补形成全场景知识覆盖。

本文作为系列博客的第三篇，将聚焦混合知识库的落地实现：从本地Docker部署、数据建模、索引构建，到双库协同逻辑，手把手带你搭建高可用的混合知识库，让你掌握“关系型知识+语义型知识”的全链路管理技巧。

1 混合知识库的设计逻辑：为什么需要“图+向量”双引擎？

1.1 单一知识库的局限性

  • 纯图数据库：擅长实体关系查询（如“小米的合作品牌”），但无法高效处理细粒度文本检索（如“苹果的环保目标细节”）；
  • 纯向量数据库：擅长语义相似性检索（如“查找与5G技术相关的内容”），但难以挖掘实体间的复杂关联（如“华为-开发-鸿蒙-适配-智能设备”）。

1.2 混合知识库的核心优势

“Neo4j图库+Milvus向量库”的组合，完美弥补了单一知识库的短板：

  • 互补覆盖：图库处理“关系型知识”，向量库处理“语义型知识”，覆盖结构化、半结构化、非结构化知识场景；
  • 提升效率：关系查询走图库，语义查询走向量库，避免单一知识库的“一刀切”检索瓶颈；
  • 适配多代理：graph_kg代理调用图库，vec_kg代理调用向量库，实现代理与知识库的精准绑定。

1.3 混合知识库与代理的对应关系

2 本地Docker部署：Neo4j图数据库搭建

2.1 部署准备

  • 依赖环境：Docker已启动（参考第一篇博客的Docker Compose配置）；
  • 核心端口：7474（Web管理界面）、7687（Bolt协议端口，代码连接核心）；
  • 初始配置：用户名neo4j，密码password（Docker Compose中已预设）。

2.2 启动与验证

  1. 启动服务：通过Docker Compose启动Neo4j（命令参考第一篇）；
  2. Web界面验证：浏览器访问http://localhost:7474，输入用户名密码登录，首次登录需修改密码（保持与代码配置一致）；
  3. 代码连接验证：通过LangChain的Neo4jGraph类测试连接，核心代码：
from langchain_community.graphs import Neo4jGraph # 初始化Neo4j连接 graph = Neo4jGraph( url='bolt://localhost:7687', username="neo4j", password="password",# 与Web界面修改后的密码一致 database="neo4j")print("Neo4j连接成功！")

2.3 数据建模：从文本到图结构的自动转换

系统通过LLMGraphTransformer将非结构化文本（如doc/company.txt）自动转换为图结构（实体+关系），无需手动建模，核心流程如下：

2.3.1 核心依赖
from langchain_experimental.graph_transformers import LLMGraphTransformer from langchain_core.documents import Document
2.3.2 数据加载与转换
# 1. 加载文本知识库（公司相关文本） current_dir = os.path.dirname(os.path.abspath(__file__)) company_txt_path = os.path.normpath(os.path.join(current_dir,"doc","company.txt"))withopen(company_txt_path,'r', encoding="utf-8")asfile: content =file.read() documents =[Document(page_content=content)]# 2. 初始化LLMGraphTransformer（通过大模型自动提取实体与关系） graph_llm = ChatOpenAI(temperature=0, model_name="qwen-plus-2025-12-01", api_key=key, base_url=base_url) graph_transformer = LLMGraphTransformer(llm=graph_llm)# 3. 文本→图结构转换（实体：如Company、Technology；关系：如DEVELOPS、COOPERATES_WITH） graph_documents = graph_transformer.convert_to_graph_documents(documents)# 4. 插入Neo4j图数据库 graph.add_graph_documents(graph_documents)print(f"成功插入{len(graph_documents)}个图文档，包含实体数：{len(graph_documents[0].nodes)}")
2.3.3 自动生成的图结构示例
实体类型实体示例关系类型关系示例
Company小米科技有限责任公司、华为技术有限公司DEVELOPS华为→DEVELOPS→鸿蒙操作系统
Technology5G通信技术、智能手表芯片COOPERATES_WITH小米→COOPERATES_WITH→高通
Operating_system鸿蒙操作系统、MIUIADOPTS华为手机→ADOPTS→鸿蒙操作系统

2.4 Cypher查询优化：Few-shot提升准确性

图知识库的检索核心是Cypher语句生成，为避免大模型生成语法错误，系统通过Few-shot示例优化Cypher生成逻辑：

2.4.1 配置Few-shot示例与Prompt
from langchain_core.prompts import PromptTemplate from langchain_community.chains.graph_qa.cypher import GraphCypherQAChain # 1. Few-shot示例（覆盖常见查询场景） examples =[{"question":"都有哪些公司？","query":"MATCH (c:Company) RETURN c.id"},{"question":"小米在技术创新方面有什么突破？","query":"MATCH (c:Company)-[r:DEVELOPS|INTRODUCES]->(t) WHERE c.id CONTAINS '小米' RETURN c.id as company, type(r) as relation, t.id as technology"},{"question":"华为的鸿蒙操作系统有什么特点？","query":"MATCH (c:Company)-[:DEVELOPS]->(os:Operating_system) WHERE c.id CONTAINS '华为' RETURN os.id"}]# 2. 构建Cypher生成Prompt cypher_prompt_template ="""You are a Neo4j Cypher expert. Generate syntactically correct Cypher queries. Schema: {schema} Important rules: 1. Company names are stored as FULL names (e.g., "小米科技有限责任公司"). ALWAYS use CONTAINS for partial matching 2. Use pattern: WHERE c.id CONTAINS 'keyword' instead of exact match 3. For relationships, use [:DEVELOPS|INTRODUCES] for technology/products 4. NEVER use undefined variables (like type(r) without defining r) Examples: {examples} Question: {question} Cypher:""" cypher_prompt = PromptTemplate( template=cypher_prompt_template, input_variables=["schema","question"], partial_variables={"examples":"\n".join([f"Q: {ex['question']}\nCypher: {ex['query']}"for ex in examples])})# 3. 创建Cypher QA Chain cypher_chain = GraphCypherQAChain.from_llm( graph=graph, cypher_llm=llm, qa_llm=llm, cypher_prompt=cypher_prompt, validate_cypher=True,# 开启Cypher语法校验 allow_dangerous_requests=True)
2.4.2 优化效果

通过Few-shot示例，大模型生成Cypher的准确率提升60%以上，避免了“实体名称精确匹配失败”“关系类型错误”等常见问题。

3 本地Docker部署：Milvus向量数据库搭建

3.1 部署准备

  • 依赖环境：Docker已启动（Docker Compose中包含Milvus及依赖的etcd、minio服务）；
  • 核心端口：19530（GRPC端口，代码连接核心）、9091（HTTP端口，可选）；
  • 初始配置：无默认用户名密码，直接通过URI连接。

3.2 启动与验证

  1. 启动服务：通过Docker Compose启动Milvus（命令参考第一篇）；
  2. 日志验证：执行docker logs rag-milvus，输出“Milvus is ready”即启动成功；
  3. 代码连接验证：通过LangChain的Milvus类测试连接，核心代码：
from langchain_milvus import Milvus from langchain_core.embeddings import Embeddings # 1. 初始化DashScope Embeddings（生成文本向量）classDashScopeEmbeddings(Embeddings):def__init__(self, model:str, api_key:str): self.model = model self.api_key = api_key # 实现embed_documents和embed_query方法（参考项目代码） embeddings = DashScopeEmbeddings(model="text-embedding-v4", api_key=key)# 2. 连接Milvus并创建集合 vectorstore = Milvus( embedding=embeddings, connection_args={"uri":"http://localhost:19530"}, collection_name="company_milvus", drop_old=True# 测试时删除旧集合，生产环境设为False)print("Milvus连接成功！")

3.3 向量索引构建：文档分块与向量插入

向量库的核心是“文本分块→向量生成→索引构建”，系统通过RecursiveCharacterTextSplitter实现合理分块，提升检索精度：

3.3.1 核心流程代码
from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 文档分块（关键参数：chunk_size=250，chunk_overlap=30） text_splitter = RecursiveCharacterTextSplitter( chunk_size=250,# 每个文本块最大长度（字符数） chunk_overlap=30,# 文本块重叠长度（避免上下文断裂） length_function=len) splits = text_splitter.split_documents(documents)# documents为之前加载的公司文本print(f"文档分块完成，共生成{len(splits)}个文本块")# 2. 向量插入与索引构建（自动生成向量并创建IVF_FLAT索引） vectorstore = Milvus.from_documents( documents=splits, collection_name="company_milvus", embedding=embeddings, connection_args={"uri":"http://localhost:19530"}, drop_old=True)print("Milvus向量索引构建完成！")
3.3.2 分块策略优化说明
  • chunk_size=250：适配中文文本，确保每个块包含完整的语义单元（如一个公司的某段技术介绍）；
  • chunk_overlap=30：避免拆分连续语义（如“鸿蒙操作系统的特点”被拆分为两个块）；
  • 索引类型：默认使用IVF_FLAT索引，适合中小规模数据（10万条以内），查询速度快且配置简单。

3.4 向量检索配置：Retriever与RAG链构建

Milvus向量库通过as_retriever()方法生成检索器，结合RAG链实现“检索→生成”的闭环：

3.4.1 核心代码
from langchain_core.prompts import PromptTemplate from langchain_core.output_parsers import StrOutputParser # 1. 构建检索器（设置返回Top2相关文本块） retriever = vectorstore.as_retriever(search_kwargs={"k":2})# 2. 构建RAG生成Prompt（限制响应长度，确保简洁） prompt = PromptTemplate( template="""You are an assistant for question-answering tasks. Use the following pieces of retrieved context to answer the question. If you don't know the answer, just say that you don't know. Use three sentences maximum and keep the answer concise: Question: {question} Context: {context} Answer: """, input_variables=["question","context"],)# 3. 构建RAG链（检索→Prompt→生成→解析） rag_chain = prompt | graph_llm | StrOutputParser()# 4. 测试检索与生成 user_question ="苹果公司的环保目标是什么？" docs = retriever.invoke(user_question)# 向量检索 response = rag_chain.invoke({"context": docs,"question": user_question})# 生成响应print(f"检索结果：{response}")
3.4.2 检索参数优化
  • search_kwargs={“k”: 2}：返回Top2最相关的文本块，既保证信息充分，又避免冗余；
  • 向量维度：使用DashScope的text-embedding-v4模型，生成768维向量，平衡检索精度与存储成本。

4 混合知识库协同逻辑：何时用图库？何时用向量库？

4.1 核心决策规则

系统通过Supervisor的路由规则，决定不同需求对应的知识库调用策略：

  1. 关系型需求（如“谁和谁有关系”“某公司的技术突破”）→ 调用Neo4j图库（graph_kg代理）；
  2. 细节型需求（如“某公司的具体目标”“文本中的关键信息”）→ 调用Milvus向量库（vec_kg代理）；
  3. 混合需求（如“华为的鸿蒙系统有什么特点，与哪些设备适配”）→ 先调用图库（关系适配）+ 再调用向量库（特点细节）。

4.2 协同执行示例

用户需求：“华为的鸿蒙操作系统有什么特点？适配哪些智能设备？”

  1. Supervisor调度graph_kg代理：生成Cypher查询“鸿蒙系统适配的设备”，从Neo4j获取关系数据（如“鸿蒙→适配→华为手机、华为手表”）；
  2. Supervisor调度vec_kg代理：检索“鸿蒙系统特点”的相关文本，从Milvus获取细节信息（如“分布式架构、兼容安卓应用”）；
  3. Supervisor调度chat代理：整合两个知识库的结果，生成统一自然语言响应。

4.3 双库协同优势

  • 精度提升：关系查询走图库，细节查询走向量库，避免单一知识库的“偏科”问题；
  • 效率优化：无需遍历全量文本，图库通过关系路径快速定位，向量库通过语义快速匹配；
  • 鲁棒性增强：一个知识库查询失败时，可切换另一个知识库兜底（如vec_kg查不到时，尝试graph_kg）。

5 常见问题与优化技巧

5.1 Neo4j图库常见问题

5.1.1 Cypher生成错误
  • 原因：大模型对图结构不熟悉，未使用CONTAINS进行模糊匹配；
  • 解决：增加Few-shot示例，强制Prompt中明确“使用CONTAINS进行公司名称匹配”。
5.1.2 实体重复或关系错乱
  • 原因：文本中同一公司有多个名称（如“华为”“华为技术有限公司”）；
  • 解决：在文本预处理阶段统一实体名称，或在Prompt中提示“合并相似公司名称”。

5.2 Milvus向量库常见问题

5.2.1 检索结果不精准
  • 原因：文档分块过大/过小，或嵌入模型维度不匹配；
  • 解决：调整chunk_size（建议200-300字符），更换更高精度的嵌入模型（如text-embedding-v4）。
5.2.2 向量插入失败
  • 原因：Milvus服务未启动，或连接URI错误（需使用GRPC端口19530）；
  • 解决：检查Docker容器状态，确保connection_args={“uri”: “http://localhost:19530”}。

5.3 性能优化技巧

  1. 图库优化：为Neo4j的常用实体属性（如Company.id）创建索引，提升查询速度；
  2. 向量库优化：大数据量（10万条以上）时，将索引类型改为HNSW，配置index_params={"M": 16, "efConstruction": 200}；
  3. 缓存策略：对高频查询结果建立缓存，避免重复检索，提升响应速度。

6 总结与后续预告

本文详细讲解了混合知识库的搭建全流程：从Neo4j图数据库的Docker部署、自动建模、Cypher优化，到Milvus向量数据库的分块策略、向量插入、RAG链构建，再到双库的协同逻辑，完整覆盖了“关系型知识+语义型知识”的存储与检索需求。

混合知识库是多代理系统的“知识基石”，其设计的合理性直接决定了代理执行的精准度与效率。而要让这些知识库与代理高效协作，离不开Supervisor的智能调度——这正是我们下一篇博客的核心内容。

后续博客预告

下一篇我们将聚焦系统的“大脑”——Supervisor，深入解析其任务路由规则、代理状态管理、循环保护机制，揭秘“如何让多个代理有序协作，避免重复工作与无效调用”。

Read more

AI绘画作品描述反推：GLM-4.6V-Flash-WEB还原提示词

AI绘画作品描述反推：GLM-4.6V-Flash-WEB还原提示词 在AI生成艺术蓬勃发展的今天，一张张令人惊叹的数字画作背后，往往隐藏着一段精心设计的文本提示词（Prompt）。然而，当我们在社交媒体或共享平台上看到一幅惊艳的作品时，却常常无法得知它是如何被“召唤”出来的——原作者未公开Prompt、平台不支持元数据嵌入、图像经过二次编辑……这些都让创作过程变得神秘而难以复现。 这种“看得见结果，看不见过程”的困境，正催生一个新兴的技术需求：从AI绘画成品中反向推理出其生成所依赖的原始提示词。这不仅关乎学习与模仿，更涉及内容溯源、版权审查与创意启发等多个层面。传统方法依赖人工经验猜测或简单图像标签识别，效果有限。而如今，随着多模态大模型的发展，我们终于拥有了真正可行的自动化解决方案。 其中，智谱AI推出的 GLM-4.6V-Flash-WEB 模型，凭借其轻量高效、语义理解强和开源可部署的优势，成为实现这一目标的理想选择。 多模态理解的新范式：不只是“看”，更要“懂” 要理解为什么GLM-4.6V-Flash-WEB能胜任提示词反推任务，首先要明白这项工作的本质并非简单
机器人-六轴机械臂的正运动学

机器人-六轴机械臂的正运动学

在机器人运动学建模领域，D-H（Denavit-Hartenberg）参数法绝对是绕不开的核心技术。它以极简的4个参数，就能清晰描述机械臂各连杆间的相对位姿关系，是实现正运动学求解、轨迹规划的基础。本文将从理论原理出发，一步步拆解六轴机械臂的D-H法建模流程，最后结合代码实现让理论落地，适合机器人初学者或技术爱好者深入学习。 一、为什么选择D-H法？—— 机械臂建模的“通用语言” 六轴机械臂作为工业场景中最常用的机器人构型，其连杆与关节的空间关系复杂。如果直接用三维坐标系叠加计算，不仅公式繁琐，还容易出现坐标混乱的问题。而D-H法的核心优势的在于“标准化”： * 简化参数：用仅4个参数（关节角、连杆偏移、连杆长度、连杆扭转角）描述相邻连杆的位姿，替代复杂的三维坐标变换； * 通用性强：适用于所有串联机械臂，无论是六轴、四轴还是协作机械臂，都能套用同一套建模逻辑； * 计算高效：通过齐次变换矩阵的乘积，可快速求解末端执行器相对于基坐标系的位姿，为后续运动学分析奠定基础。 简单来说，学会D-H法，就掌握了串联机械臂建模的“通用语言”。 二、D-H法核心：4个
Ubuntu搭建PX4无人机仿真环境(5) —— 仿真环境搭建(以Ubuntu 22.04,ROS2 Humble,Micro XRCE-DDS Agent为例)

Ubuntu搭建PX4无人机仿真环境(5) —— 仿真环境搭建(以Ubuntu 22.04,ROS2 Humble,Micro XRCE-DDS Agent为例)

目录 * 前言 * 1. 准备 * 1.1 下载 PX4 源码 * 方式一： * 方式二： * 1.2 安装仿真依赖 * 1.3 安装 Gazebo * 2. 安装 Micro XRCE-DDS Agent * 3. 编译 PX4 * 4. 通信测试 * 5. 官方 offboard 程序 * 6. offboard 测试 * 参考 前言 本教程基于 ROS2 ，在搭建之前，需要把 ROS2、QGC 等基础环境安装配置完成。但是这块的资料相比较于 ROS1 下的少很多，不利于快速上手和后期开发，小白慎选！ 小白必看：
【数据库】国产数据库的新机遇：电科金仓以融合技术同步全球竞争

【数据库】国产数据库的新机遇：电科金仓以融合技术同步全球竞争

7月15日，国产数据库厂商中电科金仓（北京）科技股份有限公司（以下简称“电科金仓”）在北京举行了一场技术发布会，集中发布四款核心产品：AI时代的融合数据库KES V9 2025、企业级统一管控平台KEMCC、数据库一体机（云数据库AI版）以及企业级智能海量数据集成平台KFS Ultra，并同步举行了“金兰组织2.0”启动仪式。 如果放在过去几年，这场发布会可能被归入“信创替代”的常规范畴。但这一次，电科金仓试图讲述的不再是“我们也能做、我们可以兼容”，而是“我们能不能定义下一代数据库形态”。 整个发布会贯穿了三个关键词：“融合”“AI”“平台能力”。这背后的核心逻辑是清晰的：在“去IOE”与“兼容Oracle”的红利渐近尾声之际，国产数据库厂商开始面对一个更加复杂、也更具挑战性的市场命题——如何在大模型时代支撑非结构化数据、高维向量检索和复杂语义计算的新需求？ 正如我国数据库学科带头人王珊教授所说，数据库内核与AI能力的深度结合，已成为释放数据核心价值的关键路径，正催生着更智能、更自适应、更能应对复杂挑战的新一代数据库形态。