Langchain-Chatchat结合Neo4j构建知识图谱问答系统

Langchain-Chatchat 结合 Neo4j 构建知识图谱问答系统

在企业智能化转型的浪潮中，一个日益突出的问题浮出水面：如何让沉睡在PDF、Word和内部文档中的海量知识“活”起来？传统的搜索方式依赖关键词匹配，面对“项目延期可能带来哪些风险”这类复杂问题时往往束手无策；而直接调用大模型又面临数据泄露与幻觉频发的双重困境。正是在这种背景下，一种融合语义理解与逻辑推理的新一代问答系统正悄然成型——以Langchain-Chatchat为基座，引入Neo4j 知识图谱，构建兼具安全性、准确性与推理能力的企业级智能知识中枢。

这套系统的魅力不在于堆砌技术，而在于精准地解决了现实世界中的断层：一边是文档里丰富的非结构化文本，另一边是业务中迫切需要的关系链与因果逻辑。它不再只是“查得到”，而是开始尝试“想得清”。

整个系统的核心流程从一份普通文档开始。用户上传PDF或Word文件后，系统首先通过Unstructured或PyPDF2等工具提取内容，并利用递归字符分割器（RecursiveCharacterTextSplitter）将长文本切分为语义完整的段落块。这一步看似简单，实则极为关键——分块过大容易丢失细节，过小则破坏上下文连贯性，实践中建议控制在300~600字符之间，并保留一定的重叠区域以维持语义连续。

紧接着，文本进入向量化阶段。这里通常选用针对中文优化的嵌入模型，如 BAAI 推出的BGE-zh系列。这些模型能有效捕捉中文语境下的语义相似性，比如“员工请假流程”和“休假申请步骤”即便用词不同，也能被映射到相近的向量空间中。随后，这些向量被存入本地向量数据库，如 FAISS 或 Chroma，支持毫秒级的近似最近邻检索。

from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 加载并解析PDF loader = PyPDFLoader("knowledge.pdf") pages = loader.load() # 分割文本 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) docs = text_splitter.split_documents(pages) # 使用中文优化的BGE模型进行向量化 embedding_model = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") # 存入FAISS实现快速检索 vectorstore = FAISS.from_documents(docs, embedding_model) # 示例查询 query = "公司请假政策是如何规定的？" retrieved_docs = vectorstore.similarity_search(query, k=3) for doc in retrieved_docs: print(doc.page_content)

这段代码虽然简洁，却构成了现代本地知识库的骨架。所有处理均在本地完成，无需联网请求外部API，从根本上杜绝了敏感信息外泄的风险。对于中小规模知识库，FAISS 是轻量高效的首选；若需支持多用户并发访问或持久化存储，则可切换至 Chroma 或 Milvus。

但仅仅做到“找得准”还不够。企业在实际运营中更常遇到的是关系型问题：“张三所在的部门有哪些成员？”、“这个故障曾由哪些历史事件引发？”这类问题要求系统具备“跳转”思维，而这正是纯向量检索的短板所在。

于是，Neo4j 登场了。作为原生图数据库，Neo4j 的优势在于其天然适合表达实体之间的复杂关联。我们不再把文档当作一堆孤立的句子，而是从中抽取出实体（如人名、组织、设备）和它们之间的关系（如隶属、导致、位于），并将这些结构化三元组写入图库。

例如，从一句“张三隶属于研发部，该部门位于北京总部”中，可以自动识别出两个关系路径：

• (张三)-[:BELONGS_TO]->(研发部)
• (研发部)-[:LOCATED_IN]->(北京总部)

一旦建成这样的图谱，就可以通过 Cypher 查询语言执行多跳推理。比如要回答“张三所在地点”，只需一条简单的模式匹配语句即可跨越两层关系获得答案。

from neo4j import GraphDatabase class KnowledgeGraph: def __init__(self, uri, user, password): self.driver = GraphDatabase.driver(uri, auth=(user, password)) def close(self): self.driver.close() def create_entity_relationship(self, entity1, rel_type, entity2): with self.driver.session() as session: session.run( "MERGE (a:Entity {name: $entity1}) " "MERGE (b:Entity {name: $entity2}) " "MERGE (a)-[r:%s]->(b)" % rel_type, entity1=entity1, entity2=entity2 ) # 初始化连接 kg = KnowledgeGraph("bolt://localhost:7687", "neo4j", "your_password") # 插入关系 kg.create_entity_relationship("张三", "BELONGS_TO", "研发部") kg.create_entity_relationship("研发部", "LOCATED_IN", "北京总部") # 多跳查询：查找张三的位置 with kg.driver.session() as session: result = session.run( """ MATCH (p:Entity {name: '张三'})-[:BELONGS_TO]->(d)-[:LOCATED_IN]->(l) RETURN l.name AS location """ ) for record in result: print("Location:", record["location"]) # 输出：北京总部 kg.close()

