这次我们来看一个把知识库做成工业级工具链的方案DeepSeek Harness 构建 LLM Wiki。它不是简单做一个“文档问答机器人”而是把知识库的构建、索引、问答、更新、评估串成一条完整流水线。核心能力是知识图谱、可溯源问答、增量编译、在线评估四个模块配合提示词迭代把散乱文档变成有结构、可追溯、可增量维护的知识资产。这篇文章会直接讲清楚DeepSeek Harness 是什么、凭什么能做工业级 LLM Wiki、10 轮提示迭代怎么落地、知识图谱怎么构建、可溯源问答怎么设计、增量编译和在线评估怎么实现以及环境准备、API 调用、资源占用、常见问题排查。如果你正在做私域知识库、团队文档问答、RAG 增强、企业智能问答或者想用 LLM 管理大量技术文档这篇内容可以直接作为落地参考。1. 核心能力速览能力项说明项目类型LLM 知识库工具链围绕 LLM Wiki 范式构建核心功能知识图谱构建、可溯源问答、增量编译、在线评估工作流模式多轮提示词驱动从文档到知识图谱再到问答闭环启动方式命令行、Web 端、桌面端具体以实际发布版为准依赖管理社区使用中常见 Node/pnpm 工程结构知识存储文档源 分块索引 图谱关系存储是否支持 API从工具链服务化设计看支持接口调用需以实际文档为准是否支持批量任务增量编译和在线评估天然适合批量处理硬件要求取决于所接入的 LLM 和向量化服务需按实际环境测试适合场景技术文档知识库、研发规范问答、产品 FAQ、运营资料归集从材料看这套工具的核心价值不是“多轮对话”而是把知识库当作一套可持续编译、可回归评估的工程系统。这和传统“把 PDF 灌进向量库就完事”的思路有明显区别。2. 适用场景与使用边界DeepSeek Harness 适合的典型场景有以下几类团队内部技术文档库把分散的 Markdown、Confluence、Notion 文档统一成知识图谱支持研发问答和规范检索。产品与运营 FAQ把产品说明、常见问题、客服话术转化为可溯源问答回答时能指出出处。研发规范与审计需求需要回答结果可回溯到具体文档章节方便后续人工复核。持续更新的文档库文档每周都在变不能每次全量重建需要增量编译机制。不适合的场景也要说清楚轻量级个人笔记检索单文件、低数量、不追求溯源用简单 RAG 或本地搜索更省事。海量实时流式数据问答知识图谱构建有延迟不适合即时抓取并回答。没有内容授权或数据脱敏条件不建议把敏感、版权不明的内容直接灌进知识库。合规边界必须注意。知识库里的内容可能来自第三方文档、内部培训材料或他人原创文章构建前要确认内容授权和来源合法。涉及个人信息、商业机密的内容需要做脱敏处理。可溯源问答虽然方便复核但不能替代人工审查对外发布和商用前必须做效果复核不能把模型生成内容当成权威结论直接发布。3. LLM Wiki 思路与 DeepSeek Harness 的模块关系LLM Wiki 的核心思想是让 LLM 从“只会聊天”变成“能维护一份动态知识库”。传统 Wiki 靠人维护词条LLM Wiki 靠提示词和工具链自动抽取实体、关系、摘要、引用再按需求更新和维护。DeepSeek Harness 是这个思路的工程化实现。从网络检索材料看它和 Karpathy 提出的“LLM Wiki 范式”有关社区讨论里也常把它看作把文档编译成知识库的工具。整体模块关系可以理解为文档采集与清洗 ↓ 文档分块 元数据标注 ↓ 实体/关系抽取知识图谱构建 ↓ 图谱存储 向量索引 ↓ 可溯源问答检索 图谱查询 答案生成 ↓ 增量编译变更检测 局部重建 ↓ 在线评估评估集 指标 回归这套链路中最关键的两个差异点一是“知识图谱”。普通 RAG 只做向量相似度检索回答缺少结构化关系。DeepSeek Harness 会把“员工 A 属于团队 B”“模块 C 依赖服务 D”这类关系抽出来放入图谱。用户问“某个服务影响了哪些模块”图谱可以直接通过关系路径回答而不是靠向量检索拼凑。二是“增量编译”。知识库不是一次性产物。文档更新后只对变更部分重新抽取关系、重算向量而不是整个库重新跑一遍。这对工业级使用非常重要能明显降低更新成本和出错概率。4. 环境准备与前置条件4.1 基础环境检查清单不管具体项目怎么打包建议先确认以下环境项检查项建议操作系统Windows 10/11、Linux、macOS 均可实际看官方支持矩阵Node.js 与包管理器常见工程使用 Node 和 pnpm建议安装 LTS 版 NodePython 环境若涉及本地抽取模型、向量化、评估脚本需要 Python 3.9模型服务接入 DeepSeek API 或本地模型服务确保 key 或 endpoint 可用图数据库可选知识图谱较大时建议使用 Neo4j 等图数据库向量数据库根据项目默认配置选择如 Chroma、Milvus、Qdrant 等磁盘空间按文档量和模型缓存估算建议预留 20GB 以上端口常见 Web 服务端口 3000、7860、8080注意冲突4.2 安装命令示例下面给出一套通用安装流程实际命令需要按项目实际发布信息调整# 克隆项目仓库地址以实际发布为准 git clone project-url cd deepseek-harness # 安装依赖常见工程使用 pnpm pnpm install # 安装 Python 依赖如果涉及本地方案 pip install -r requirements.txt如果下载依赖时速度很慢可以配置 pnpm 镜像源或使用 Python 包镜像源避免直接卡在依赖拉取环节。4.3 模型服务配置LLM Wiki 的核心是 LLM配置模型时要注意# 模型配置文件示例 llm: provider: deepseek api_key: ${DEEPSEEK_API_KEY} model: deepseek-chat temperature: 0.2 embedding: provider: local model: bge-m3 dimension: 1024 graph_db: provider: neo4j uri: bolt://localhost:7687 user: neo4j password: ${NEO4J_PASSWORD}如果使用本地模型还要确认显存和模型精度问题。LLM 推理中 FP16、BF16、FP32 对显存占用和结果精度影响很大本地部署时建议先用小模型跑通再切换大模型。5. 10 轮提示迭代总览标题里的“10 轮提示”不是随便写 10 个 prompt而是一条从文档到知识库再到评估的完整迭代路线。直接看表轮次目标输入输出第 1 轮定义领域边界文档集、需求说明领域范围说明、排除哪些内容第 2 轮设计知识图谱 Schema领域实体、关系、属性示例实体类型、关系类型、属性清单第 3 轮准备种子语料原始文档清洗后的高质量种子文档第 4 轮确定分块策略清洗后文档分块脚本和元数据模板第 5 轮实体抽取提示词文档块结构化实体 JSON第 6 轮关系抽取提示词实体 JSON 文档块关系三元组第 7 轮图谱入库与校验三元组可查询的知识图谱第 8 轮可溯源问答提示词用户问题 图谱证据带引用的答案第 9 轮增量编译机制新文档、变更文档局部重建的索引和图谱第 10 轮在线评估与回归评估问题集指标报告和回归结果为什么是 10 轮因为每一轮都在解决一个独立问题且前一轮的输出是后一轮的输入。比如第 5 轮的实体抽取质量直接决定第 6 轮的关系抽取第 6 轮的三元组质量又决定第 7 轮图谱能不能被问答链路查询。如果直接跳到问答环节后面排查的成本会非常高。每一轮提示词都有固定结构角色约束 输入格式 输出格式 示例。下面重点拆解其中几个关键轮的实战细节。6. 知识图谱构建实战6.1 定义实体与关系 Schema知识图谱不是把文档里的词全部抽出来而是先设计一套适合业务领域的 Schema。假设我们要构建“研发团队文档知识库”可以定义实体类型属性团队成员姓名、岗位、部门服务名称、负责人、技术栈文档标题、路径、更新时间业务模块名称、依赖、负责人规范名称、适用范围、版本关系类型说明USE服务使用某种技术栈DEPENDS_ON模块依赖服务OWNED_BY服务/模块由团队成员负责MENTIONED_IN实体在文档中被提及FOLLOWS规范适用于某个模块6.2 实体抽取提示词模板实体抽取是第 5 轮也是后续所有环节的基础。提示词怎么写很关键你是一个知识图谱实体抽取器。 给定一篇技术文档片段抽取其中与研发团队知识库相关的实体。 要求 1. 只抽取与 Schema 中定义的类型匹配的实体。 2. 输出严格 JSON 数组格式为 [{name: 实体名, type: 实体类型, attributes: {}}] 3. 属性只能从原文中提取不能推测。 4. 没有匹配实体时输出 []。 文档片段 {chunk_text}输出示例[ { name: 订单服务, type: 服务, attributes: { 负责人: 张三, 技术栈: Go } }, { name: 支付模块, type: 业务模块, attributes: { 依赖: 订单服务 } } ]6.3 关系抽取提示词模板有了实体第 6 轮就是抽实体之间的关系你是一个知识图谱关系抽取器。 给定文档片段和实体列表抽取实体之间的关系。 要求 1. 只抽取 Schema 中已有的关系类型。 2. 输出 JSON 数组格式为 [{source: 实体A, relation: 关系类型, target: 实体B, evidence: 原文证据}] 3. evidence 必须是原文中的原句。 实体列表 {entities_json} 文档片段 {chunk_text}关系抽取的核心是“证据”。每条三元组都要能回溯到原文这正是后续可溯源问答的基础。如果关系没有原文证据宁可不入库也不能靠模型脑补。6.4 图谱入库与校验三元组生成后需要写入图数据库。以 Neo4j 为例from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) def create_relationship(tx, source, relation, target): query ( MERGE (a:Entity {name: $source}) MERGE (b:Entity {name: $target}) MERGE (a)-[r:REL {type: $relation}]-(b) ) tx.run(query, sourcesource, relationrelation, targettarget) triples [ {source: 订单服务, relation: DEPENDS_ON, target: 支付模块}, {source: 订单服务, relation: OWNED_BY, target: 张三}, ] with driver.session() as session: for triple in triples: session.execute_write(create_relationship, triple[source], triple[relation], triple[target]) driver.close()入库后要校验统计三元组数量、检查孤立实体、检查关系类型是否合法。从实际经验看最容易出问题的不是抽取而是实体对齐。同一实体在不同文档里写法不同比如“订单服务”和“订单系统”需要做实体归一化。7. 可溯源问答链路知识图谱构建完成后问答就不能只靠向量检索了。理想链路是用户提问。语义检索定位候选文档块。图谱查询获取相关实体和关系路径。把文档证据和图谱证据拼接成上下文。LLM 根据证据生成答案并标注引用来源。7.1 问答提示词设计可溯源问答的提示词要强调“证据优先”和“引用标记”你是企业知识库问答助手。 回答问题前先使用提供的文档片段和图谱证据。 要求 1. 答案必须基于证据不能编造。 2. 每个关键结论后面加上引用标记格式为 [来源ID]。 3. 如果证据不足直接回答“当前知识库中没有找到相关信息”。 4. 保持答案简洁不要展开无关内容。 图谱证据 {graph_evidence} 文档片段 {chunk_evidence} 用户问题 {question}7.2 Python 调用示例import requests url http://127.0.0.1:8080/api/chat payload { question: 订单服务依赖哪些模块, enable_graph: True, enable_rag: True, top_k: 5 } response requests.post(url, jsonpayload, timeout60) print(response.json())预期返回结构{ answer: 订单服务依赖支付模块和用户模块。[DOC_001], references: [ { source_id: DOC_001, title: 订单服务架构说明, chunk_index: 12, evidence: 订单服务依赖支付模块完成交易结算。 } ], graph_paths: [ { source: 订单服务, relation: DEPENDS_ON, target: 支付模块 } ] }从实际使用角度看判断问答链路是否成功的标准有三个答案是否与原文一致、引用是否能定位到具体文档块、图谱路径是否帮助补充了文档中没有直接出现的关联信息。三个条件缺一不可。8. 增量编译机制增量编译是工业级 LLM Wiki 和玩具级知识库的分水岭。只有几千个文档时全量重建可能还行但文档到几万、几十万时全量重建的时间和成本完全不可接受。8.1 增量编译思路核心思想是“变更检测 局部重建”维护一个文档状态表记录每个文档的哈希值、上次编译时间、分块数量。新文档或修改文档时只重新抽取该文档、重算向量、更新图谱。删除文档时只删除该文档涉及的实体关系和向量索引。下游依赖变更时比如 Schema 改了才触发相关范围的局部重建。8.2 配置示例incremental_compile: enabled: true watch_dirs: - ./docs/ - ./specs/ poll_interval_seconds: 60 hash_algorithm: sha256 sqlite_db: ./state.db max_batch_chunks: 200 on_change: [parse, extract_entities, extract_relations, embed, update_graph]8.3 编译流程代码逻辑import hashlib import json def compute_hash(filepath): with open(filepath, rb) as f: return hashlib.sha256(f.read()).hexdigest() def should_compile(filepath, state): current_hash compute_hash(filepath) return state.get(filepath) ! current_hash def compile_document(filepath): # 1. 读取文档 # 2. 分块 # 3. 实体关系抽取 # 4. 更新向量索引 # 5. 更新知识图谱 # 6. 更新状态表 pass增量编译的关键是状态表必须稳定。进程崩溃、数据库损坏、文件重命名都会影响状态判断。稳妥做法是状态表落盘、每批任务记录日志、编译完成后统一提交状态避免半途失败产生脏状态。9. 在线评估与回归没有评估的知识库就是黑盒。在线评估的目的是回答三个问题检索找得到吗答案答得对吗引用给得准吗9.1 构建评估数据集评估数据集建议按真实业务问题整理格式如下[ { question: 订单服务依赖哪些模块, expected_entities: [支付模块, 用户模块], expected_answer_keywords: [支付模块, 用户模块], expected_source_ids: [DOC_001], difficulty: easy }, { question: 服务出现故障应该找谁, expected_entities: [张三], expected_answer_keywords: [张三, 负责人], expected_source_ids: [DOC_003], difficulty: medium } ]9.2 自动化评估脚本import json import requests eval_set json.load(open(eval_set.json)) def evaluate_question(q): response requests.post( http://127.0.0.1:8080/api/chat, json{question: q[question]}, timeout60 ) data response.json() answer data.get(answer, ) refs data.get(references, []) hit_entities any(e in answer for e in q[expected_entities]) has_source any(r.get(source_id) in q[expected_source_ids] for r in refs) return { question: q[question], hit_entities: hit_entities, has_source: has_source, pass: hit_entities and has_source } results [evaluate_question(q) for q in eval_set] pass_rate sum(r[pass] for r in results) / len(results) print(fPass Rate: {pass_rate:.2%})9.3 常见评估指标指标说明实体命中率答案是否包含预期实体来源命中率引用是否包含预期文档答案相关性答案与问题是否相关需要人工抽检图谱支持度答案是否能从图谱路径推导未命中率知识库没有答案时是否正确拒绝在线评估的常见问题是评估集太少。建议每个业务模块至少准备 20 到 50 个问题并定期补充。评估不能只在发布前跑每次增量编译后都要跑回归防止“改一个文档坏一片回答”。10. 接口 API 与批量任务10.1 服务启动如果项目提供服务化启动方式常见模式是# 启动 Web 服务具体命令以实际项目为准 pnpm dsh web如果启动过程卡在pnpm dsh web优先检查依赖是否安装完整、端口是否被占用、启动日志中是否有请求阻塞。10.2 通用 API 调用模板下面给出通用调用模板实际接口路径和参数需要按项目文档调整import requests BASE_URL http://127.0.0.1:8080 # 文档上传示例 def upload_document(filepath): with open(filepath, rb) as f: response requests.post( f{BASE_URL}/api/documents, files{file: f}, data{title: filepath} ) return response.json() # 批量问答示例 def batch_ask(questions): results [] for q in questions: response requests.post( f{BASE_URL}/api/chat, json{question: q}, timeout120 ) results.append(response.json()) return results questions [ 订单服务依赖哪些模块, 支付模块的负责人是谁, 部署流程规范是怎样的 ] answers batch_ask(questions) print(json.dumps(answers, ensure_asciiFalse, indent2))10.3 批量任务设计建议批量任务最容易遇到的问题是大批量请求时服务超时、限流、资源耗尽。建议批量请求控制在 20 到 50 个一组分批执行。每批之间加短暂间隔避免突发流量。记录每个请求的日志包括问题、耗时、状态码、回答摘要。失败的请求自动重试重试最多 3 次。批量完成后汇总异常统一排查。11. 资源占用与性能观察11.1 观察哪些指标运行 DeepSeek Harness 时重点观察以下指标指标观察方式CPU 占用系统监控工具或top、任务管理器内存占用同上注意向量索引常驻内存显存占用nvidia-smi或任务管理器 GPU 信息磁盘 IO增量编译时注意读写接口耗时API 返回时间重点看 p95索引构建耗时单文档分块到入库的耗时图谱更新延迟新文档到图谱可查询的延迟11.2 显存占用与模型精度如果你使用本地 LLM显存占用和模型精度直接相关。FP16 和 BF16 是目前本地部署的主流方式显存占用大约是 FP32 的一半。BF16 的指数范围和 FP32 一致训练和推理稳定性更好FP16 在数值动态范围上有上限容易出现溢出。实际选用哪种精度要看模型的训练方式和推理框架支持情况不能只看显存数字。更稳妥的判断是先用 API 服务把整套流程跑通再根据成本和隐私要求决定是否切换到本地模型。知识图谱构建和增量编译阶段对显存要求不一定高真正吃显存的是大模型的推理和向量化。资源不足时可以外接 API本地只跑检索和图谱查询。11.3 性能优化方向文档分块大小从 512 降到 256检索更准但索引量更大。实体抽取使用小模型问答使用大模型分层推理。增量编译改成事件触发不用轮询。向量索引使用 HNSW 参数调优提高检索速度。图谱查询加缓存高频问题走缓存。12. 常见问题与排查方法问题现象可能原因排查方式解决方案pnpm dsh web启动卡住依赖未安装完整、端口被占、网络请求阻塞查看启动日志检查端口占用重装依赖换端口或检查网络连接依赖下载慢网络源不稳定查看包管理器日志配置国内镜像源使用加速源模型服务连接失败API Key 错误、endpoint 不可达测试模型服务连通性检查配置文件和网络策略实体抽取结果为空提示词约束过严、文档无法解析直接测试单条文档块放宽输出要求检查文档格式三元组没有入库关系类型不符合 Schema查看抽取日志修正关系类型定义回答没有引用来源提示词未强调引用或检索没有返回证据检查上下文是否包含证据片段调整提示词增加检索力度增量编译不触发文档状态哈希未变化、监听目录错误查看状态表和编译日志检查文件路径、状态表评估通过率低评估集和文档口径不一致、提示词不稳定抽检错误case补充评估集优化输出格式显存不足模型过大或推理并发过高nvidia-smi查看显存降低模型规模减少并发或切换 API最值得注意的问题是“实体抽取”和“关系抽取”的稳定性。LLM 输出天然有随机性同样的输入两次结果可能不同。工业级使用一定要做“结构化输出校验”抽取出 JSON 后先做格式校验再做 Schema 校验不合格的重新抽取或人工修复。13. 最佳实践与合规建议13.1 工程实践先把最小闭环跑通一份文档 → 抽取实体 → 建图谱 → 问答带引用 → 更新文档 → 增量编译 → 评估通过。这 7 个步骤都通了再扩大文档量。建议目录结构project/ ├── docs/ # 原始文档 ├── chunks/ # 分块结果 ├── entities/ # 实体抽取结果 ├── relations/ # 关系抽取结果 ├── graph/ # 图谱导入脚本与备份 ├── eval/ # 评估数据集与结果 ├── logs/ # 运行日志 └── state.db # 增量编译状态表批量任务一定要加日志和失败重试。知识库更新不应该静默失败增量编译的每个环节都要有可追踪日志。接口服务要限制访问范围至少做访问控制避免内部知识库暴露到公网。13.2 合规提醒涉及知识图谱、文档检索、可溯源问答时不要忽略内容来源。常见合规风险有两类一是版权风险。文档库中如果包含他人文章、教程、书籍内容构建知识图谱和问答系统时不能直接商用需要确认授权范围。即使是内部使用也要注意来源标注。二是隐私与敏感信息。个人信息、账号信息、内部安全信息不应该进入知识库。建议在文档入库前做敏感信息扫描启用数据脱敏设置访问权限。可溯源问答的“证据”设计反过来也要求系统能定位到具体文档所以必须有审计能力和删除能力——用户要求删除某条数据时图数据库、向量索引和文档副本要能同步清除。14. 总结与下一步DeepSeek Harness 做 LLM Wiki 的完整链路最有价值的点在于把知识库从“能问能答”提升到“可增量维护、可评估回归”的工程系统。10 轮提示迭代作为方法论每一轮都解决一个独立问题最终把文档变成知识图谱加可溯源问答的闭环。如果你要上手最先应该验证的是知识图谱构建和可溯源问答。这两个功能直接决定知识库有没有超出普通向量检索的价值。最容易踩的坑是文档分块策略和实体抽取的稳定性建议先小规模测试再逐步扩大范围。下一步可以尝试的方向包括把评估集扩充到更多业务模块、接入更多向量模型做效果对比、让知识图谱支持多版本文档对比、增加多轮对话中的上下文记忆、将评估结果接入 CI 实现每次文档更新自动回归。增量编译和在线评估都跑通后这套 LLM Wiki 方案才真正具备工业级落地条件。 
长河君 · 2026/9/1 6:15:51 · 阅读 1.2k DeepSeek Harness构建LLM Wiki：知识图谱与可溯源问答实践
这次我们来看一个把知识库做成工业级工具链的方案DeepSeek Harness 构建 LLM Wiki。它不是简单做一个“文档问答机器人”而是把知识库的构建、索引、问答、更新、评估串成一条完整流水线。核心能力是知识图谱、可溯源问答、增量编译、在线评估四个模块配合提示词迭代把散乱文档变成有结构、可追溯、可增量维护的知识资产。这篇文章会直接讲清楚DeepSeek Harness 是什么、凭什么能做工业级 LLM Wiki、10 轮提示迭代怎么落地、知识图谱怎么构建、可溯源问答怎么设计、增量编译和在线评估怎么实现以及环境准备、API 调用、资源占用、常见问题排查。如果你正在做私域知识库、团队文档问答、RAG 增强、企业智能问答或者想用 LLM 管理大量技术文档这篇内容可以直接作为落地参考。1. 核心能力速览能力项说明项目类型LLM 知识库工具链围绕 LLM Wiki 范式构建核心功能知识图谱构建、可溯源问答、增量编译、在线评估工作流模式多轮提示词驱动从文档到知识图谱再到问答闭环启动方式命令行、Web 端、桌面端具体以实际发布版为准依赖管理社区使用中常见 Node/pnpm 工程结构知识存储文档源 分块索引 图谱关系存储是否支持 API从工具链服务化设计看支持接口调用需以实际文档为准是否支持批量任务增量编译和在线评估天然适合批量处理硬件要求取决于所接入的 LLM 和向量化服务需按实际环境测试适合场景技术文档知识库、研发规范问答、产品 FAQ、运营资料归集从材料看这套工具的核心价值不是“多轮对话”而是把知识库当作一套可持续编译、可回归评估的工程系统。这和传统“把 PDF 灌进向量库就完事”的思路有明显区别。2. 适用场景与使用边界DeepSeek Harness 适合的典型场景有以下几类团队内部技术文档库把分散的 Markdown、Confluence、Notion 文档统一成知识图谱支持研发问答和规范检索。产品与运营 FAQ把产品说明、常见问题、客服话术转化为可溯源问答回答时能指出出处。研发规范与审计需求需要回答结果可回溯到具体文档章节方便后续人工复核。持续更新的文档库文档每周都在变不能每次全量重建需要增量编译机制。不适合的场景也要说清楚轻量级个人笔记检索单文件、低数量、不追求溯源用简单 RAG 或本地搜索更省事。海量实时流式数据问答知识图谱构建有延迟不适合即时抓取并回答。没有内容授权或数据脱敏条件不建议把敏感、版权不明的内容直接灌进知识库。合规边界必须注意。知识库里的内容可能来自第三方文档、内部培训材料或他人原创文章构建前要确认内容授权和来源合法。涉及个人信息、商业机密的内容需要做脱敏处理。可溯源问答虽然方便复核但不能替代人工审查对外发布和商用前必须做效果复核不能把模型生成内容当成权威结论直接发布。3. LLM Wiki 思路与 DeepSeek Harness 的模块关系LLM Wiki 的核心思想是让 LLM 从“只会聊天”变成“能维护一份动态知识库”。传统 Wiki 靠人维护词条LLM Wiki 靠提示词和工具链自动抽取实体、关系、摘要、引用再按需求更新和维护。DeepSeek Harness 是这个思路的工程化实现。从网络检索材料看它和 Karpathy 提出的“LLM Wiki 范式”有关社区讨论里也常把它看作把文档编译成知识库的工具。整体模块关系可以理解为文档采集与清洗 ↓ 文档分块 元数据标注 ↓ 实体/关系抽取知识图谱构建 ↓ 图谱存储 向量索引 ↓ 可溯源问答检索 图谱查询 答案生成 ↓ 增量编译变更检测 局部重建 ↓ 在线评估评估集 指标 回归这套链路中最关键的两个差异点一是“知识图谱”。普通 RAG 只做向量相似度检索回答缺少结构化关系。DeepSeek Harness 会把“员工 A 属于团队 B”“模块 C 依赖服务 D”这类关系抽出来放入图谱。用户问“某个服务影响了哪些模块”图谱可以直接通过关系路径回答而不是靠向量检索拼凑。二是“增量编译”。知识库不是一次性产物。文档更新后只对变更部分重新抽取关系、重算向量而不是整个库重新跑一遍。这对工业级使用非常重要能明显降低更新成本和出错概率。4. 环境准备与前置条件4.1 基础环境检查清单不管具体项目怎么打包建议先确认以下环境项检查项建议操作系统Windows 10/11、Linux、macOS 均可实际看官方支持矩阵Node.js 与包管理器常见工程使用 Node 和 pnpm建议安装 LTS 版 NodePython 环境若涉及本地抽取模型、向量化、评估脚本需要 Python 3.9模型服务接入 DeepSeek API 或本地模型服务确保 key 或 endpoint 可用图数据库可选知识图谱较大时建议使用 Neo4j 等图数据库向量数据库根据项目默认配置选择如 Chroma、Milvus、Qdrant 等磁盘空间按文档量和模型缓存估算建议预留 20GB 以上端口常见 Web 服务端口 3000、7860、8080注意冲突4.2 安装命令示例下面给出一套通用安装流程实际命令需要按项目实际发布信息调整# 克隆项目仓库地址以实际发布为准 git clone project-url cd deepseek-harness # 安装依赖常见工程使用 pnpm pnpm install # 安装 Python 依赖如果涉及本地方案 pip install -r requirements.txt如果下载依赖时速度很慢可以配置 pnpm 镜像源或使用 Python 包镜像源避免直接卡在依赖拉取环节。4.3 模型服务配置LLM Wiki 的核心是 LLM配置模型时要注意# 模型配置文件示例 llm: provider: deepseek api_key: ${DEEPSEEK_API_KEY} model: deepseek-chat temperature: 0.2 embedding: provider: local model: bge-m3 dimension: 1024 graph_db: provider: neo4j uri: bolt://localhost:7687 user: neo4j password: ${NEO4J_PASSWORD}如果使用本地模型还要确认显存和模型精度问题。LLM 推理中 FP16、BF16、FP32 对显存占用和结果精度影响很大本地部署时建议先用小模型跑通再切换大模型。5. 10 轮提示迭代总览标题里的“10 轮提示”不是随便写 10 个 prompt而是一条从文档到知识库再到评估的完整迭代路线。直接看表轮次目标输入输出第 1 轮定义领域边界文档集、需求说明领域范围说明、排除哪些内容第 2 轮设计知识图谱 Schema领域实体、关系、属性示例实体类型、关系类型、属性清单第 3 轮准备种子语料原始文档清洗后的高质量种子文档第 4 轮确定分块策略清洗后文档分块脚本和元数据模板第 5 轮实体抽取提示词文档块结构化实体 JSON第 6 轮关系抽取提示词实体 JSON 文档块关系三元组第 7 轮图谱入库与校验三元组可查询的知识图谱第 8 轮可溯源问答提示词用户问题 图谱证据带引用的答案第 9 轮增量编译机制新文档、变更文档局部重建的索引和图谱第 10 轮在线评估与回归评估问题集指标报告和回归结果为什么是 10 轮因为每一轮都在解决一个独立问题且前一轮的输出是后一轮的输入。比如第 5 轮的实体抽取质量直接决定第 6 轮的关系抽取第 6 轮的三元组质量又决定第 7 轮图谱能不能被问答链路查询。如果直接跳到问答环节后面排查的成本会非常高。每一轮提示词都有固定结构角色约束 输入格式 输出格式 示例。下面重点拆解其中几个关键轮的实战细节。6. 知识图谱构建实战6.1 定义实体与关系 Schema知识图谱不是把文档里的词全部抽出来而是先设计一套适合业务领域的 Schema。假设我们要构建“研发团队文档知识库”可以定义实体类型属性团队成员姓名、岗位、部门服务名称、负责人、技术栈文档标题、路径、更新时间业务模块名称、依赖、负责人规范名称、适用范围、版本关系类型说明USE服务使用某种技术栈DEPENDS_ON模块依赖服务OWNED_BY服务/模块由团队成员负责MENTIONED_IN实体在文档中被提及FOLLOWS规范适用于某个模块6.2 实体抽取提示词模板实体抽取是第 5 轮也是后续所有环节的基础。提示词怎么写很关键你是一个知识图谱实体抽取器。 给定一篇技术文档片段抽取其中与研发团队知识库相关的实体。 要求 1. 只抽取与 Schema 中定义的类型匹配的实体。 2. 输出严格 JSON 数组格式为 [{name: 实体名, type: 实体类型, attributes: {}}] 3. 属性只能从原文中提取不能推测。 4. 没有匹配实体时输出 []。 文档片段 {chunk_text}输出示例[ { name: 订单服务, type: 服务, attributes: { 负责人: 张三, 技术栈: Go } }, { name: 支付模块, type: 业务模块, attributes: { 依赖: 订单服务 } } ]6.3 关系抽取提示词模板有了实体第 6 轮就是抽实体之间的关系你是一个知识图谱关系抽取器。 给定文档片段和实体列表抽取实体之间的关系。 要求 1. 只抽取 Schema 中已有的关系类型。 2. 输出 JSON 数组格式为 [{source: 实体A, relation: 关系类型, target: 实体B, evidence: 原文证据}] 3. evidence 必须是原文中的原句。 实体列表 {entities_json} 文档片段 {chunk_text}关系抽取的核心是“证据”。每条三元组都要能回溯到原文这正是后续可溯源问答的基础。如果关系没有原文证据宁可不入库也不能靠模型脑补。6.4 图谱入库与校验三元组生成后需要写入图数据库。以 Neo4j 为例from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) def create_relationship(tx, source, relation, target): query ( MERGE (a:Entity {name: $source}) MERGE (b:Entity {name: $target}) MERGE (a)-[r:REL {type: $relation}]-(b) ) tx.run(query, sourcesource, relationrelation, targettarget) triples [ {source: 订单服务, relation: DEPENDS_ON, target: 支付模块}, {source: 订单服务, relation: OWNED_BY, target: 张三}, ] with driver.session() as session: for triple in triples: session.execute_write(create_relationship, triple[source], triple[relation], triple[target]) driver.close()入库后要校验统计三元组数量、检查孤立实体、检查关系类型是否合法。从实际经验看最容易出问题的不是抽取而是实体对齐。同一实体在不同文档里写法不同比如“订单服务”和“订单系统”需要做实体归一化。7. 可溯源问答链路知识图谱构建完成后问答就不能只靠向量检索了。理想链路是用户提问。语义检索定位候选文档块。图谱查询获取相关实体和关系路径。把文档证据和图谱证据拼接成上下文。LLM 根据证据生成答案并标注引用来源。7.1 问答提示词设计可溯源问答的提示词要强调“证据优先”和“引用标记”你是企业知识库问答助手。 回答问题前先使用提供的文档片段和图谱证据。 要求 1. 答案必须基于证据不能编造。 2. 每个关键结论后面加上引用标记格式为 [来源ID]。 3. 如果证据不足直接回答“当前知识库中没有找到相关信息”。 4. 保持答案简洁不要展开无关内容。 图谱证据 {graph_evidence} 文档片段 {chunk_evidence} 用户问题 {question}7.2 Python 调用示例import requests url http://127.0.0.1:8080/api/chat payload { question: 订单服务依赖哪些模块, enable_graph: True, enable_rag: True, top_k: 5 } response requests.post(url, jsonpayload, timeout60) print(response.json())预期返回结构{ answer: 订单服务依赖支付模块和用户模块。[DOC_001], references: [ { source_id: DOC_001, title: 订单服务架构说明, chunk_index: 12, evidence: 订单服务依赖支付模块完成交易结算。 } ], graph_paths: [ { source: 订单服务, relation: DEPENDS_ON, target: 支付模块 } ] }从实际使用角度看判断问答链路是否成功的标准有三个答案是否与原文一致、引用是否能定位到具体文档块、图谱路径是否帮助补充了文档中没有直接出现的关联信息。三个条件缺一不可。8. 增量编译机制增量编译是工业级 LLM Wiki 和玩具级知识库的分水岭。只有几千个文档时全量重建可能还行但文档到几万、几十万时全量重建的时间和成本完全不可接受。8.1 增量编译思路核心思想是“变更检测 局部重建”维护一个文档状态表记录每个文档的哈希值、上次编译时间、分块数量。新文档或修改文档时只重新抽取该文档、重算向量、更新图谱。删除文档时只删除该文档涉及的实体关系和向量索引。下游依赖变更时比如 Schema 改了才触发相关范围的局部重建。8.2 配置示例incremental_compile: enabled: true watch_dirs: - ./docs/ - ./specs/ poll_interval_seconds: 60 hash_algorithm: sha256 sqlite_db: ./state.db max_batch_chunks: 200 on_change: [parse, extract_entities, extract_relations, embed, update_graph]8.3 编译流程代码逻辑import hashlib import json def compute_hash(filepath): with open(filepath, rb) as f: return hashlib.sha256(f.read()).hexdigest() def should_compile(filepath, state): current_hash compute_hash(filepath) return state.get(filepath) ! current_hash def compile_document(filepath): # 1. 读取文档 # 2. 分块 # 3. 实体关系抽取 # 4. 更新向量索引 # 5. 更新知识图谱 # 6. 更新状态表 pass增量编译的关键是状态表必须稳定。进程崩溃、数据库损坏、文件重命名都会影响状态判断。稳妥做法是状态表落盘、每批任务记录日志、编译完成后统一提交状态避免半途失败产生脏状态。9. 在线评估与回归没有评估的知识库就是黑盒。在线评估的目的是回答三个问题检索找得到吗答案答得对吗引用给得准吗9.1 构建评估数据集评估数据集建议按真实业务问题整理格式如下[ { question: 订单服务依赖哪些模块, expected_entities: [支付模块, 用户模块], expected_answer_keywords: [支付模块, 用户模块], expected_source_ids: [DOC_001], difficulty: easy }, { question: 服务出现故障应该找谁, expected_entities: [张三], expected_answer_keywords: [张三, 负责人], expected_source_ids: [DOC_003], difficulty: medium } ]9.2 自动化评估脚本import json import requests eval_set json.load(open(eval_set.json)) def evaluate_question(q): response requests.post( http://127.0.0.1:8080/api/chat, json{question: q[question]}, timeout60 ) data response.json() answer data.get(answer, ) refs data.get(references, []) hit_entities any(e in answer for e in q[expected_entities]) has_source any(r.get(source_id) in q[expected_source_ids] for r in refs) return { question: q[question], hit_entities: hit_entities, has_source: has_source, pass: hit_entities and has_source } results [evaluate_question(q) for q in eval_set] pass_rate sum(r[pass] for r in results) / len(results) print(fPass Rate: {pass_rate:.2%})9.3 常见评估指标指标说明实体命中率答案是否包含预期实体来源命中率引用是否包含预期文档答案相关性答案与问题是否相关需要人工抽检图谱支持度答案是否能从图谱路径推导未命中率知识库没有答案时是否正确拒绝在线评估的常见问题是评估集太少。建议每个业务模块至少准备 20 到 50 个问题并定期补充。评估不能只在发布前跑每次增量编译后都要跑回归防止“改一个文档坏一片回答”。10. 接口 API 与批量任务10.1 服务启动如果项目提供服务化启动方式常见模式是# 启动 Web 服务具体命令以实际项目为准 pnpm dsh web如果启动过程卡在pnpm dsh web优先检查依赖是否安装完整、端口是否被占用、启动日志中是否有请求阻塞。10.2 通用 API 调用模板下面给出通用调用模板实际接口路径和参数需要按项目文档调整import requests BASE_URL http://127.0.0.1:8080 # 文档上传示例 def upload_document(filepath): with open(filepath, rb) as f: response requests.post( f{BASE_URL}/api/documents, files{file: f}, data{title: filepath} ) return response.json() # 批量问答示例 def batch_ask(questions): results [] for q in questions: response requests.post( f{BASE_URL}/api/chat, json{question: q}, timeout120 ) results.append(response.json()) return results questions [ 订单服务依赖哪些模块, 支付模块的负责人是谁, 部署流程规范是怎样的 ] answers batch_ask(questions) print(json.dumps(answers, ensure_asciiFalse, indent2))10.3 批量任务设计建议批量任务最容易遇到的问题是大批量请求时服务超时、限流、资源耗尽。建议批量请求控制在 20 到 50 个一组分批执行。每批之间加短暂间隔避免突发流量。记录每个请求的日志包括问题、耗时、状态码、回答摘要。失败的请求自动重试重试最多 3 次。批量完成后汇总异常统一排查。11. 资源占用与性能观察11.1 观察哪些指标运行 DeepSeek Harness 时重点观察以下指标指标观察方式CPU 占用系统监控工具或top、任务管理器内存占用同上注意向量索引常驻内存显存占用nvidia-smi或任务管理器 GPU 信息磁盘 IO增量编译时注意读写接口耗时API 返回时间重点看 p95索引构建耗时单文档分块到入库的耗时图谱更新延迟新文档到图谱可查询的延迟11.2 显存占用与模型精度如果你使用本地 LLM显存占用和模型精度直接相关。FP16 和 BF16 是目前本地部署的主流方式显存占用大约是 FP32 的一半。BF16 的指数范围和 FP32 一致训练和推理稳定性更好FP16 在数值动态范围上有上限容易出现溢出。实际选用哪种精度要看模型的训练方式和推理框架支持情况不能只看显存数字。更稳妥的判断是先用 API 服务把整套流程跑通再根据成本和隐私要求决定是否切换到本地模型。知识图谱构建和增量编译阶段对显存要求不一定高真正吃显存的是大模型的推理和向量化。资源不足时可以外接 API本地只跑检索和图谱查询。11.3 性能优化方向文档分块大小从 512 降到 256检索更准但索引量更大。实体抽取使用小模型问答使用大模型分层推理。增量编译改成事件触发不用轮询。向量索引使用 HNSW 参数调优提高检索速度。图谱查询加缓存高频问题走缓存。12. 常见问题与排查方法问题现象可能原因排查方式解决方案pnpm dsh web启动卡住依赖未安装完整、端口被占、网络请求阻塞查看启动日志检查端口占用重装依赖换端口或检查网络连接依赖下载慢网络源不稳定查看包管理器日志配置国内镜像源使用加速源模型服务连接失败API Key 错误、endpoint 不可达测试模型服务连通性检查配置文件和网络策略实体抽取结果为空提示词约束过严、文档无法解析直接测试单条文档块放宽输出要求检查文档格式三元组没有入库关系类型不符合 Schema查看抽取日志修正关系类型定义回答没有引用来源提示词未强调引用或检索没有返回证据检查上下文是否包含证据片段调整提示词增加检索力度增量编译不触发文档状态哈希未变化、监听目录错误查看状态表和编译日志检查文件路径、状态表评估通过率低评估集和文档口径不一致、提示词不稳定抽检错误case补充评估集优化输出格式显存不足模型过大或推理并发过高nvidia-smi查看显存降低模型规模减少并发或切换 API最值得注意的问题是“实体抽取”和“关系抽取”的稳定性。LLM 输出天然有随机性同样的输入两次结果可能不同。工业级使用一定要做“结构化输出校验”抽取出 JSON 后先做格式校验再做 Schema 校验不合格的重新抽取或人工修复。13. 最佳实践与合规建议13.1 工程实践先把最小闭环跑通一份文档 → 抽取实体 → 建图谱 → 问答带引用 → 更新文档 → 增量编译 → 评估通过。这 7 个步骤都通了再扩大文档量。建议目录结构project/ ├── docs/ # 原始文档 ├── chunks/ # 分块结果 ├── entities/ # 实体抽取结果 ├── relations/ # 关系抽取结果 ├── graph/ # 图谱导入脚本与备份 ├── eval/ # 评估数据集与结果 ├── logs/ # 运行日志 └── state.db # 增量编译状态表批量任务一定要加日志和失败重试。知识库更新不应该静默失败增量编译的每个环节都要有可追踪日志。接口服务要限制访问范围至少做访问控制避免内部知识库暴露到公网。13.2 合规提醒涉及知识图谱、文档检索、可溯源问答时不要忽略内容来源。常见合规风险有两类一是版权风险。文档库中如果包含他人文章、教程、书籍内容构建知识图谱和问答系统时不能直接商用需要确认授权范围。即使是内部使用也要注意来源标注。二是隐私与敏感信息。个人信息、账号信息、内部安全信息不应该进入知识库。建议在文档入库前做敏感信息扫描启用数据脱敏设置访问权限。可溯源问答的“证据”设计反过来也要求系统能定位到具体文档所以必须有审计能力和删除能力——用户要求删除某条数据时图数据库、向量索引和文档副本要能同步清除。14. 总结与下一步DeepSeek Harness 做 LLM Wiki 的完整链路最有价值的点在于把知识库从“能问能答”提升到“可增量维护、可评估回归”的工程系统。10 轮提示迭代作为方法论每一轮都解决一个独立问题最终把文档变成知识图谱加可溯源问答的闭环。如果你要上手最先应该验证的是知识图谱构建和可溯源问答。这两个功能直接决定知识库有没有超出普通向量检索的价值。最容易踩的坑是文档分块策略和实体抽取的稳定性建议先小规模测试再逐步扩大范围。下一步可以尝试的方向包括把评估集扩充到更多业务模块、接入更多向量模型做效果对比、让知识图谱支持多版本文档对比、增加多轮对话中的上下文记忆、将评估结果接入 CI 实现每次文档更新自动回归。增量编译和在线评估都跑通后这套 LLM Wiki 方案才真正具备工业级落地条件。