企业官网建设流程全解析

llm-wiki-compiler query深度教程：带引用的知识问答与答案回存（--save --review实战）

【免费下载链接】llm-wiki-compilerThe knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.项目地址: https://gitcode.com/gh_mirrors/ll/llm-wiki-compiler

llm-wiki-compiler是一款知识编译器：原始资料进去，互链 wiki 出来。它的query命令是整个工作流里最有“复利效应”的一环——先用混合检索（向量语义搜索 + BM25 重排）从你自己的 wiki 中找出相关页面，再生成只基于这些页面、带 [[wikilink]] 引用的回答。配合--save和--review，你还能把高质量答案回存为 wiki 页面，让下一次提问站在上一次的答案之上。

一分钟上手：对编译好的 wiki 提问

前提：你已经用llmwiki quickstart或llmwiki compile编译过项目（完整步骤见 docs/quickstart.mdx）。在项目根目录直接提问：

llmwiki query "什么是多头注意力？它和自注意力有什么区别？"

回答会流式输出到终端。注意回答里会自然出现[[self-attention]]这类 wiki 内链——这就是答案引用，它保证回答的每个论断都能回溯到你 wiki 里的具体页面，而不是模型凭记忆“编”出来的。wiki 里没有足够信息时，模型会直说“不知道”，这是设计行为。

检索本身是两步：先做分块级向量语义搜索（基于.llmwiki/embeddings.bin），再用BM25 词法重排，把“语义相近但不直接相关”的内容挤下去。加--debug可以看到选中了哪些页面、各自的得分，以及重排是否改变了顺序：

llmwiki query "位置编码是怎么工作的？" --debug

相关实现见 src/commands/query.ts（两步检索与答案生成管线）。

看懂答案引用报告：resolved / pending / broken

回答流完后，query会打印一份引用报告，把答案里出现的 wiki 内链按“首次出现顺序”分类：

Answer citations: 1 resolved, 1 pending, 1 broken resolved: alpha -> concepts/alpha pending: beta broken: missing

这份报告只是“建议性检查”；真正发布时会持有项目锁重新做一次新鲜校验（报告生成逻辑在 src/commands/query-citation-report.ts）。换句话说：没有 broken 链接 ≠ 事实完全正确，但它是回存前的一道硬门槛。

--save 实战：把答案回存为 wiki 页面

这是 query 的“复利”开关。加上--save后，只要 profile 检查和新鲜引用校验都通过，答案会：

1. 写入wiki/queries/<slug>.md（原子写入，见 src/commands/query-save.ts）
2. 重新生成wiki/index.md，让新答案立刻可被发现
3. 为新页面补向量索引（除非你关闭了 embeddings）

# 第一次提问：答案只来自概念页 llmwiki query "大语言模型训练用到哪些技术？" # 满意后回存 llmwiki query "大语言模型训练用到哪些技术？" --save # 之后的提问可以在这份沉淀之上继续追问 llmwiki query "RLHF 和我们刚沉淀的训练技术有什么关系？"

时间一长，wiki/queries/会积累出“二次综合知识”，证据包越来越厚——这是 docs/cli/query.mdx 里说的compounding queries。

注意发布策略：--save遇到 pending 或 broken 链接会直接拒发（答案仍然完整打印在终端，只是不写文件），避免带病页面污染 wiki；遇到校验不可用也拒发，绝不静默放行。

--save --review 实战：先进审核队列，人工把关后再发布

对“权威型”wiki，直接写盘可能太激进。--review（必须搭配--save）会把答案作为经过校验的候选放进.llmwiki/candidates/，页面、索引、向量全部不动，并打印一个候选 ID：

llmwiki query "注意力机制是如何工作的？" --save --review llmwiki review list llmwiki review show <answer-candidate-id> # 先批准所有被引用的 pending 目标页，再批准答案本身 llmwiki review approve <target-candidate-id> llmwiki review approve <answer-candidate-id>

这条路径的关键安全设计：

• 预条件绑定：暂存时会记录目标页当时的摘要（或“不存在”；若暂存后目标页变了，批准会拒绝并要求重新生成、重新暂存
• 批准时不做额外模型调用：所有链接必须在批准那一刻全部解析为已保留页面
• 拒绝不删候选：批准失败时候选保留，处理完目标页可以重试

完整的候选生命周期、原因码和批量批准（approve-batch）详见 docs/cli/review.mdx。

在本地 viewer 里浏览沉淀后的答案

回存完成后，用只读 viewer 浏览效果最直观——左侧Queries分组会列出所有沉淀页，正文中的引用芯片可以一键跳回来源：

llmwiki view --open

页面里的field-notes.md:3-5这类芯片，就是 llmwiki 的段落级溯源标记（^[file.md:行范围]），概念详解见 docs/concepts/citations.mdx。想换风格可以看 docs/guides/viewer-themes.mdx，比如 Scientific Clay 主题。

实用标志速查与小贴士

💡 三个实战建议：

• 先不带--save试问一遍，看引用报告再决定是否回存，成本最低；
• broken 链接别硬发：先llmwiki compile补上目标概念页，再重新提问回存；
• 想要证据包而不想要答案（比如接自己的 agent），用llmwiki context "<问题>" --json，它输出与query相同的混合检索结果，但不生成回答。

小结

llmwiki query把“问答”变成了 wiki 的生长方式：检索有混合检索兜底，回答有 [[wikilink]] 引用兜底，回存有引用校验和审核队列兜底。--save负责沉淀，--review负责把关——两者组合，你的 wiki 就会像滚雪球一样，越用越厚、越问越准。

延伸阅读：docs/cli/query.mdx（query/context 完整参考）、docs/cli/review.mdx（审核队列全貌）、docs/concepts/citations.mdx（引用与溯源模型）。

【免费下载链接】llm-wiki-compilerThe knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.项目地址: https://gitcode.com/gh_mirrors/ll/llm-wiki-compiler