这段代码展示了图数据库最动人的能力之一：隐式知识的显性化。原本分散在不同文档中的信息，经过结构化整合后，竟能自动推导出新的结论。这种“发现你没想到的知识”，正是智能系统的真正价值所在。

当然，构建图谱并非一键完成。实体识别（NER）和关系抽取（RE）的质量直接决定了图谱的有效性。目前主流做法有两种：一是使用预训练模型（如 UIE、SpaCy + NLP pipeline）做自动化抽取；二是结合规则模板进行增强。无论哪种方式，都需注意实体归一化——避免因“研发部”、“研发部门”、“RD Dept”等表述差异造成节点分裂。生产环境中，建议建立术语表并启用模糊匹配机制。

更重要的是，这套系统并不是让两个引擎各自为战，而是设计了一套“双通道协同”架构，在语义检索与图谱推理之间动态调度：

+------------------+ +---------------------+ | 用户提问输入 | ----> | 问题路由与解析模块 | +------------------+ +----------+----------+ | +-----------------------v------------------------+ | 双通道知识检索引擎 | | | +--------v---------+ +-------------v-----------+ | 向量检索通道 | | 知识图谱推理通道 | | - 文档切片 | | - 实体识别与链接 | | - 向量化 | | - 关系路径查询 | | - FAISS/Chroma检索 | | - 多跳推理 | +--------+---------+ +-------------+-----------+ | | +-----------------------+------------------------+ | +-------v--------+ | 答案融合与生成 | | - 上下文拼接 | | - LLM生成最终答 | +-----------------+

当用户提问时，系统会先分析问题类型。如果是开放性描述类问题（如“总结这份报告的主要观点”），则交由向量引擎召回相关段落；若是涉及明确实体关系的问题（如“XX项目的负责人是谁？”、“A故障可能导致哪些后果？”），则优先触发图谱查询。最终，两路结果被合并送入本地部署的大模型（如 ChatGLM、Qwen）进行自然语言整合，输出流畅且有依据的回答。

这种混合策略带来了显著的优势互补：
- 向量检索覆盖广，擅长处理非结构化知识；
- 图谱推理精度高，特别适合做因果链、组织架构、流程追踪等任务。

在真实应用场景中，这种能力组合已展现出巨大潜力。某制造企业的运维团队将数百份设备手册和故障日志导入系统后，一线工程师只需输入“变频器报警E019可能由哪些原因引起”，系统便能结合历史案例（向量检索）与故障树模型（图谱推理），给出包含电气过载、散热不良等多个维度的排查建议，大幅缩短停机时间。

类似地，在法律合规领域，律师可通过提问“该合同条款违反了哪几项监管规定”来快速定位依据；在科研管理中，研究人员能探索“某个技术概念在过去五年内的演进路径”。新员工入职培训也不再依赖老员工口述经验，只需问一句“报销流程需要哪些审批人”，系统就能自动绘出完整路径。

不过，落地过程中也需关注几个关键设计点：

• 智能路由机制：不能盲目同时调用双引擎。可通过轻量分类模型或关键词规则判断问题类型，提升响应效率。
• 增量更新能力：每当新增文档时，应自动触发信息抽取流程，仅更新受影响的子图，避免全量重建。
• 置信度提示：对不确定性高的答案，应在前端标注“根据文档推测”或“可能性较高”，防止模型“自信地胡说”。
• 资源协调：本地部署需综合考虑GPU显存（LLM推理）、内存（向量缓存）与磁盘IO（图数据库读写），合理分配硬件资源。

尤为值得注意的是，这套架构并不追求完全替代人类专家，而是作为“增强智能”存在——它处理重复性知识查询，释放人力去应对更高阶的决策任务。正如一位客户反馈：“以前花半天找资料，现在十分钟就能拿到线索，剩下的交给专业判断。”

展望未来，随着小型化LLM（如 Phi-3、TinyLlama）的进步和自动化信息抽取技术的成熟，此类系统的部署门槛将进一步降低。或许不久之后，每个团队都将拥有自己的“数字副脑”：既记得住所有文档细节，又能理得清千丝万缕的关系。

Langchain-Chatchat 与 Neo4j 的结合，不只是两项技术的简单叠加，更是一种思维方式的进化——从“检索已知”走向“发现未知”。它提醒我们，真正的智能，不仅在于知道答案，更在于提出正确的问题，并在复杂的知识网络中找到通往答案的那条路径。