10轮提示词打造可溯源知识图谱：本地LLM Wiki实战指南

没人愿意把笔记变成“笔记坟场”。传统 Wiki 写的时候很爽，检索的时候很痛苦；整理的时候很认真，用起来的时候发现全是碎片。Andrej Karpathy 提出 LLM Wiki 范式之后，这类问题有了一个新解法：用提示词把知识库当“知识图谱”来编译，让 LLM 参与整理、关联、溯源、评估和增量更新。

这次我们来看一套偏工业级的落地思路：以 DeepSeek Harness 这类本地运行框架为底座，用 10 轮提示词把原始资料加工成“可溯源问答 + 知识图谱 + 增量编译 + 在线评估”的 LLM Wiki。文章会先说明你需要准备什么环境，再逐步拆解 10 轮提示的具体目的和模板，最后给出知识图谱构建、接口调用方式、常见问题和性能观察方法。

视频口播式结论放在前面：整个流程不需要企业级算力。嵌入模型和生成模型都可以跑在本地，显存占用主要取决于你选的模型规格；如果只是做知识库问答，优先用小参数模型加外挂知识图谱，而不是盲目上大模型。这套方案的重点不是“提示词写得有多花”，而是知识组织方式足够结构化，让每次问答都有依据、可溯源。

1. 核心能力速览

这个项目或者说这套工作流，最值得关注的是“知识图谱”和“增量编译”两个设计。普通 RAG 只做向量检索，问题复杂一点就答不对；而 LLM Wiki 把知识拆成结构化节点，实体之间建立关系，再靠提示词生成可回溯的问答对。这种方式更容易排查“模型为什么答错”，也更方便做质量回归。

2. 适用场景与使用边界

2.1 适合谁

• 长期积累技术笔记、项目文档、论文阅读笔记的开发者。
• 需要在团队内部搭建知识库问答系统的工程团队。
• 正在做 RAG 应用，但发现纯向量检索效果不稳定的同学。
• 希望对知识库内容进行版本化管理和自动化评估的内容团队。

2.2 能解决什么问题

• 解决笔记碎片化：同一主题的多条笔记自动建立关联，形成知识图谱。
• 解决问答无依据：可溯源机制要求模型回答时列出引用来源，降低幻觉风险。
• 解决更新成本高：增量编译只刷新变化节点，不需要每次全量重建。
• 解决质量不可控：在线评估集可以持续测试，答案变差时及时发现。

2.3 不适合什么场景

• 不适合对实时性要求极高的在线客服系统。
• 不适合完全没有人工复核流程的生产环境直接输出。
• 不适合文档量极小、关系极简单的临时项目，杀鸡用牛刀。

2.4 合规与安全边界

使用 LLM Wiki 处理文档时，必须确认语料有权使用。包含人脸、声音、隐私数据或版权材料的文档，未经授权不得进入知识库。企业私有数据如果使用云端模型，需要先确认数据协议；更稳妥的做法是使用本地模型，避免数据出网。问答系统上线前，必须对敏感内容做过滤和人工复核。

3. 环境准备与前置条件

3.1 操作系统与运行时

LLM Wiki 类方案通常以 Node.js 和 Python 混合开发。建议准备：

• Windows 10/11、Ubuntu 20.04+ 或 macOS 12+。
• Node.js 18 或更高版本，建议 20 LTS。
• pnpm 包管理器，用于安装框架依赖。
• Python 3.10 或更高版本，用于知识图谱构建脚本和评估脚本。

如果本机还没有 pnpm，可以通过 npm 安装：

npm install -g pnpm

3.2 GPU 与内存要求

显存占用取决于模型选择。常见组合有两种：

注意：上面是经验估算，不是实测数据。实际显存占用会受文本长度、并发数、量化方式影响，需要以本机测试为准。CPU 也能跑，但生成速度会明显下降，建议优先使用 NVIDIA 显卡。

3.3 磁盘与端口

• 模型文件通常占用 2GB 到 20GB，需要预留足够磁盘空间。
• 知识库内容建议独立目录管理，避免与项目代码混放。
• 默认端口如果被占用，启动参数里要能自定义端口。

3.4 通用检查清单

# 检查 Node 版本 node -v # 检查 pnpm pnpm -v # 检查显卡驱动可用 nvidia-smi # 检查 Python python --version

这套检查清单可以帮助你判断环境状态。如果一个项目要求更高的 Node 版本，建议用 nvm 管理，不要直接覆盖系统全局版本。

