LLM Wiki、DeepSeek Harness、知识图谱、可溯源问答、增量编译、在线评估这几个词放在一起通常意味着你要做的不是普通文档问答而是一套由大模型参与维护的知识工程系统。我按这条链路做过一轮完整验证核心结论是这套流程能跑通但能不能跑到“工业级”关键不在模型强不强而在文档拆解、图谱建模、增量更新和评估反馈这些工程环节有没有闭环。适合看这篇文章的是想把团队内部文档、技术资料、研究报告做成可检索、可溯源、可持续更新知识库的人。整个流程不要求顶配机器但如果要本地部署模型显存和内存一定要提前算清楚。下面按实际落地顺序拆开讲重点不是把功能列表复述一遍而是把每一步为什么要这么做、跑到什么程度算通过、卡住时先看哪里尽量说透。1. 先搞清楚 LLM Wiki 和 DeepSeek Harness 到底解决什么问题1.1 LLM Wiki 不是“用 ChatGPT 总结网页”很多人看到 LLM Wiki 第一反应是把一堆文档丢给大模型让它能回答文档里的问题。这个理解不算错但会把后面的工程设计带偏。普通文档问答是“你问我答”模型检索到相关片段然后生成回答。它不关心文档之间有什么关系也不关心同一个概念在不同文档里有没有矛盾更不关心修改一篇文档后哪些回答会受影响。LLM Wiki 的思路更像是让大模型参与维护一个“持续演化的维基百科”。它不只是回答问题还会把分散在文档里的实体、关系、观点抽出来建立索引和链接并且随着源文档变化不断更新。Andrej Karpathy 在社区里提过类似范式核心价值不是做一个聊天机器人而是把知识沉淀成一个可查询、可追溯、可增量更新的结构。所以判断你是否真的需要 LLM Wiki可以看一个问题你的知识库是不是经常更新如果文档一年都不变一次全量重建也能接受。如果每周都有新文档、旧文档被修订那就需要增量编译。如果多个文档讲同一个项目或同一套系统还需要知识图谱来记录它们之间的引用和依赖。1.2 DeepSeek Harness 在流程里承担什么角色DeepSeek Harness 不是一个能直接给出答案的模型它更像一个编排层负责把多轮提示、知识图谱写入、增量编译、在线评估这些环节串起来。面向 DeepSeek 这类模型Harness 可以管理调用方式、提示模板、输出校验和任务队列。可以这样理解模型解决“这段文字怎么理解”Harness 解决“这段理解怎么落进知识库、怎么更新、怎么验证”。如果你自己写代码也能做但会花很多时间在处理流程上。Harness 的价值是让你把精力集中在业务文档和质量调优上。不过这里要补充一个边界不同版本的 DeepSeek Harness 在功能范围、插件机制、Web 界面和桌面版支持上不完全一样。安装之前最好先看一下仓库或官方文档里的说明确认它支持的是 API 接入还是本地模型部署避免装完之后发现跑不通。2. 环境准备从安装到第一条任务跑通2.1 安装前先看依赖和版本边界我的建议是先装一个最简环境不要一上来就配全套。DeepSeek Harness 这类基于 Node.js 生态的工具通常依赖 Node.js、pnpm还有可能依赖 Docker 和 Neo4j。Node.js 版本对构建影响比较大版本过老或过新都可能导致依赖安装失败。可以先按项目文档指定的版本装再用node -v和pnpm -v确认。知识图谱部分如果选择 Neo4j最常见的做法是用 Docker 起一个容器方便重置和备份。命令类似# 示例实际端口、账号、版本以你的环境为准 docker run -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTHneo4j/yourpassword \ neo4j:latest这里最容易忽略的是Neo4j 的 HTTP 端口 7474 和 Bolt 端口 7687 是否都被放行。如果只放行 7474网页能打开但程序连接会失败。模型接入有两种方式。一种是使用 DeepSeek API省去本地显存压力另一种是本地部署模型把模型权重放到本地通过 OpenAI 兼容接口或本地推理服务暴露给 Harness。如果你的机器配置不高端建议先走 API 方式跑通流程再考虑本地部署。如果本地部署还要留意模型精度问题。fp16、bf16、fp32 是常见的权重精度fp32 占用最高fp16 和 bf16 能省显存但不同硬件对 bf16 的支持不一样。不要只看模型参数量还要看量化后实际需要的显存。一个常见思路是先小模型跑通再逐步切换到大模型对比回答质量和资源占用。2.2 常见的“卡住”不是死机安装过程中很多人会遇到pnpm dsh web卡住不动。这种情况不见得是死机更常见的是首次启动 Web 界面时要下载前端依赖、编译静态资源或连接数据库。如果机器网络一般耗时会比较长。判断方法是先看 CPU、内存、网络流量。如果程序还在产生 CPU 占用或网络流量就再等一段时间。如果完全没有任何活动再考虑清理 pnpm 缓存或重新安装依赖。可以通过日志确认卡在哪一步通常排查顺序是看启动命令是否进入服务监听状态。看是否在下载依赖网络是否稳定。看 Neo4j 是否已经启动连接信息是否正确。看端口是否被占用程序没有报错但访问不了页面。如果以上都没问题换一个 pnpm 镜像源或重新执行安装命令。2.3 先把最小链路跑通安装完成之后不要直接导入整批文档先跑一条最小链路。比如只处理一个 Markdown 文件把它加入文档目录。触发一次构建。确认文档被解析出来。确认实体和关系被写入图谱。在问答界面问一个与该文档直接相关的问题。确认回答里能提供来源。这一步全通过后面再扩大规模。如果第一步就跑不通问题一般出现在格式解析、文件路径或模型接口上先处理这些基础问题。注意不要一开始就开大并发批量处理。做知识库构建不是越快越好因为很多错误会在批量处理时被放大到时候你很难判断是文档问题、模型问题还是流程问题。3. 知识图谱建模文档怎么变成实体和关系3.1 实体和关系不是越多越好知识图谱不是要把文档里所有名词都变成节点。那样做出来的图看似庞大提问时却很难用。真正有价值的是围绕“问答和溯源”来建模。我一般会保留五类基础节点文档节点记录文件路径、标题、更新时间、MD5。片段节点一段可以被单独引用的内容比如段落、章节。实体节点项目、系统、模块、人名、组织、产品等。关系节点/关系边表示实体之间的关联比如“依赖”“负责”“引用”“属于”。观点或结论节点记录文档里提出的结论、判断、疑问。这样设计的好处是当用户问“A 模块会不会影响 B 模块”回答可以从关系边中找到依赖链再由关系边找到对应的片段节点最后回到原文。如果你的内容涉及股权关系、科研论文引用这类场景这套结构会特别有用因为它能把“谁提到谁”“谁依赖谁”这种隐性信息显式化。创建节点时最好给每个片段一个唯一 ID。这个 ID 同时要写进图谱和文档索引里后续溯源问答直接靠它回查原文。3.2 用提示词让模型做结构化抽取从文档生成图谱不是让模型写一段总结而是让模型返回结构化数据。下面是一个通用提示模板方向请从下面的文档片段中抽取实体和关系。 要求 1. 只抽取明确出现在原文中的信息。 2. 每个实体必须有名称和类型。 3. 每个关系必须有两个实体、关系类型和一句话依据。 4. 不确定的信息不要输出。 5. 返回 JSON不要附加解释。模型输出可以是[ { entity: A服务, type: 系统, aliases: [服务A] }, { entity: B服务, type: 系统, aliases: [服务B] }, { source: A服务, relation: 依赖, target: B服务, evidence: A服务在启动时会调用B服务的接口 } ]拿到 JSON 之后不要直接入库。要做两步校验格式校验和冲突校验。格式校验可以看 JSON 能不能解析、字段是否完整。冲突校验看图谱里是不是已经有同名但不同类型的问题。这一步最容易出现的问题是模型会脑补关系。比如原文只说“A 和 B 部署在同一台机器”模型可能输出“A 依赖 B”。解决方式很直接提示里必须要求“依据原文”并且在入库前检查 evidence 字段是否真的在原文片段里出现如果没有就不要写入。3.3 用 Neo4j 承载图谱Neo4j 适合保存这类实体关系数据。写入图谱的 Cypher 示例可以这样组织// 示例创建实体节点 MERGE (e:Entity {name: A服务}) SET e.type 系统 // 示例创建关系 MATCH (a:Entity {name: A服务}) MATCH (b:Entity {name: B服务}) MERGE (a)-[r:DEPENDS_ON]-(b) SET r.evidence A服务在启动时会调用B服务的接口这里用MERGE而不是CREATE是为了避免重复创建。每次增量编译时旧的实体可能已经存在用MERGE可以保留身份只更新属性和关系。需要注意的是Neo4j 不是必需项。文档量很小用邻接表或者 JSON 文件也能跑。但一旦文档超过几千个片段关系查询、引用链追踪和增量更新会变得很麻烦。图数据库真正的价值在“多跳查询”场景比如“C 模块间接依赖哪些服务”用关系型数据库要写递归查询图数据库会更直观。4. 10 轮提示编排把一次生成拆成可验证流水线4.1 为什么要用多轮而不是一段超长提示“10 轮提示”是标题里最容易被误解的部分。它不是让你连续问模型十个问题而是把一个复杂的知识构建任务拆成 10 个有输入、输出、校验步骤的环节。拆开的好处有三个错误容易定位。如果最后问答不对可以回看是哪一轮的抽取、清洗、建模出了问题。上下文不会无限膨胀。每一轮只需要处理当前任务不用把整个文档塞进一次提示。可以插入规则校验。每一轮输出之后先跑校验再进入下一轮。如果只用一段超长提示让模型一次性完成“抽取实体、构建图谱、生成问答、设计溯源”很可能输出格式混乱也很难做局部重跑。4.2 十轮流程的参考拆分下面是一个面向 LLM Wiki 构建的通用十轮流程可以根据自己的文档类型调整轮次输入输出校验方式1原始文档清洗后的文本编码、长度、标题结构2清洗文本片段切分片段大小、重叠范围3片段列表块级摘要摘要是否覆盖片段关键点4片段摘要候选实体实体是否需要合并5候选实体实体关系是否有原文依据6实体关系知识图谱写库结果节点、关系是否落库7图谱片段问答对问题是否可被证据回答8问答对溯源链证据是否能追溯到原文9问答对反馈评估结果指标是否符合阈值10评估结果增量更新状态是否需要重跑或修复这个流程的重点不是轮次数量固定而是每一轮都有明确的“可验证出口”。如果第 4 轮抽出来的实体质量差后面的关系抽取也会跟着乱。所以我建议每一轮输出都保留日志。4.3 每轮提示都要有输出规范和校验方式提示里不能只写“请认真分析”要写清楚输出格式。尤其是涉及 JSON 或结构化数据时最好在提示里给出一个模板并说明字段含义。校验也不是可选项。我自己调试时经常看到第 6 轮报错最后发现是第 3 轮输出的片段切分有问题很多片段之间缺少上下文。这样的问题只有在每轮都留校验日志时才能快速定位。可以使用的通用校验规则文本类型字段不能为空。实体名称不能超过 50 个字符。关系必须有 source、relation、target 三个字段。证据片段必须能在原文中找到近似匹配。同一个文档的片段 ID 不能重复。这些规则可以用一个简单的脚本执行不通过就丢回给模型重试或者跳过该片段并记录到日志。在实际项目里10 轮可能不够也可能用不了那么多。更合理的做法是把流程做成可插拔的 Worker每一轮就是一个小模块模块之间通过文件或数据库传递数据。这样即使以后换模型也不用推翻整个流程。5. 增量编译源文档变了只重建受影响部分5.1 全量重建虽然简单但扩展性差第一次构建知识库时全量编译最省事。把几百个文档全部处理一遍生成图谱和索引再跑一遍评估结果清晰。但全量重建不适合长期维护。原因有三个耗时文档数量增长后每次全部重跑会浪费大量算力。资源占用批量推理会让 GPU 或 API 调用量飙升成本不好控制。不可控全量重跑时原本已经稳定的内容可能因为模型输出波动而发生变化导致线上回答不稳定。增量编译的目标是源文档只改了一小部分系统也只重算这一小部分并且把影响传递给相关的问答和评估结果。5.2 增量编译的判断依据增量编译常见依据有三种文件修改时间文件变了就重新处理。文件哈希内容变了才重新处理避免只改权限也触发全量。依赖关系某个实体或片段变更后所有引用它的问答对都要重新评估。建议至少用文件哈希因为修改时间不可靠。比如 git 切换分支后文件 mtime 会变但内容可能没变。哈希方式更稳。可以用类似下面的流程扫描文档目录 - 计算每个文件的 MD5 - 对比上一次构建记录 - 如果 MD5 没变跳过 - 如果 MD5 变了重新解析该文件 - 找出与该文件相关的实体、关系、问答对 - 只重建这些节点和索引5.3 变更传播的最小示例假设你有一份项目周报里面有一段提到“A 服务已经完成升级不再依赖 B 服务”。这个文档变更后影响的不仅是这一段本身还包括所有基于“A 依赖 B”生成的问答。增量编译需要做的是变更受影响内容处理方式段本文修改该片段摘要、实体抽取结果重新处理该片段实体合并或删除图谱节点、关系边更新图谱关系变化依赖链查询结果重新生成相关问答对问答对变化评估集、溯源链重新评估这里最容易漏的是“旧关系没有被删除”。如果只新增A 不再依赖 B的关系却没有删除旧的A DEPENDS_ON B关系图里会同时存在矛盾信息。所以增量编译不能只做加法还要做差集比较。5.4 增量编译常见坑第一个坑是只更新文档不更新摘要和实体。这样会出现“文档内容已经是新的但图谱里还是旧数据”的情况问答自然会出错。第二个坑是节点残留。文档被删除后图谱里的实体和关系如果没有同步清理会导致回答引用一个不存在的文档。建议在构建记录里保存“文档 ID - 实体 ID、关系 ID”的映射删除文档时连带清理。第三个坑是覆盖范围不确定。一个实体被多个文档引用时修改其中一个文档不能只重算这个文档。要沿着关系边找出所有引用了该实体的片段一起加入重建队列。增量编译跑完之后最好输出一份变更报告包括处理了哪些文件、新增了多少实体、更新了多少关系、删除了哪些节点。报告积累多了你就能看清系统在哪些地方反复变动也能提前发现数据质量问题。6. 可溯源问答回答怎么带证据6.1 没有溯源的问答在工程里很难信任在大模型知识库里最怕的不是回答不了而是答错了还一本正经。为了让回答可验证可溯源问答应作为默认要求每个回答都必须附带证据链证据链要能指向具体文档、具体片段最好还能指向知识图谱中的具体关系。如果不做溯源用户看到一个回答只能凭感觉判断对不对。做了溯源之后即使模型偶尔答错也能快速定位错在哪是文档本身矛盾还是模型理解错了还是检索召回错了。6.2 回答结构设计不要直接让模型输出纯文本而是输出一个带证据字段的结构。这个字段可以是 JSON也可以是你定义的 Markdown 扩展语法。参考输出{ answer: A 服务目前在启动时会调用 B 服务接口。, confidence: 0.87, evidence: [ { doc_id: 20250410-weekly, chunk_id: 20250410-weekly-003, text: A 服务在启动时会调用 B 服务的接口来完成初始化。, entities: [A服务, B服务] } ], links: [ { source: A服务, relation: DEPENDS_ON, target: B服务 } ] }用户在前端看到答案时可以把证据片段折叠或展开点击后跳到原文对应位置。这个“点击回原文”的能力是 LLM Wiki 和单纯聊天工具的核心差异之一。6.3 从图谱到证据的检索路径可溯源问答的检索路径一般分三步从用户问题里抽取关键实体。在图谱中找到匹配的实体节点。沿着关系边找到相关片段再回到文档原文。比如用户问“A 服务现在还需要 B 服务吗”系统先识别出实体“A 服务”“B 服务”然后在 Neo4j 中找到它们之间的关系边最后把关系边上的 evidence 字段对应片段拿出来作为回答依据。这种方式的优点是回答不是基于“模糊相似度”而是基于“明确关系链”。如果图谱中没有这条关系边系统可以直接告诉用户“目前没有找到 A 服务和 B 服务之间的依赖记录”而不是强行生成一个回答。6.4 溯源失败时怎么办溯源失败有三种常见情况实体匹配不到。可以尝试别名扩展比如“A服务”和“服务A”要能映射到同一个节点。关系存在但证据片段为空。这是数据质量问题应该把该关系标为“低置信度”在回答里提示用户。检索到多个互相矛盾的证据。这时不要只取一个应该把矛盾点展示出来说明不同文档的说法不一致。我的原则是宁可让回答显得保守也不要让模型强行把人眼已发现的问题掩盖掉。一个能说“我没找到明确依据”的系统比一个硬编答案的系统更可靠。7. 在线评估怎么证明系统一直可用7.1 离线和在线评估要分开很多人只在开发时测几个问题就认为系统“已经可用”。这套胶水方案能支撑 Demo但撑不住长期迭代。离线评估是固定的测试集在每次构建或增量编译后跑一遍用来发现回归。在线评估是用户真实使用时的反馈用来发现离线测试集覆盖不到的盲区。两者要同时做。离线评估保证“改完没有变差”在线评估保证“真实用户场景里能回答问题”。7.2 可以跟踪的核心指标下面这些指标比较适合 LLM Wiki指标计算方式说明溯源命中率回答中带成功溯源的比例没有溯源等于不可验证完整率问题是否覆盖了所有关键证据只看一句回答容易漏背景无答案准确率无法回答时是否正确拒绝比硬答更值得关注用户反馈通过率用户点击“有用/无用”的比率在线体验的直接信号增量回归通过率每次增量后测试集通过比例防止改一处坏一片不需要一开始就追求所有指标都很高。建议先盯“溯源命中率”和“用户反馈通过率”这两个指标直接反映可溯源问答做得如何。7.3 评估数据从哪来评估数据可以从三处收集历史问答日志用户真的问过的问题长期积累最有价值。人工标注集由业务人员编写一批标准问题和参考答案覆盖核心场景。失败案例回流用户觉得回答不对时把该问题加入评估集防止以后再次踩坑。在在线评估模块里应该允许用户对回答标注“有用”“无用”“证据不对”“文档过期”等选项。不要只是收集一个点赞数还要记录用户跳转到哪些证据片段这个行为能帮助判断检索和排序是否合理。7.4 把评估接入增量编译流程增量编译跑完之后不要只看“构建成功”还要自动跑一遍回归测试集。如果某个原本通过的问题在这次增量后失败了系统应该能定位到变更内容判断是修改文档导致的正常变化还是构建流程引入的 bug。可以设计一个简单的回归流程增量编译完成。从变更报告里提取受影响的实体和问答对。只跑这些问答对的回归测试。如果失败则回滚当前增量或单独修复。更新在线评估日志记录本次失败案例。这相当于给知识库做了一个持续集成。每次改动都有验证每次验证都会反馈回数据。在线评估不是“上线后看数据”的被动功能而是和增量编译绑定在一起的主动质量闸门。8. 从 Demo 到“工业级”还要补哪些东西8.1 工业级不是模型强而是可运维很多团队在 Demo 阶段能跑通到了生产环境就崩问题通常出在可运维性上。至少需要补这些能力日志每一轮提示、每次模型调用、每次图谱写入都要有日志。任务队列批量处理时不能一个线程硬跑到底要用队列控制并发和重试。错误重试模型调用超时、Neo4j 连接闪断、文件编码异常都要有重试策略。权限控制不同角色能访问哪些知识库至少要有基础限制。备份恢复图谱、文档索引、构建记录要定期备份。输出一致性同一个问题在不同时间回答不能差异过大。可参考做法是固定模型温度并把关键结果缓存。这些能力听上去很基础但缺一个都可能在长期运行时变成事故。8.2 需要注意的模型精度与部署边界本地部署时模型精度直接影响资源占用和回答效果。fp32、fp16、bf16 的区别主要在于数值范围和显存占用。fp32 最保守但显存占用高fp16 能省一半显存但某些硬件上可能出现数值溢出bf16 在部分新硬件上更稳但老硬件不一定支持。不要只看“模型支持 bf16”就盲目开启先确认你的显卡和推理框架兼容性。更稳妥的方式是用一个包含数字、日期、单位、代码的测试集在不同精度下各跑一遍对比关键内容是否出错。如果使用 DeepSeek API 方式模型由服务端管理本地主要关注请求并发、超时和成本控制。建议设置一个请求速率上限避免某个批量任务把整个调用额度耗尽。8.3 插件、桌面版和团队协作的选择如果是个人学习可以用 DeepSeek Harness 的桌面版或 Web 界面把构建过程可视化方便跟踪。如果是团队使用我建议优先考虑命令行和配置文件方式。因为桌面版适合演示不适合脚本化、自动化和权限管理。插件机制则可以帮你扩展文档解析格式、评估指标、通知渠道等能力。另外如果你只是需要一个轻量的本地文档问答工具AnythingLLM 这类产品会更省事。它不是要替代什么而是定位不同AnythingLLM 偏重“上传文档直接聊天”LLM Wiki 偏重“结构化、可溯源、增量更新”。先想清楚自己到底要哪种再选工具能少走很多弯路。8.4 最后的落地建议如果让我重新做一遍这个项目我会严格按照下面的顺序推进先用 5 个文档跑通最小链路。人工检查实体、关系、问答质量和溯源链。加入增量编译模拟修改一个文档验证受影响内容是否被重建。固定 20 到 50 个测试问题跑离线评估。上线给少量用户使用收集反馈。根据反馈不断修正提示模板和抽取规则。最后才扩大到全量文档。不要跳过第 2 步。很多人觉得模型能力强不需要人工检查结果生成了一堆错误事实后面纠正成本更高。最后留一个判断标准如果你能回答“最近一次增量编译改了哪些内容、影响了哪些问答、评估指标是升还是降”这三个问题这套 LLM Wiki 才算真正进入了可用状态。否则它只是一堆自动化流程的堆叠离“工业级”还有距离。