详细内容或原文请订阅后点击阅览

LLM Wiki 过度设计 - 我用纯 Python 编译器替换了我的

2026年7月3日 13:30 33 Comments
X Twitter Instagram Mail

大多数“LLM wiki”使用代理、嵌入和重复模型调用来组织本地注释。我构建了一个确定性的替代方案：一个纯 Python 编译器，仅使用标准库将杂乱的 Markdown 转换为链接的、经过 linted 的 wiki。在此过程中，我修复了两个真正的错误，在两个操作系统上对管道进行了基准测试，并展示了为什么编译器通常比代理更适合机械文本组织。LLM 维基百科过度设计——我用纯 Python 编译器替换了我的编译器首先出现在《走向数据科学》上。

来源:走向数据科学

TL;DR

  • 我的管道将原始的、凌乱的文本注释文件夹编译成链接的、linted markdown wiki。没有 LLM 调用，没有嵌入，没有外部 API，只有标准库。
  • 该管道有四个阶段：正则表达式提取器、检测交叉引用的图形生成器、保留您手写的任何内容的节感知重写器以及检查其自身输出的 linter。
  • 我在构建这个时遇到了两个真正的错误：一个扩展性很差的图形生成器，以及一个默默地低估了孤儿页面的 linter。本文中的这两个问题均按实际发生的情况进行，并附有修复程序。
  • 我在两台不同的机器（Linux 和 Windows）上对三种语料库大小的完整管道进行了基准测试，并检查了确定性输出是否在两台机器上实际匹配。他们确实做到了。
  • 下面包含完整代码、所有 17 个测试和未舍入的终端输出，以便您可以自己重新运行所有内容。

    • 为什么我写这个

    我尝试构建一个 Karpathy 风格的 LLM wiki。代理循环。递归 LLM 调用。一切事物的嵌入。

    输入是我已有的本地 Markdown 文件的文件夹，位于我自己的磁盘上。

    中途，我突然意识到：我正在支付代币来重新组织我已经拥有的文本。

    所以我用纯Python编译器替换了整个管道。

    本文完整介绍了该系统：将原始的、格式不一致的文本注释文件夹转换为链接的、经过 linted 的 Markdown wiki，其中零 LLM 调用、零外部 API 和零第三方依赖项。下面的每个基准测试数字都是真实的，在两台不同的机器（一个 Linux 容器和我自己的 Windows PC）上运行，并且我已经包含了我在构建它时遇到的两个真实错误。

    如果您正在寻找纯 Python markdown wiki 编译器、基于代理的知识库工具的确定性替代方案，或者构建本地优先 RAG 替代方案的实际分解，这就是那篇文章。

    完整代码：https://github.com/Emmimal/wiki-compiler/

    编译器思维方式

    这是本文其余部分所构建的重构：

    中断的地方

    注释 交叉引用 编译器 下面的 LLM 不同的 代理的 不一致 真实的 工具的 已有的 文本 输入 语料库 第三方 原始的 手写的 构建 完整 一致的 wiki 中断的 知识库 表达式 检查 输出的 为什么 测试 引用的 管道 自己的 实际 生成器 拥有的 不一致的 真正的 进行 两台 替代方案 文件夹 提取器