4. 项目初始化与目录结构

以 DeepSeek Harness 这类框架为例，项目初始化一般会生成一套包含知识库、配置、脚本和输出目录的工程结构。合理的目录结构是后续 10 轮提示的基础。

4.1 推荐目录结构

llm-wiki/ ├── docs/ # 原始语料 │ ├── 00_inbox/ # 待整理输入 │ ├── 01_atomic/ # 原子笔记 │ ├── 02_concept/ # 概念笔记 │ └── 03_moc/ # 主题地图 ├── knowledge/ # 知识图谱数据 │ ├── entities.json # 实体表 │ ├── relations.json # 关系表 │ └── triples.json # 三元组 ├── eval/ # 评估数据集 │ ├── questions.json │ └── expected_answers.json ├── scripts/ # 脚本 ├── config/ # 配置 ├── output/ # 输出结果 └── agent.md # Agent 工作说明

4.2 agent.md 的作用

LLM Wiki 范式强调给 Agent 一份可执行的工作说明。agent.md可以理解为知识库编译的“操作规程”，内容包括任务目标、输入输出格式、处理规则和评估标准。这不是给人看的文档，而是给 LLM 每轮执行时的长期提示词。

agent.md里建议写清楚：

• 知识库领域范围。
• 实体抽取的类型定义。
• 关系抽取的 schema 定义。
• 问答对生成的格式要求。
• 溯源字段必须包含哪些信息。

5. 10轮提示：从零打造工业级 LLM Wiki

这是全文核心。所谓“10轮提示”，不是让 LLM 随便聊 10 次，而是针对知识库生产流程设计 10 个不同的处理阶段。每一轮都有自己的输入、输出和质量标准。

5.1 第 1 轮：需求分析与语料边界

目的

明确知识库要解决什么问题。不要一上来就灌文档，先让 LLM 基于语料目录生成一份“知识库范围说明”。

输入

• 原始语料目录清单。
• 目标用户画像。
• 预期问答场景。

提示词模板示例

你是知识库架构师。请根据语料目录，输出一份知识库范围说明，包括： 1. 主要覆盖的领域和子领域。 2. 每份文档在知识库中的角色。 3. 哪些文档可能包含过时信息。 4. 建议的术语表和实体类型列表。 输出格式：Markdown 表格，最后一列标注置信度。

验证方式

检查输出的领域分类是否与语料实际内容一致。如果分类完全不对，说明提示词里缺少领域背景，需要补充术语表再跑一轮。

5.2 第 2 轮：语料清洗与格式归一化

目的

原始文档格式混乱，存在 PDF 抽取残留、代码块错位、重复段落等问题。这一轮要把文本统一成干净的 Markdown。

提示词模板示例

请将以下原始文本清洗为结构化 Markdown： 1. 删除重复段落。 2. 保留代码块，并标注语言。 3. 将表格转换为 Markdown 表格。 4. 删除页眉页脚和无关水印文字。 5. 保留文档原有的标题层级。 不要新增原文没有的内容。输出只包含清洗后的 Markdown。

预期结果

清洗后的文档应为规范 Markdown，代码块语言标注完整，表格结构可解析。如果清洗结果丢失关键信息，降低输出长度限制或拆分文本。

5.3 第 3 轮：实体关系抽取

目的

从清洗后的文档中抽取实体和关系，为知识图谱准备原材料。

实体类型建议

• 概念（Concept）
• 组件（Component）
• API
• 协议（Protocol）
• 论文
• 项目
• 人物
• 组织

提示词模板示例

请从以下文本中抽取实体和关系。 实体类型定义： - Concept: 抽象概念，如“增量编译”“知识图谱”。 - API: 函数、接口或命令行。 - Project: 项目名称。 - Protocol: 协议名称。 - Person: 人名。 - Org: 组织名。 关系类型定义： - related_to: 相关关系。 - depends_on: 依赖关系。 - part_of: 组成关系。 - implements: 实现关系。 - used_by: 被使用关系。 输出 JSON 格式： { "entities": [ {"name": "...", "type": "...", "source": "文件路径"} ], "relations": [ {"source": "...", "target": "...", "type": "...", "source": "文件路径"} ] }

验证方式

用脚本统计抽取到的实体总数和关系总数，抽样检查 20 个三元组是否正确。常见问题：实体名称过长、类型错配、关系方向反了。

