做企业级 LLM 知识库项目最大的坑从来不是模型选型而是“demo 能跑上线就废”。你花两周搭了一个基于 RAG 的问答系统演示时效果惊艳一放进生产环境问题立刻暴露回答没有出处、知识更新要全量重建、模型输出质量没人说得清。这些问题单独看都不致命但它们叠加在一起就是一个无法维护的知识系统。这篇文章要解决的正是这四个问题知识不结构化、答案不可溯源、更新成本高、质量无法度量。我会用“10 轮提示词工作流”作为主线把 DeepSeek Harness 工具链、知识图谱、可溯源问答、增量编译、在线评估这些能力串起来完整演示如何从零构建一个工业级的 LLM Wiki 系统。你不一定逐行照抄代码但读完以后你会得到一套可以复用的架构思路、提示词模板和排错清单。1. 为什么普通 RAG 做不了工业级知识库先做一个判断传统 RAG 不是不好而是被用错了场景。把几百份 PDF 切块、向量化、塞进向量数据库然后接一个 LLM 做问答——这是目前市面上最常见的做法。但它只在“文档数量少、问题相对固定、允许一定幻觉”的轻量场景下成立。一旦到了工业级四个问题会依次出现。第一知识没有结构化。向量检索的本质是“按语义相似度找相似文本”它不知道知识之间的逻辑关系。你问“A 项目和 B 项目有哪些协作风险”RAG 可能把两份无关文档拼在一起然后 LLM 强行生成了一个看起来合理、实际不存在的答案。知识图谱恰好补上这一层实体、关系、属性被显式建模回答问题时可以沿着图谱路径做推理。第二答案不可溯源。工业场景不能接受“模型说自己不知道”或者“模型编了一个出处”。每个回答都要能回看到具体文档、具体段落、具体图谱路径。没有溯源机制知识的可信度就是零合规审核也过不了。第三更新成本高。传统 RAG 的常见策略是“全量重建”文档有变化就重新切块、重新向量化、重新导入。如果知识库有十万级文档一次全量重建可能耗几个小时。增量编译要解决的问题就是只处理变化的部分新文档进来时对新增内容做抽取和索引而不是推倒重来。第四质量不可度量。大多数 RAG 项目死在“没有评测集”。改了一个提示词模型输出是变好了还是变差了换了一个 embedding 模型检索召回率提升没有没有在线评估机制所有优化都是凭感觉。这也是为什么 Harness 类的评估工具在工业级项目中几乎是必需品。所以我的结论很明确LLM Wiki 的本质不是“用 LLM 做搜索”而是“用 LLM 构建和维护一个可溯源、可评估、可更新的知识系统”。后面所有内容都围绕这个判断展开。2. LLM Wiki 范式与 DeepSeek Harness 的定位2.1 LLM Wiki 是什么从文档仓库到可执行知识库LLM Wiki 这个概念近几年被频繁提及关键不是“Wiki”这个形式而是它背后的知识组织方式。一个合格的 LLM Wiki 至少要有三层原始文档层PDF、Word、Markdown、网页等原始材料是知识的源头也是回答引用的最终出处。结构化知识层从原始文档中抽取的实体、关系、属性以知识图谱形式存储用于回答跨文档、多跳问题。问答索引层面向问答场景的索引包括向量索引和问答对缓存用于快速检索和生成答案。这三层不是割裂的。结构化知识层负责“理解”问答索引层负责“检索”原始文档层负责“可溯源”。任何一层缺失LLM Wiki 都会退化为一个稍好一点的搜索引擎。在工程实现上LLM Wiki 的核心是“可执行知识”知识不只是被归档保存还要能被 LLM 查询、校验、更新。这就引出了持续迭代的工作流——不是一次性构建完成而是像软件工程一样有编译、有测试、有发布、有回滚。2.2 DeepSeek HarnessLLM 项目的“开发测试一体化”工具链这里要重点说 DeepSeek Harness。从社区项目的定位来看它不是单一的模型而是一套围绕 DeepSeek 模型的应用开发与评测工具链把模型调用、提示词编排、测试用例管理、在线评估、知识库索引这些能力做成了统一入口。常见形态包括命令行工具CLI、Web 控制台、桌面版Studio以及插件机制。为什么要强调 Harness 这类工具因为单靠裸调 APILLM 应用开发会陷入一片混乱提示词改了哪里没有记录、模型输出有没有退化没有对比、测试集和提示词版本脱节。Harness 提供的核心价值是把“提示词工程”和“模型评估”变成可管理的工程流程。需要特别说明的是DeepSeek Harness 目前迭代速度很快不同版本的安装方式和命令可能不同。本文后面给出的安装和启动命令是常见操作形态实际使用请以官方文档为准。这种保守不是敷衍而是因为 LLM 工具链目前处于快速演进期写死某个版本命令反而容易误导读者。2.3 为什么选择 DeepSeek 模型底座在这个架构里DeepSeek 模型承担两个角色一是抽取知识三元组的“知识工程师”二是生成可溯源答案的“问答助手”。选择它的原因有三个。一是推理能力足以支撑复杂的知识抽取指令。实体关系抽取不是简单分类它要求模型理解句子语义、跨句推断、遵循严格 JSON 输出格式这对模型的指令跟随能力要求很高。实测下来DeepSeek 的深度推理模型在结构化抽取任务上的表现足够稳定。二是OpenAI 兼容 API 降低了工程接入成本。DeepSeek 开放接口兼容 OpenAI 协议意味着现有的 LangChain、LlamaIndex 等生态工具可以直接复用不需要为模型单独写一套适配层。三是成本和私有化部署的灵活性。工业级知识库如果每次问答都走云端 API成本压力很大。DeepSeek 开源权重支持私有化部署可以在企业内网以较低成本运行。具体是调 API 还是私有化部署取决于你的数据敏感度和预算这个后面会在最佳实践里展开。3. 整体架构设计四层联动整个 LLM Wiki 系统的架构可以拆成四层。这张表描述的是逻辑分层每一层都有对应的技术选型。层级核心职责技术选型是不是必需数据层存储原始文档、问答记录、评测集MinIO/本地文件系统/MySQL是图谱层存储实体、关系、属性支撑多跳推理Neo4j工业级推荐索引层向量检索、全文检索、增量索引Elasticsearch / ChromaDB / FAISS是评估层评测集管理、自动评分、回归对比DeepSeek Harness 自研脚本工业级必选核心流程是这样的原始文档进入数据层触发抽取任务。LLM 从文档中抽取实体、关系、属性输出 JSON 格式的三元组。Python 脚本把三元组写入 Neo4j同时构建向量索引。用户提问时先在图谱中走实体检索和关系路径扩展再结合向量检索召回相关片段共同组成上下文。LLM 基于图谱路径和参考片段生成答案每条回答都携带引用编号。回答进入评估层在线评测集自动打分发现问题后回到提示词或图谱侧修正。这个架构的核心思想是**“图谱管结构、向量管语义、模型管生成、评估管质量”**。每个环节都有清晰的边界替换任意一个组件都不会牵一发动全身。4. 10 轮提示工作流从混沌到工业级“10 轮提示”不是随便让 LLM 聊十次天而是把 LLM Wiki 的构建过程拆成 10 个有明确输入输出和验收标准的阶段。每一轮都是一次独立的提示词任务上一轮的结构化输出是下一轮的输入。先看总览表。轮次目标输入输出验收标准第 1 轮定义 Wiki 目标与边界项目背景主题定义、受众、知识范围边界清晰可执行第 2 轮设计知识分类体系主题定义分类树、标签体系覆盖知识范围无重叠第 3 轮材料导入与清洗原始文档清洗后的文档集噪声内容被剔除第 4 轮实体与关系抽取清洗后的文档实体表、关系表JSON实体去重、关系有出处第 5 轮图谱构建与校验三元组 JSONNeo4j 图数据 校验报告无孤立实体、无关系冲突第 6 轮问答对生成图谱 文档FAQ 与复杂问答对问题覆盖知识范围第 7 轮可溯源索引构建问答对 原始文档带来源的索引条目每条答案对应原始出处第 8 轮在线评估评测问答对得分报告、失败案例准确率达标第 9 轮增量编译新增文档新增图谱和索引只处理增量全量不受影响第 10 轮发布与运营系统 监控可访问的 Wiki 服务上线可用监控正常下面按四个阶段逐轮展开。4.1 第 1-3 轮定调、选材、清洗很多 LLM 知识库项目失败不是因为模型不够强而是因为第一轮就错了没有定义清楚“这个 Wiki 到底服务谁、回答什么问题、哪些问题不回答”。第 1 轮提示词模板你是一位知识库架构师。我们要构建一个关于[XX领域]的LLM Wiki目标用户是[XX角色]。 请完成以下任务 1. 给这个Wiki写一段定位说明不超过200字。 2. 列出8-12个必须覆盖的核心主题。 3. 列出5个明确不在覆盖范围内的问题类型防止问答越界。 4. 输出JSON格式{positioning: , core_topics: [], out_of_scope: []}这一轮真正的价值不是输出格式而是让项目参与者对齐预期。如果你发现自己列不出 out_of_scope说明知识边界还没有想清楚。第 2 轮在这个基础上生成分类树。分类树的黄金法则是“互斥且穷尽”任何一个文档都能找到唯一的分类归属不会出现“这个放 A 也行放 B 也对”的歧义。第 3 轮处理文档清洗。这一步最容易被忽略但其实是决定后续抽取质量的关键。喂给第 4 轮的文档如果充斥着导航栏、页眉页脚、无关广告LLM 抽取出的图谱质量必然堪忧。清洗的底线是正文完整、来源可识别、重复内容去重。4.2 第 4-5 轮实体关系抽取与图谱构建第 4 轮是知识图谱建设中最核心的一步。提示词不能只是“抽取实体和关系”而是要明确定义实体类型、关系类型、输出格式以及对“不确定性”的处理方式。第 4 轮提示词模板你是一位知识图谱构建专家。请从下面的文档中抽取实体和关系。 实体类型定义可以新增但必须先声明 - PRODUCT产品名称 - TECHNOLOGY技术名称 - PERSON人员 - ORG组织 - PROJECT项目 - EVENT事件 关系类型定义 - RELATES_TO相关 - DEPENDS_ON依赖 - LEADS_TO导致 - COLLABORATES_WITH协作 - USES使用 严格约束 1. 实体去重同一实体的不同表述必须归一为同一个名称。 2. 每个关系必须能用文档中的原句支持没有原句支持的关系不要抽取。 3. 如果不确定某个实体是否是产品还是技术归类为语义最接近的类型并在description里说明。 4. 输出JSON格式不要输出任何解释文字。 {entities: [{name: , type: , description: }], relations: [{source: , type: , target: }]} 文档内容 [待处理的清洗后文档]这里真正的难点是实体归一化。“DeepSeek”“深度求索”“DeepSeek公司”是不是同一个实体这类问题如果不在提示词里约束图谱会被同义实体撑爆。工程上的推荐做法是LLM 抽取后再做一层规则或向量聚类对齐将同义实体合并。第 5 轮把第 4 轮输出的三元组写入 Neo4j同时做一致性校验。需要重点排查三类问题孤立实体有实体没有任何关系说明抽取时上下文不足或者关系被遗漏。关系冲突A 依赖 B同时 B 依赖 A在依赖语义下矛盾。类型不一致同一个实体在不同文档里被标为 PRODUCT 和 TECHNOLOGY。校验环节可以继续用 LLM 做也可以写脚本配合图查询做。核心原则是图谱不是“导入就行了”它需要像代码一样接受质量检查。4.3 第 6-8 轮问答对生成、溯源和评估第 6 轮生成问答对。这轮要区分“事实型问题”和“推理型问题”。事实型问题可以直接从图谱中抽取比如“产品 X 的技术栈是什么”推理型问题需要跨多个实体推理比如“项目 A 依赖的技术栈中有哪些存在安全风险”。两类问题都要生成因为工业级 Wiki 真正的价值在推理型问答上。第 7 轮是“可溯源”落地的关键。每一条生成的问答对都必须绑定到图谱路径和原始文档段落。数据结构大致是这样{ question: 项目A使用了哪些数据库, answer: 项目A使用了MySQL和Redis。, evidence: [ {type: graph_path, path: 项目A-USES-MySQL}, {type: source_doc, doc_id: doc_001, paragraph: 项目A的技术选型包括MySQL作为主存储Redis用于缓存。} ] }答案可以重新生成但 evidence 必须来自真实路径和文档。做不到这一点的知识库不管模型多么聪明都不具备生产条件。第 8 轮是在线评估的起点。把第 6-7 轮生成的问答对整理为评测集然后让评估模型对回答质量打分。评分维度建议包括四个准确性、完整性、引用可溯性、回答简洁性。一个回答如果事实正确但引用错了文档溯源分必须扣——因为工业场景里错误引用比不引用更有害。4.4 第 9-10 轮增量编译与上线运营第 9 轮的增量编译解决的是“文档更新后怎么维护”的问题。传统做法是全量重建增量编译的思路则完全不同只对新增和修改的文档做第 3 到第 7 轮的流程然后合并进已有图谱和索引。这里的核心工程问题是冲突处理。新文档说“项目 A 不再使用 Redis”旧图谱里却是“项目 A 使用 Redis”。如果直接合并新增节点会产生自相矛盾的知识图谱。实践中的方案是关系带上版本号和状态字段新关系写入时标记旧关系为 superseded已取代而不是物理删除。这样既保留了历史又能回答“当前状态”的问题。第 10 轮上线运营除了常规的部署监控之外要特别重视反馈闭环用户对每个回答的行为数据点赞、点踩、追问回流到评测集成为下一轮评估的种子数据。LLM Wiki 不是一个一次性交付的项目它是一个需要持续运营的知识系统。5. 环境准备与工具链安装下面进入实操环节。先说明环境基线版本细节请以实际安装为准本文重点演示通用思路。硬件建议如果使用云端 API8GB 内存的普通开发机即可完成全部流程。如果要私有化部署 DeepSeek 模型做推理建议 GPU 显存不低于 24GB具体取决于模型参数量。软件清单Python 3.10Node.js 18 和 pnpmDeepSeek Harness 常见安装依赖Neo4j Community Edition 5.x向量数据库可选 ChromaDB轻量演示或 Elasticsearch生产DeepSeek API Key或本地推理服务地址5.1 安装 DeepSeek Harness以官方文档为准# 确认 Node 与 pnpm 环境 node -v pnpm -v # 以 npm/pnpm 全局方式安装具体命令和包名以官方文档为准 pnpm add -g dsh # 启动 Web 控制台 dsh web如果你的版本没有dsh命令或者安装后卡在pnpm dsh web不要硬试。优先检查三件事确认全局 bin 目录是否加入了 PATH启动时端口是否被占用首次启动是否在下载初始化依赖。桌面版Studio通常在官网 Release 页面或应用商店提供安装包安装后直接启动即可。5.2 安装 Neo4jNeo4j 在 Linux 和 macOS 上可以用包管理器安装Windows 可以下载安装包。安装后启动服务默认控制台地址是http://localhost:7474默认账号密码都是neo4j首次登录会强制修改密码。# macOS 使用 Homebrew 安装 brew install neo4j # Linux 使用包管理器安装后启动 sudo systemctl start neo4j5.3 安装 Python 依赖pip install openai neo4j chromadb这些库分别用于调用 DeepSeek API、连接 Neo4j 图数据库、操作向量索引。6. 核心代码实现这一节给出四个可以直接跑的代码骨架知识图谱构建、可溯源问答、增量索引、在线评估。每个示例都做了简化核心逻辑完整保留。6.1 知识图谱构建Python Neo4j# 文件路径scripts/build_graph.py import json from neo4j import GraphDatabase # 连接参数建议放到环境变量或配置中心不要硬编码 NEO4J_URI bolt://localhost:7687 NEO4J_USER neo4j NEO4J_PASSWORD your-password def create_entity(tx, entity): query MERGE (e:Entity {name: $name}) SET e.type $type, e.description $description tx.run(query, nameentity[name], typeentity[type], descriptionentity.get(description, )) def create_relation(tx, source, relation, target): query MATCH (a:Entity {name: $source}) MATCH (b:Entity {name: $target}) MERGE (a)-[r:REL {type: $relation}]-(b) tx.run(query, sourcesource, relationrelation, targettarget) if __name__ __main__: # 第4轮LLM抽取结果 with open(data/entities.json, r, encodingutf-8) as f: data json.load(f) driver GraphDatabase.driver(NEO4J_URI, auth(NEO4J_USER, NEO4J_PASSWORD)) with driver.session() as session: for entity in data[entities]: session.execute_write(create_entity, entity) for rel in data[relations]: session.execute_write( create_relation, rel[source], rel[type], rel[target] ) driver.close() print(知识图谱构建完成)这段代码的核心是MERGE语句它的含义是“存在就匹配不存在就创建”。这是图数据库做增量更新的基础——重复执行不会产生重复节点。关系也是同理用MERGE避免重复边。6.2 可溯源问答DeepSeek API 引用标注# 文件路径rag_qa.py from openai import OpenAI client OpenAI( api_keysk-xxx, # 替换为你的 DeepSeek API Key base_urlhttps://api.deepseek.com/v1 # OpenAI 兼容接口 ) def ask_with_citation(question, context_docs): # context_docs: [{content: ..., source: doc_001}, ...] context_text \n\n.join( f[{i1}] {doc[content]}\n来源{doc[source]} for i, doc in enumerate(context_docs) ) system_prompt ( 你是企业知识库问答助手。回答必须基于提供的参考材料。 每条回答末尾必须标注引用编号禁止编造参考材料没有的内容。 ) messages [ {role: system, content: system_prompt}, {role: user, content: f参考材料\n{context_text}\n\n问题{question}} ] resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.2, # 知识问答用低温度减少随机性 ) return resp.choices[0].message.content这里有两个关键设计。第一是temperature0.2知识问答场景宁可回答“不知道”也不编造低温度能显著降低幻觉概率。第二是引用编号机制它把“答案”和“证据”强行绑定到一起——如果模型在回答里写了[1]那么[1]必须对应参考材料里的一个来源。工程上可以进一步做引用校验检测模型是否把出处标错了。6.3 增量编译与索引更新# 文件路径incremental_index.py # 基于 ChromaDB 的增量索引示例API 版本以实际安装为准 import chromadb class IncrementalIndex: def __init__(self, persist_path./chroma_db): self.client chromadb.PersistentClient(pathpersist_path) self.collection self.client.get_or_create_collection( namellm_wiki, metadata{hnsw:space: cosine} ) self._loaded_ids set() self._load_processed_ids() def _load_processed_ids(self): # 生产环境应从数据库或文件读取已处理文档 ID 的快照 # 这里简化为从已存在集合中获取 try: existing self.collection.get(include[])[ids] self._loaded_ids set(existing) except Exception: self._loaded_ids set() def upsert_document(self, doc_id, text, metadata): # 已处理过且内容相同的文档跳过 if doc_id in self._loaded_ids: return False self.collection.upsert( ids[doc_id], documents[text], metadatas[metadata] ) self._loaded_ids.add(doc_id) return True # 使用示例 # index IncrementalIndex() # index.upsert_document(doc_100, 新增文档内容..., {source: doc_100})增量编译的核心逻辑就是这个upsert——相同的文档 ID 写多次不会产生重复新的文档 ID 直接追加。生产环境比这复杂需要处理文档修改、删除、版本对比但这个骨架已经把最重要的“只处理增量”的思路体现出来了。6.4 在线评估脚本# 文件路径evaluate.py import random from openai import OpenAI client OpenAI( api_keysk-xxx, base_urlhttps://api.deepseek.com/v1 ) EVAL_PROMPT 你是问答质量评估员。请从四个维度对回答打分1-5分 - 准确性事实是否正确有没有幻觉。 - 完整性是否充分回答了问题。 - 可溯性引用或证据是否能支撑答案。 - 简洁性是否冗余。 只输出 JSON不要解释 {accuracy: 0, completeness: 0, traceability: 0, conciseness: 0} def evaluate_answer(question, reference_answer, model_answer): prompt f 问题{question} 参考答案{reference_answer} 模型回答{model_answer} {EVAL_PROMPT} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0 ) return resp.choices[0].message.content if __name__ __main__: # 从评测集中随机抽取N条 eval_set json.load(open(data/eval_set.json, encodingutf-8)) sample random.sample(eval_set, min(20, len(eval_set))) scores [] for item in sample: model_answer ask_with_citation(item[question], item[docs]) result evaluate_answer( item[question], item[reference_answer], model_answer ) scores.append(json.loads(result)) print(f平均分{sum(s[accuracy] for s in scores) / len(scores):.2f})评估这件事核心思想是“先有评测集才有优化权”。没有评测集的 LLM 应用优化就是玄学有了评测集之后每次改动都能看到分数的变化这才是工程化。7. 运行结果与效果验证按照前面顺序执行你会看到几个关键输出节点。7.1 图谱构建运行python scripts/build_graph.py后预期输出知识图谱构建完成然后打开 Neo4j Browserhttp://localhost:7474执行MATCH (n) RETURN n LIMIT 25;如果能看到带标签的节点和关系说明第 4-5 轮图谱构建成功。如果图结果为空回到第 4 步检查entities.json是否为空再检查 Neo4j 连接参数是否正确。7.2 增量索引运行增量索引脚本后检查./chroma_db目录是否生成并确认对同一文档重复执行不会重复添加。这一步验证失败往往是 ChromaDB 的 API 版本差异优先看错误日志中提示的方法名是否在当前版本存在。7.3 可溯源问答调用ask_with_citation预期的回答格式应该是包含引用编号的完整答案。验收标准是回答中的每个[n]都能对应输入的context_docs[n]。如果回答没有引用说明系统提示词里的引用要求被模型忽略了可以把引用格式要求放到用户消息的末尾模型对靠近问题处的指令遵从率更高。7.4 在线评估运行python evaluate.py预期输出一个平均分。如果准确性平均分低于 4 分最优先排查的不是模型而是上下文中是否混入了不相关或过时的文档。知识问答中 80% 的坏答案都源于坏上下文。8. 常见问题与排查思路这里整理一套实战中更容易踩到的问题清单。问题现象可能原因排查方式解决方案DeepSeek Harness 安装后dsh命令找不到全局 bin 目录未加入 PATH执行npm bin -g查看路径将输出目录加入 PATH或改用 npx 调用启动dsh web卡住不动首次初始化下载依赖或端口被占用查看终端输出和系统端口占用等待初始化完成检查 3000/8000 等端口是否被占用DeepSeek API 调用返回 401API Key 错误或余额不足检查请求日志和 Key 配置重新生成 Key确认 base_url 正确Neo4j 中查不到关系抽取的三元组没有写入或 MERGE 匹配失败先查实体是否存在检查entities.json格式确认实体名称无空格差异实体抽取出现大量同义不同名提示词没有归一化约束查看抽取结果中的实体列表在提示词中加入归一化约束或者增加规则/向量去重问答回答没有引用编号系统提示词约束不生效检查模型输出把引用格式要求放到用户消息末尾降低 temperature增量更新后问题答案仍然过期旧关系没有标记 superseded查看图谱中同一关系的多条状态增加状态字段新关系写入时标记旧关系为 superseded评估得分低但人工觉得没问题评测集问题或参考答案有偏抽样人工复核检查评测集的 question 和 reference_answer 是否需要更新向量检索召回质量差文档切分策略不合理检查切片大小和重叠度过短切片召回噪声大过长切片语义不聚焦需要调参下载依赖很慢网络问题或镜像源缺失查看 pnpm/npm 下载日志配置国内镜像源或使用离线依赖包排查的底层思路是先定位是哪一层出了问题。LLM Wiki 是分层的架构同一个“答案不对”的症状可能来自索引层、图谱层、生成层或评估层。不看分层直接调模型是最常见的返工原因。9. 最佳实践与工程建议最后这组实践建议来自实际项目里最值得复用的经验。先建评测集再建知识库。很多团队先搭系统再补评测集结果优化时没有基准。正确顺序是第一批文档清洗完后先人工标注 50-100 条问答对作为种子评测集后面的每一步修改都以评测集分数为准绳。知识图谱要保留历史版本。工业级知识库每天都在变。给实体和关系加valid_from、valid_to、status字段让图谱支持“当前快照”和“历史回溯”两种查询模式。很多合规审计场景要求看到某个时间点的知识状态没有版本历史根本无法回答。LLM 只做抽取不做决定。实体关系的合并、冲突解决、图谱写入最终应该由规则和人工审核决定。LLM 负责提出候选工程系统负责把关。这个边界不划清图谱会随着 LLM 升级而出现不可控的漂移。溯源是系统设计不是提示词设计。不要指望模型“记住”引用。把引用作为输入的一部分传给模型让答案中的每个编号都能在系统层面回查。系统层检查引用的合法性比模型自觉可靠得多。生产环境对 DeepSeek 模型的推理精度要有感知。同样的模型用 fp16 还是 bf16 部署在长文本生成和复杂抽取任务上表现会有细微差异。上线前要固定推理精度并在评测集上跑一遍基线避免“换了个部署方式效果变了”的诡异问题。把提示词也纳入版本管理。提示词是代码的一部分。使用 Git 管理提示词变更每次修改都要关联评测集分数。否则会出现“上周还好好的这周变差了”却找不到原因的情况。访问控制要单独设计。LLM Wiki 部署到局域网后如果允许团队其他人访问需要设置鉴权。最简单的方式是在 Nginx 层做反向代理和 Basic Auth复杂场景接入公司 SSO。不要裸奔。10. 总结与后续学习方向这篇文章的核心线索是LLM Wiki 不是“文档 问答”的简单组合而是一个有结构、有溯源、有评估、有增量更新机制的知识系统工程。10 轮提示工作流的价值在于把知识库建设从一次性项目变成了可迭代、可验证的持续过程。DeepSeek Harness 负责承载这个过程中最繁琐的编排和评估任务知识图谱负责补足 RAG 缺失的结构化推理能力增量编译解决知识更新的成本问题在线评估让每一步优化都有数据支撑。下一步可以继续深入的方向有三个多跳问答评测集建设当前评测集大多是单文档问题可以研究如何设计跨文档、多跳推理的评测用例这是 LLM Wiki 与普通 RAG 拉开距离的关键。图谱与向量的混合检索策略什么时候走图谱路径什么时候走向量召回如何把两者结果做融合排序这是工程优化的深水区。增量编译中的冲突消解机制关系版本化只是起步更复杂的场景是新旧文档“部分冲突、部分兼容”如何自动判断并生成人工审核工单值得专门设计。把这套流程跑通之后你会明显感觉到知识库系统的天花板已经从“模型聪明不聪明”变成了“工程体系完整不完整”。这篇文章里的代码和模板可以当作起点真正的工业级落地还需要你基于自身业务场景把每个细节打磨到位。建议收藏备用实战时对照排查清单逐步推进。 从RAG到LLM Wiki：10轮提示词构建工业级知识库
做企业级 LLM 知识库项目最大的坑从来不是模型选型而是“demo 能跑上线就废”。你花两周搭了一个基于 RAG 的问答系统演示时效果惊艳一放进生产环境问题立刻暴露回答没有出处、知识更新要全量重建、模型输出质量没人说得清。这些问题单独看都不致命但它们叠加在一起就是一个无法维护的知识系统。这篇文章要解决的正是这四个问题知识不结构化、答案不可溯源、更新成本高、质量无法度量。我会用“10 轮提示词工作流”作为主线把 DeepSeek Harness 工具链、知识图谱、可溯源问答、增量编译、在线评估这些能力串起来完整演示如何从零构建一个工业级的 LLM Wiki 系统。你不一定逐行照抄代码但读完以后你会得到一套可以复用的架构思路、提示词模板和排错清单。1. 为什么普通 RAG 做不了工业级知识库先做一个判断传统 RAG 不是不好而是被用错了场景。把几百份 PDF 切块、向量化、塞进向量数据库然后接一个 LLM 做问答——这是目前市面上最常见的做法。但它只在“文档数量少、问题相对固定、允许一定幻觉”的轻量场景下成立。一旦到了工业级四个问题会依次出现。第一知识没有结构化。向量检索的本质是“按语义相似度找相似文本”它不知道知识之间的逻辑关系。你问“A 项目和 B 项目有哪些协作风险”RAG 可能把两份无关文档拼在一起然后 LLM 强行生成了一个看起来合理、实际不存在的答案。知识图谱恰好补上这一层实体、关系、属性被显式建模回答问题时可以沿着图谱路径做推理。第二答案不可溯源。工业场景不能接受“模型说自己不知道”或者“模型编了一个出处”。每个回答都要能回看到具体文档、具体段落、具体图谱路径。没有溯源机制知识的可信度就是零合规审核也过不了。第三更新成本高。传统 RAG 的常见策略是“全量重建”文档有变化就重新切块、重新向量化、重新导入。如果知识库有十万级文档一次全量重建可能耗几个小时。增量编译要解决的问题就是只处理变化的部分新文档进来时对新增内容做抽取和索引而不是推倒重来。第四质量不可度量。大多数 RAG 项目死在“没有评测集”。改了一个提示词模型输出是变好了还是变差了换了一个 embedding 模型检索召回率提升没有没有在线评估机制所有优化都是凭感觉。这也是为什么 Harness 类的评估工具在工业级项目中几乎是必需品。所以我的结论很明确LLM Wiki 的本质不是“用 LLM 做搜索”而是“用 LLM 构建和维护一个可溯源、可评估、可更新的知识系统”。后面所有内容都围绕这个判断展开。2. LLM Wiki 范式与 DeepSeek Harness 的定位2.1 LLM Wiki 是什么从文档仓库到可执行知识库LLM Wiki 这个概念近几年被频繁提及关键不是“Wiki”这个形式而是它背后的知识组织方式。一个合格的 LLM Wiki 至少要有三层原始文档层PDF、Word、Markdown、网页等原始材料是知识的源头也是回答引用的最终出处。结构化知识层从原始文档中抽取的实体、关系、属性以知识图谱形式存储用于回答跨文档、多跳问题。问答索引层面向问答场景的索引包括向量索引和问答对缓存用于快速检索和生成答案。这三层不是割裂的。结构化知识层负责“理解”问答索引层负责“检索”原始文档层负责“可溯源”。任何一层缺失LLM Wiki 都会退化为一个稍好一点的搜索引擎。在工程实现上LLM Wiki 的核心是“可执行知识”知识不只是被归档保存还要能被 LLM 查询、校验、更新。这就引出了持续迭代的工作流——不是一次性构建完成而是像软件工程一样有编译、有测试、有发布、有回滚。2.2 DeepSeek HarnessLLM 项目的“开发测试一体化”工具链这里要重点说 DeepSeek Harness。从社区项目的定位来看它不是单一的模型而是一套围绕 DeepSeek 模型的应用开发与评测工具链把模型调用、提示词编排、测试用例管理、在线评估、知识库索引这些能力做成了统一入口。常见形态包括命令行工具CLI、Web 控制台、桌面版Studio以及插件机制。为什么要强调 Harness 这类工具因为单靠裸调 APILLM 应用开发会陷入一片混乱提示词改了哪里没有记录、模型输出有没有退化没有对比、测试集和提示词版本脱节。Harness 提供的核心价值是把“提示词工程”和“模型评估”变成可管理的工程流程。需要特别说明的是DeepSeek Harness 目前迭代速度很快不同版本的安装方式和命令可能不同。本文后面给出的安装和启动命令是常见操作形态实际使用请以官方文档为准。这种保守不是敷衍而是因为 LLM 工具链目前处于快速演进期写死某个版本命令反而容易误导读者。2.3 为什么选择 DeepSeek 模型底座在这个架构里DeepSeek 模型承担两个角色一是抽取知识三元组的“知识工程师”二是生成可溯源答案的“问答助手”。选择它的原因有三个。一是推理能力足以支撑复杂的知识抽取指令。实体关系抽取不是简单分类它要求模型理解句子语义、跨句推断、遵循严格 JSON 输出格式这对模型的指令跟随能力要求很高。实测下来DeepSeek 的深度推理模型在结构化抽取任务上的表现足够稳定。二是OpenAI 兼容 API 降低了工程接入成本。DeepSeek 开放接口兼容 OpenAI 协议意味着现有的 LangChain、LlamaIndex 等生态工具可以直接复用不需要为模型单独写一套适配层。三是成本和私有化部署的灵活性。工业级知识库如果每次问答都走云端 API成本压力很大。DeepSeek 开源权重支持私有化部署可以在企业内网以较低成本运行。具体是调 API 还是私有化部署取决于你的数据敏感度和预算这个后面会在最佳实践里展开。3. 整体架构设计四层联动整个 LLM Wiki 系统的架构可以拆成四层。这张表描述的是逻辑分层每一层都有对应的技术选型。层级核心职责技术选型是不是必需数据层存储原始文档、问答记录、评测集MinIO/本地文件系统/MySQL是图谱层存储实体、关系、属性支撑多跳推理Neo4j工业级推荐索引层向量检索、全文检索、增量索引Elasticsearch / ChromaDB / FAISS是评估层评测集管理、自动评分、回归对比DeepSeek Harness 自研脚本工业级必选核心流程是这样的原始文档进入数据层触发抽取任务。LLM 从文档中抽取实体、关系、属性输出 JSON 格式的三元组。Python 脚本把三元组写入 Neo4j同时构建向量索引。用户提问时先在图谱中走实体检索和关系路径扩展再结合向量检索召回相关片段共同组成上下文。LLM 基于图谱路径和参考片段生成答案每条回答都携带引用编号。回答进入评估层在线评测集自动打分发现问题后回到提示词或图谱侧修正。这个架构的核心思想是**“图谱管结构、向量管语义、模型管生成、评估管质量”**。每个环节都有清晰的边界替换任意一个组件都不会牵一发动全身。4. 10 轮提示工作流从混沌到工业级“10 轮提示”不是随便让 LLM 聊十次天而是把 LLM Wiki 的构建过程拆成 10 个有明确输入输出和验收标准的阶段。每一轮都是一次独立的提示词任务上一轮的结构化输出是下一轮的输入。先看总览表。轮次目标输入输出验收标准第 1 轮定义 Wiki 目标与边界项目背景主题定义、受众、知识范围边界清晰可执行第 2 轮设计知识分类体系主题定义分类树、标签体系覆盖知识范围无重叠第 3 轮材料导入与清洗原始文档清洗后的文档集噪声内容被剔除第 4 轮实体与关系抽取清洗后的文档实体表、关系表JSON实体去重、关系有出处第 5 轮图谱构建与校验三元组 JSONNeo4j 图数据 校验报告无孤立实体、无关系冲突第 6 轮问答对生成图谱 文档FAQ 与复杂问答对问题覆盖知识范围第 7 轮可溯源索引构建问答对 原始文档带来源的索引条目每条答案对应原始出处第 8 轮在线评估评测问答对得分报告、失败案例准确率达标第 9 轮增量编译新增文档新增图谱和索引只处理增量全量不受影响第 10 轮发布与运营系统 监控可访问的 Wiki 服务上线可用监控正常下面按四个阶段逐轮展开。4.1 第 1-3 轮定调、选材、清洗很多 LLM 知识库项目失败不是因为模型不够强而是因为第一轮就错了没有定义清楚“这个 Wiki 到底服务谁、回答什么问题、哪些问题不回答”。第 1 轮提示词模板你是一位知识库架构师。我们要构建一个关于[XX领域]的LLM Wiki目标用户是[XX角色]。 请完成以下任务 1. 给这个Wiki写一段定位说明不超过200字。 2. 列出8-12个必须覆盖的核心主题。 3. 列出5个明确不在覆盖范围内的问题类型防止问答越界。 4. 输出JSON格式{positioning: , core_topics: [], out_of_scope: []}这一轮真正的价值不是输出格式而是让项目参与者对齐预期。如果你发现自己列不出 out_of_scope说明知识边界还没有想清楚。第 2 轮在这个基础上生成分类树。分类树的黄金法则是“互斥且穷尽”任何一个文档都能找到唯一的分类归属不会出现“这个放 A 也行放 B 也对”的歧义。第 3 轮处理文档清洗。这一步最容易被忽略但其实是决定后续抽取质量的关键。喂给第 4 轮的文档如果充斥着导航栏、页眉页脚、无关广告LLM 抽取出的图谱质量必然堪忧。清洗的底线是正文完整、来源可识别、重复内容去重。4.2 第 4-5 轮实体关系抽取与图谱构建第 4 轮是知识图谱建设中最核心的一步。提示词不能只是“抽取实体和关系”而是要明确定义实体类型、关系类型、输出格式以及对“不确定性”的处理方式。第 4 轮提示词模板你是一位知识图谱构建专家。请从下面的文档中抽取实体和关系。 实体类型定义可以新增但必须先声明 - PRODUCT产品名称 - TECHNOLOGY技术名称 - PERSON人员 - ORG组织 - PROJECT项目 - EVENT事件 关系类型定义 - RELATES_TO相关 - DEPENDS_ON依赖 - LEADS_TO导致 - COLLABORATES_WITH协作 - USES使用 严格约束 1. 实体去重同一实体的不同表述必须归一为同一个名称。 2. 每个关系必须能用文档中的原句支持没有原句支持的关系不要抽取。 3. 如果不确定某个实体是否是产品还是技术归类为语义最接近的类型并在description里说明。 4. 输出JSON格式不要输出任何解释文字。 {entities: [{name: , type: , description: }], relations: [{source: , type: , target: }]} 文档内容 [待处理的清洗后文档]这里真正的难点是实体归一化。“DeepSeek”“深度求索”“DeepSeek公司”是不是同一个实体这类问题如果不在提示词里约束图谱会被同义实体撑爆。工程上的推荐做法是LLM 抽取后再做一层规则或向量聚类对齐将同义实体合并。第 5 轮把第 4 轮输出的三元组写入 Neo4j同时做一致性校验。需要重点排查三类问题孤立实体有实体没有任何关系说明抽取时上下文不足或者关系被遗漏。关系冲突A 依赖 B同时 B 依赖 A在依赖语义下矛盾。类型不一致同一个实体在不同文档里被标为 PRODUCT 和 TECHNOLOGY。校验环节可以继续用 LLM 做也可以写脚本配合图查询做。核心原则是图谱不是“导入就行了”它需要像代码一样接受质量检查。4.3 第 6-8 轮问答对生成、溯源和评估第 6 轮生成问答对。这轮要区分“事实型问题”和“推理型问题”。事实型问题可以直接从图谱中抽取比如“产品 X 的技术栈是什么”推理型问题需要跨多个实体推理比如“项目 A 依赖的技术栈中有哪些存在安全风险”。两类问题都要生成因为工业级 Wiki 真正的价值在推理型问答上。第 7 轮是“可溯源”落地的关键。每一条生成的问答对都必须绑定到图谱路径和原始文档段落。数据结构大致是这样{ question: 项目A使用了哪些数据库, answer: 项目A使用了MySQL和Redis。, evidence: [ {type: graph_path, path: 项目A-USES-MySQL}, {type: source_doc, doc_id: doc_001, paragraph: 项目A的技术选型包括MySQL作为主存储Redis用于缓存。} ] }答案可以重新生成但 evidence 必须来自真实路径和文档。做不到这一点的知识库不管模型多么聪明都不具备生产条件。第 8 轮是在线评估的起点。把第 6-7 轮生成的问答对整理为评测集然后让评估模型对回答质量打分。评分维度建议包括四个准确性、完整性、引用可溯性、回答简洁性。一个回答如果事实正确但引用错了文档溯源分必须扣——因为工业场景里错误引用比不引用更有害。4.4 第 9-10 轮增量编译与上线运营第 9 轮的增量编译解决的是“文档更新后怎么维护”的问题。传统做法是全量重建增量编译的思路则完全不同只对新增和修改的文档做第 3 到第 7 轮的流程然后合并进已有图谱和索引。这里的核心工程问题是冲突处理。新文档说“项目 A 不再使用 Redis”旧图谱里却是“项目 A 使用 Redis”。如果直接合并新增节点会产生自相矛盾的知识图谱。实践中的方案是关系带上版本号和状态字段新关系写入时标记旧关系为 superseded已取代而不是物理删除。这样既保留了历史又能回答“当前状态”的问题。第 10 轮上线运营除了常规的部署监控之外要特别重视反馈闭环用户对每个回答的行为数据点赞、点踩、追问回流到评测集成为下一轮评估的种子数据。LLM Wiki 不是一个一次性交付的项目它是一个需要持续运营的知识系统。5. 环境准备与工具链安装下面进入实操环节。先说明环境基线版本细节请以实际安装为准本文重点演示通用思路。硬件建议如果使用云端 API8GB 内存的普通开发机即可完成全部流程。如果要私有化部署 DeepSeek 模型做推理建议 GPU 显存不低于 24GB具体取决于模型参数量。软件清单Python 3.10Node.js 18 和 pnpmDeepSeek Harness 常见安装依赖Neo4j Community Edition 5.x向量数据库可选 ChromaDB轻量演示或 Elasticsearch生产DeepSeek API Key或本地推理服务地址5.1 安装 DeepSeek Harness以官方文档为准# 确认 Node 与 pnpm 环境 node -v pnpm -v # 以 npm/pnpm 全局方式安装具体命令和包名以官方文档为准 pnpm add -g dsh # 启动 Web 控制台 dsh web如果你的版本没有dsh命令或者安装后卡在pnpm dsh web不要硬试。优先检查三件事确认全局 bin 目录是否加入了 PATH启动时端口是否被占用首次启动是否在下载初始化依赖。桌面版Studio通常在官网 Release 页面或应用商店提供安装包安装后直接启动即可。5.2 安装 Neo4jNeo4j 在 Linux 和 macOS 上可以用包管理器安装Windows 可以下载安装包。安装后启动服务默认控制台地址是http://localhost:7474默认账号密码都是neo4j首次登录会强制修改密码。# macOS 使用 Homebrew 安装 brew install neo4j # Linux 使用包管理器安装后启动 sudo systemctl start neo4j5.3 安装 Python 依赖pip install openai neo4j chromadb这些库分别用于调用 DeepSeek API、连接 Neo4j 图数据库、操作向量索引。6. 核心代码实现这一节给出四个可以直接跑的代码骨架知识图谱构建、可溯源问答、增量索引、在线评估。每个示例都做了简化核心逻辑完整保留。6.1 知识图谱构建Python Neo4j# 文件路径scripts/build_graph.py import json from neo4j import GraphDatabase # 连接参数建议放到环境变量或配置中心不要硬编码 NEO4J_URI bolt://localhost:7687 NEO4J_USER neo4j NEO4J_PASSWORD your-password def create_entity(tx, entity): query MERGE (e:Entity {name: $name}) SET e.type $type, e.description $description tx.run(query, nameentity[name], typeentity[type], descriptionentity.get(description, )) def create_relation(tx, source, relation, target): query MATCH (a:Entity {name: $source}) MATCH (b:Entity {name: $target}) MERGE (a)-[r:REL {type: $relation}]-(b) tx.run(query, sourcesource, relationrelation, targettarget) if __name__ __main__: # 第4轮LLM抽取结果 with open(data/entities.json, r, encodingutf-8) as f: data json.load(f) driver GraphDatabase.driver(NEO4J_URI, auth(NEO4J_USER, NEO4J_PASSWORD)) with driver.session() as session: for entity in data[entities]: session.execute_write(create_entity, entity) for rel in data[relations]: session.execute_write( create_relation, rel[source], rel[type], rel[target] ) driver.close() print(知识图谱构建完成)这段代码的核心是MERGE语句它的含义是“存在就匹配不存在就创建”。这是图数据库做增量更新的基础——重复执行不会产生重复节点。关系也是同理用MERGE避免重复边。6.2 可溯源问答DeepSeek API 引用标注# 文件路径rag_qa.py from openai import OpenAI client OpenAI( api_keysk-xxx, # 替换为你的 DeepSeek API Key base_urlhttps://api.deepseek.com/v1 # OpenAI 兼容接口 ) def ask_with_citation(question, context_docs): # context_docs: [{content: ..., source: doc_001}, ...] context_text \n\n.join( f[{i1}] {doc[content]}\n来源{doc[source]} for i, doc in enumerate(context_docs) ) system_prompt ( 你是企业知识库问答助手。回答必须基于提供的参考材料。 每条回答末尾必须标注引用编号禁止编造参考材料没有的内容。 ) messages [ {role: system, content: system_prompt}, {role: user, content: f参考材料\n{context_text}\n\n问题{question}} ] resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.2, # 知识问答用低温度减少随机性 ) return resp.choices[0].message.content这里有两个关键设计。第一是temperature0.2知识问答场景宁可回答“不知道”也不编造低温度能显著降低幻觉概率。第二是引用编号机制它把“答案”和“证据”强行绑定到一起——如果模型在回答里写了[1]那么[1]必须对应参考材料里的一个来源。工程上可以进一步做引用校验检测模型是否把出处标错了。6.3 增量编译与索引更新# 文件路径incremental_index.py # 基于 ChromaDB 的增量索引示例API 版本以实际安装为准 import chromadb class IncrementalIndex: def __init__(self, persist_path./chroma_db): self.client chromadb.PersistentClient(pathpersist_path) self.collection self.client.get_or_create_collection( namellm_wiki, metadata{hnsw:space: cosine} ) self._loaded_ids set() self._load_processed_ids() def _load_processed_ids(self): # 生产环境应从数据库或文件读取已处理文档 ID 的快照 # 这里简化为从已存在集合中获取 try: existing self.collection.get(include[])[ids] self._loaded_ids set(existing) except Exception: self._loaded_ids set() def upsert_document(self, doc_id, text, metadata): # 已处理过且内容相同的文档跳过 if doc_id in self._loaded_ids: return False self.collection.upsert( ids[doc_id], documents[text], metadatas[metadata] ) self._loaded_ids.add(doc_id) return True # 使用示例 # index IncrementalIndex() # index.upsert_document(doc_100, 新增文档内容..., {source: doc_100})增量编译的核心逻辑就是这个upsert——相同的文档 ID 写多次不会产生重复新的文档 ID 直接追加。生产环境比这复杂需要处理文档修改、删除、版本对比但这个骨架已经把最重要的“只处理增量”的思路体现出来了。6.4 在线评估脚本# 文件路径evaluate.py import random from openai import OpenAI client OpenAI( api_keysk-xxx, base_urlhttps://api.deepseek.com/v1 ) EVAL_PROMPT 你是问答质量评估员。请从四个维度对回答打分1-5分 - 准确性事实是否正确有没有幻觉。 - 完整性是否充分回答了问题。 - 可溯性引用或证据是否能支撑答案。 - 简洁性是否冗余。 只输出 JSON不要解释 {accuracy: 0, completeness: 0, traceability: 0, conciseness: 0} def evaluate_answer(question, reference_answer, model_answer): prompt f 问题{question} 参考答案{reference_answer} 模型回答{model_answer} {EVAL_PROMPT} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0 ) return resp.choices[0].message.content if __name__ __main__: # 从评测集中随机抽取N条 eval_set json.load(open(data/eval_set.json, encodingutf-8)) sample random.sample(eval_set, min(20, len(eval_set))) scores [] for item in sample: model_answer ask_with_citation(item[question], item[docs]) result evaluate_answer( item[question], item[reference_answer], model_answer ) scores.append(json.loads(result)) print(f平均分{sum(s[accuracy] for s in scores) / len(scores):.2f})评估这件事核心思想是“先有评测集才有优化权”。没有评测集的 LLM 应用优化就是玄学有了评测集之后每次改动都能看到分数的变化这才是工程化。7. 运行结果与效果验证按照前面顺序执行你会看到几个关键输出节点。7.1 图谱构建运行python scripts/build_graph.py后预期输出知识图谱构建完成然后打开 Neo4j Browserhttp://localhost:7474执行MATCH (n) RETURN n LIMIT 25;如果能看到带标签的节点和关系说明第 4-5 轮图谱构建成功。如果图结果为空回到第 4 步检查entities.json是否为空再检查 Neo4j 连接参数是否正确。7.2 增量索引运行增量索引脚本后检查./chroma_db目录是否生成并确认对同一文档重复执行不会重复添加。这一步验证失败往往是 ChromaDB 的 API 版本差异优先看错误日志中提示的方法名是否在当前版本存在。7.3 可溯源问答调用ask_with_citation预期的回答格式应该是包含引用编号的完整答案。验收标准是回答中的每个[n]都能对应输入的context_docs[n]。如果回答没有引用说明系统提示词里的引用要求被模型忽略了可以把引用格式要求放到用户消息的末尾模型对靠近问题处的指令遵从率更高。7.4 在线评估运行python evaluate.py预期输出一个平均分。如果准确性平均分低于 4 分最优先排查的不是模型而是上下文中是否混入了不相关或过时的文档。知识问答中 80% 的坏答案都源于坏上下文。8. 常见问题与排查思路这里整理一套实战中更容易踩到的问题清单。问题现象可能原因排查方式解决方案DeepSeek Harness 安装后dsh命令找不到全局 bin 目录未加入 PATH执行npm bin -g查看路径将输出目录加入 PATH或改用 npx 调用启动dsh web卡住不动首次初始化下载依赖或端口被占用查看终端输出和系统端口占用等待初始化完成检查 3000/8000 等端口是否被占用DeepSeek API 调用返回 401API Key 错误或余额不足检查请求日志和 Key 配置重新生成 Key确认 base_url 正确Neo4j 中查不到关系抽取的三元组没有写入或 MERGE 匹配失败先查实体是否存在检查entities.json格式确认实体名称无空格差异实体抽取出现大量同义不同名提示词没有归一化约束查看抽取结果中的实体列表在提示词中加入归一化约束或者增加规则/向量去重问答回答没有引用编号系统提示词约束不生效检查模型输出把引用格式要求放到用户消息末尾降低 temperature增量更新后问题答案仍然过期旧关系没有标记 superseded查看图谱中同一关系的多条状态增加状态字段新关系写入时标记旧关系为 superseded评估得分低但人工觉得没问题评测集问题或参考答案有偏抽样人工复核检查评测集的 question 和 reference_answer 是否需要更新向量检索召回质量差文档切分策略不合理检查切片大小和重叠度过短切片召回噪声大过长切片语义不聚焦需要调参下载依赖很慢网络问题或镜像源缺失查看 pnpm/npm 下载日志配置国内镜像源或使用离线依赖包排查的底层思路是先定位是哪一层出了问题。LLM Wiki 是分层的架构同一个“答案不对”的症状可能来自索引层、图谱层、生成层或评估层。不看分层直接调模型是最常见的返工原因。9. 最佳实践与工程建议最后这组实践建议来自实际项目里最值得复用的经验。先建评测集再建知识库。很多团队先搭系统再补评测集结果优化时没有基准。正确顺序是第一批文档清洗完后先人工标注 50-100 条问答对作为种子评测集后面的每一步修改都以评测集分数为准绳。知识图谱要保留历史版本。工业级知识库每天都在变。给实体和关系加valid_from、valid_to、status字段让图谱支持“当前快照”和“历史回溯”两种查询模式。很多合规审计场景要求看到某个时间点的知识状态没有版本历史根本无法回答。LLM 只做抽取不做决定。实体关系的合并、冲突解决、图谱写入最终应该由规则和人工审核决定。LLM 负责提出候选工程系统负责把关。这个边界不划清图谱会随着 LLM 升级而出现不可控的漂移。溯源是系统设计不是提示词设计。不要指望模型“记住”引用。把引用作为输入的一部分传给模型让答案中的每个编号都能在系统层面回查。系统层检查引用的合法性比模型自觉可靠得多。生产环境对 DeepSeek 模型的推理精度要有感知。同样的模型用 fp16 还是 bf16 部署在长文本生成和复杂抽取任务上表现会有细微差异。上线前要固定推理精度并在评测集上跑一遍基线避免“换了个部署方式效果变了”的诡异问题。把提示词也纳入版本管理。提示词是代码的一部分。使用 Git 管理提示词变更每次修改都要关联评测集分数。否则会出现“上周还好好的这周变差了”却找不到原因的情况。访问控制要单独设计。LLM Wiki 部署到局域网后如果允许团队其他人访问需要设置鉴权。最简单的方式是在 Nginx 层做反向代理和 Basic Auth复杂场景接入公司 SSO。不要裸奔。10. 总结与后续学习方向这篇文章的核心线索是LLM Wiki 不是“文档 问答”的简单组合而是一个有结构、有溯源、有评估、有增量更新机制的知识系统工程。10 轮提示工作流的价值在于把知识库建设从一次性项目变成了可迭代、可验证的持续过程。DeepSeek Harness 负责承载这个过程中最繁琐的编排和评估任务知识图谱负责补足 RAG 缺失的结构化推理能力增量编译解决知识更新的成本问题在线评估让每一步优化都有数据支撑。下一步可以继续深入的方向有三个多跳问答评测集建设当前评测集大多是单文档问题可以研究如何设计跨文档、多跳推理的评测用例这是 LLM Wiki 与普通 RAG 拉开距离的关键。图谱与向量的混合检索策略什么时候走图谱路径什么时候走向量召回如何把两者结果做融合排序这是工程优化的深水区。增量编译中的冲突消解机制关系版本化只是起步更复杂的场景是新旧文档“部分冲突、部分兼容”如何自动判断并生成人工审核工单值得专门设计。把这套流程跑通之后你会明显感觉到知识库系统的天花板已经从“模型聪明不聪明”变成了“工程体系完整不完整”。这篇文章里的代码和模板可以当作起点真正的工业级落地还需要你基于自身业务场景把每个细节打磨到位。建议收藏备用实战时对照排查清单逐步推进。