5.4 第 4 轮：知识去重与冲突消解

目的

多份文档可能描述同一个实体，但名称不统一。例如“DeepSeek Harness”和“DeepSeek-Harness”可能是同一对象。这轮负责把同义实体合并。

提示词模板示例

以下实体是从同一知识库中抽取的，请找出可能指向同一实体的条目并建议合并： - 使用归一化规则：去除中英文括号差异、统一大小写、统一短横线。 - 置信度低于 0.8 的不要合并。 - 每个合并建议需要附理由。 输出 JSON： { "merges": [ { "canonical_name": "统一后的实体名", "aliases": ["别名1", "别名2"], "reason": "合并理由" } ] }

注意事项

去重阶段容易误合并，比如“LLM”可能同时指代“大语言模型”和某个同名论文。建议把高危合并项打印出来人工确认，而不是直接接受。

5.5 第 5 轮：原子化切片

目的

把长文档切成适合 LLM 处理的原子笔记。原子笔记的名称、摘要、标签和正文单独保存。

切片粒度建议

• 每个概念独立成篇。
• 每篇原子笔记控制在 300 到 800 字。
• 保留来源文件路径和章节锚点。
• 同一切片不要包含两个无关主题。

提示词模板示例

请将以下文档拆分为原子笔记。要求： 1. 每个原子笔记只表达一个核心概念。 2. 使用固定 frontmatter 格式。 3. 保留原文引用，标记原始文件路径和段落位置。 4. 不遗漏关键内容。 输出格式： --- id: "auto-generated-id" title: "原子笔记标题" tags: ["标签1", "标签2"] source: "docs/01_atomic/xxx.md" anchor: "#section-2" --- 笔记正文

验证方式

统计切片数量和平均长度。如果切片大量超过 1000 字，说明拆分粒度不够细。

5.6 第 6 轮：知识图谱建模与三元组导出

目的

将实体和关系整理为可导入图谱数据库的三元组文件。这一步需要设计 Schema，并输出triples.json。

三元组示例

[ { "head": "DeepSeek Harness", "relation": "implements", "tail": "LLM Wiki", "source": "docs/01_atomic/dsh-llm-wiki.md" }, { "head": "LLM Wiki", "relation": "depends_on", "tail": "知识图谱", "source": "docs/01_atomic/llm-wiki-overview.md" } ]

Schema 设计建议

关系名称要小写并使用下划线，例如related_to、part_of、implemented_by。避免使用中文作为关系类型，方便后续查询和迁移。

导出脚本示例

import json def export_triples(input_path, output_path): with open(input_path, "r", encoding="utf-8") as f: data = json.load(f) triples = [] for item in data["relations"]: triples.append({ "head": item["source"], "relation": item["type"], "tail": item["target"], "source": item.get("source_path", "") }) with open(output_path, "w", encoding="utf-8") as f: json.dump(triples, f, ensure_ascii=False, indent=2) if __name__ == "__main__": export_triples("knowledge/relations.json", "knowledge/triples.json")

5.7 第 7 轮：可溯源问答对生成

目的

生成一批高质量 QA 对，并让每个答案都绑定来源片段。这既是知识库的问答素材，也是后续评估集的基础。

提示词模板示例

请根据原子笔记生成 5 个问答对。 要求： 1. 问题覆盖单点知识、关系推断和流程理解。 2. 答案必须基于笔记内容。 3. 每个答案必须包含 citations，指向源文件路径和片段。 4. 如果笔记内容无法回答问题，写“无法回答”。 输出 JSON： { "qa_pairs": [ { "question": "...", "answer": "...", "source": "...", "citations": ["文件路径#锚点"], "difficulty": "easy|medium|hard" } ] }

质量检查

这一步容易出现“答案看似合理但脱离原文”的情况。建议将 QA 对保存后，使用关键词匹配或人工抽检验证答案中的关键实体是否存在。

5.8 第 8 轮：增量编译规则制定

目的

定义哪些文件变化时需要重建哪些节点。LLM Wiki 的编译过程可以类比代码构建：只有源文件变化，才重新生成对应笔记和三元组。

规则示例

配置文件示例

incremental: enabled: true watch_dirs: - docs/01_atomic - docs/02_concept output_dirs: - knowledge - output triggers: add: ["concept_index", "relation_update"] modify: ["concept_index"] delete: ["relation_update"]

实现思路

增量编译的关键是文件哈希。对每个笔记内容计算哈希，存入缓存表。每次运行前扫描文件，对比哈希变化，只对变化文件执行后续 LLM 提示流程。

5.9 第 9 轮：在线评估数据集构建

目的

构建一个固定答案的回归测试集，让每次知识库更新后运行相同问题，检查答案是否退化。

数据集结构示例

{ "eval_set": [ { "id": "eval-001", "question": "DeepSeek Harness 支持哪些启动方式？", "expected_entities": ["WebUI", "CLI", "API"], "min_entities": 2, "citations_required": true, "difficulty": "medium" } ] }

评估维度

• 实体覆盖率：答案中是否包含预期实体。
• 溯源命中率：答案是否引用了正确来源。
• 一致性：同一问题多次回答是否稳定。
• 拒绝率：知识库无法回答时是否诚实拒绝。

5.10 第 10 轮：反思、修正与持续更新

目的

前 9 轮产出的知识库并不能直接上线，需要经过一轮反思式审查。将最新生成的 QA 对放回知识库中重新检索，检查召回是否正确。

反思提示词模板示例

你是知识库质量审查员。请检查以下问答对： 1. 答案是否完全来自引用的来源文件。 2. 如果出现“幻觉”，请标出哪些句子没有依据。 3. 给出修正建议：是补充笔记、修改关系还是调整提示词。 输出格式： - 问题编号 - 幻觉句子列表 - 修正建议

持续更新策略

建议每周运行一次在线评估，知识库变更后立刻触发增量编译。评估结果低于阈值时，回溯到对应提示轮次调整。

6. 知识图谱构建与三元组装库

10 轮提示产出的三元组需要落到实际的图数据库，才能支持复杂关系查询和知识推理。常用的图数据库是 Neo4j，也可以先用 JSON 文件验证再导入。

6.1 Neo4j 查询示例

from neo4j import GraphDatabase def connect(uri, user, password): return GraphDatabase.driver(uri, auth=(user, password)) def create_triples(driver, triples): with driver.session() as session: for t in triples: session.run( """ MERGE (head:Entity {name: $head}) MERGE (tail:Entity {name: $tail}) MERGE (head)-[r:RELATION {type: $relation}]->(tail) SET r.source = $source """, head=t["head"], tail=t["tail"], relation=t["relation"], source=t["source"] ) if __name__ == "__main__": with open("knowledge/triples.json", "r", encoding="utf-8") as f: triples = json.load(f) driver = connect("bolt://localhost:7687", "neo4j", "your-password") create_triples(driver, triples) driver.close()

注意：这只是通用示例，实际项目中的图模型需要根据知识库领域调整。比如股权关系、科研论文引用关系等场景，关系类型和属性设计都不同。

6.2 知识图谱查询如何参与问答

可溯源问答不只是把问题抛给 LLM，而是先在图谱中检索候选实体和路径，再把候选片段送入 LLM 生成回答。这样做有三个好处：减少噪声、提高多跳推理准确率、让答案来源更透明。

7. 可溯源问答的实现原理

7.1 溯源字段设计

每条知识条目至少需要记录：

7.2 问答流程

1. 对用户问题做实体识别。
2. 在知识图谱中检索相关实体和关联路径。
3. 将候选笔记片段拼接为上下文。
4. 提示 LLM 仅基于上下文回答，并输出引用。
5. 校验引用是否存在，过滤无法验证的回答。

7.3 防止幻觉的核心

不要依赖 LLM 自己“记得”答案。所有回答必须经过知识图谱检索和引用校验两重检查。如果候选片段中没有足够证据，直接返回“当前知识库无法回答”。

8. 增量编译与在线评估实践

8.1 增量编译触发流程

# 扫描文件变化 python scripts/scan_changes.py \ --watch-dir docs/01_atomic \ --cache-file .cache/note_hashes.json # 对变化文件执行处理 python scripts/process_changed_files.py \ --input-dir docs/01_atomic \ --output-dir docs/02_concept # 更新三元组 python scripts/update_triples.py \ --relations knowledge/relations.json \ --output knowledge/triples.json

8.2 在线评估运行脚本

python scripts/evaluate.py \ --eval-set eval/questions.json \ --kb-uri http://127.0.0.1:7860 \ --output output/eval_result.json

8.3 评估结果处理建议

• 单条失败：优先检查相关笔记内容是否有误。
• 成批失败：可能是知识图谱 Schema 变更导致，需要检查关系映射。
• 引用缺失：查看候选片段是否被正确检索。

9. 接口 API 与批量任务

DeepSeek Harness 这类框架通常提供 HTTP 接口，方便把知识库问答接入团队内部工具。

9.1 通用 API 调用示例

import requests import time API_URL = "http://127.0.0.1:7860/api/query" payload = { "question": "DeepSeek Harness 支持增量编译吗？", "top_k": 5, "with_citations": True } def query_kb(question: str, timeout: int = 120): resp = requests.post(API_URL, json=payload, timeout=timeout) resp.raise_for_status() return resp.json() if __name__ == "__main__": result = query_kb("DeepSeek Harness 支持增量编译吗？") print(result["answer"]) for c in result.get("citations", []): print(f"- {c['source_file']}#{c['anchor']}")

9.2 批量任务设计

批量处理建议使用任务队列而不是直接并发请求。每个任务记录状态：pending、running、done、failed。处理失败时自动重试，最多重试 3 次，并在日志中输出失败原因。

{ "batch_id": "batch-20250101-001", "tasks": [ { "task_id": "task-001", "doc_path": "docs/01_atomic/example.md", "status": "pending", "retry_count": 0, "max_retry": 3 } ] }

9.3 接口安全建议

• 局域网内使用时不暴露到公网。
• 接口增加简单 Token 校验。
• 批量接口控制并发数，避免压垮本地 GPU 推理服务。

10. 资源占用与性能观察

10.1 显存观察方法

启动知识库服务后，用以下命令监控显存：

watch -n 1 nvidia-smi

主要看两个值：

• 生成模型进程的显存占用。
• 嵌入模型进程的显存占用。

如果显存不够，优先采取以下措施：

• 换更小的量化模型。
• 缩短单次输入文本长度。
• 降低并发请求数。
• 把嵌入模型放到 CPU。

10.2 性能判断维度

10.3 瓶颈定位

如果整体响应慢，先分别测知识图谱查询和 LLM 生成两段耗时。图谱查询慢就优化索引和关系模型；生成慢就换更小的模型或减少候选片段长度。

11. 常见问题与排查方法

12. 最佳实践与合规建议

12.1 工程化建议

• 第一次运行先用最小数据集验证全流程，不要直接灌入数百篇文档。
• 固定一份agent.md 模板，所有提示轮次都基于它执行，减少随机性。
• 模型文件、输入素材、输出结果分目录管理，不要混放。
• 增量编译的缓存文件列入 Git 忽略清单，避免频繁冲突。
• 在线评估集纳入版本管理，知识库结构变更时同步修订。
• 批量任务必须保留日志和失败重试机制。
• 接口服务限制访问来源 IP，不开放到公网。

12.2 合规与伦理建议

• 知识库语料必须确认授权，未经许可的文档、论文、专利内容不要入库。
• 涉及人脸、声音等个人信息的内容，需要先完成脱敏和授权确认。
• 问答系统上线前，建议针对敏感话题做一轮人工审核。
• 如果使用云端模型处理私有数据，需要确认服务协议是否允许。
• 本地部署优先使用开源模型，避免数据出网。

12.3 内容质量运营建议

知识库不是一次建完就结束。建议每周做一次小规模更新，每月做一次全量评估。评估结果异常时，优先回滚最近一次知识图谱变更，而不是直接调整模型提示词。提示词和知识内容分离管理，有利于排错。

13. 总结与下一步

这套 10 轮提示的 LLM Wiki 工作流，最值得尝试的是把知识图谱、增量编译和在线评估三个环节串起来。它的价值在于：每一层都有可验证的产物，而不是让 LLM 直接输出一份看似完整的长文档。你可以先拿一份熟悉的领域文档跑通前 3 轮，确认实体抽取和关系建模是否符合预期，再逐步把 10 轮流程补全。

最容易踩的坑有三个：实体抽取阶段过度依赖 LLM 导致噪声过大，增量编译时缓存失效导致全量重建频繁，以及评估集质量不好导致评估分数虚高。建议从最小数据集开始，先把知识图谱 Schema 定稳定，再扩大语料量。

接下来的扩展方向也很明确：把知识图谱换成 Neo4j 这样的正式图数据库，接入团队内部 IM 机器人，或者用异步任务队列处理每天新增文档。建议先把基础流程跑稳，再考虑放大规模。文章里的命令和代码都是通用模板，接入实际项目时请以对应框架的官方文档为准。