InfoForge：用作本地AI代理的RAG数据源的离线版维基百科

我询问了本地的8B模型：小说家夏目漱石的出生日期是什么时候。它回答说是“1867年2月9日”，接着还说出了它所参考的参考资料。其实这个模型本身并不知道这一事实。它是通过我家里的一台机器上存储的、容量达52.69 GB的维基百科数据库查到该信息的；整个查询过程完全无需互联网参与。那台机器就是 我的家用服务器。

既然模型已经“知道一切”了，何必多此一举呢

因为它做不到，而且其失败方式相当糟糕。向一个小模型询问日期、某种物质的性质或某个地名，它会给出一个流畅、自信且看似合理的回答，但完全看不出该答案是否真实。它并非在撒谎；它根本无法区分什么是记忆中的事实、什么是自己生成的内容。对于文学创作来说这没问题，但对于事实信息而言则是灾难。

检索机制能解决问题，但常规的检索流程是以云搜索 API 为前提的：你的提问会被发送到某家公司，该公司会记录下这些信息，而你的助手随后便要依赖他人的服务可用性和服务条款了。在我家，正是这套 AI 系统来回答孩子们的问题，因此上述两个问题都让我颇为担忧。

维基百科同时解决了这两个问题。它是目前最全面的通用知识库——你可以合法地下载其全部内容，而这些数据仅需一张价格比一次夜生活消费还便宜的磁盘就能存储下来。Kiwix项目多年前便完成了艰巨的任务：它将整个维基百科打包成经过压缩且带有索引的ZIM格式，以便那些没有网络连接的学校、船只或其他场所使用。我现在只是让人工智能去读取它，而非通过浏览器访问罢了。

最终你会得到什么

提出一个问题，得到一个答案；随后是一个编号列表，列出了构成该答案所依据的维基百科条目。这是2026年9月16日的一次真实运行记录（服务器地址为回环地址）：

$ infoforge ask "夏目漱石出生于哪一年？"
infoforge: 警告：跳过歧义页面：夏目
infoforge: 警告：跳过歧义页面：漱石
infoforge: 已根据5篇文章进行定位
根据提供的资料，夏目漱石出生于1867年2月9日。...

参考文献：
[1] 夏目漱石 — http://127.0.0.1:8080/content/wikipedia_en_all_nopic/Natsume_Soseki
[2] 夏目漱石 — http://127.0.0.1:8080/content/wikipedia_en_all_nopic/Natsume_S%C5%8Dseki
[3] 柳秉澈 — ...

这花了4.4秒。当没有任何可接地的东西时，就会出现这种情况：

$ infoforge search "qzxvbnm plorkwidget fnargle"
infoforge: 错误: 找不到与‘qzxvbnm plorkwidget fnargle’相关的数据源
$ echo $?
3

没有段落输出，无需猜测，还会返回一个调用脚本可以检查的退出码。ask命令同样返回退出码3，并提示用户尝试使用更简单的关键词，或者运行 infoforge doctor。完整的退出码说明如下：0表示正常；2表示配置或用法有误；3表示没有任何可依据的信息；4表示未引用任何来源（仅在启用 --strict 选项时出现）；5表示所有模型端点均无法访问。即便出现退出码5的情况，该工具仍会输出它找到的文章，因此这次搜索并未白费。

工作原理

五个阶段，没有一个是巧妙的，我建议就保持这样吧。

关键词提取。 问题本身并非查询内容。Kiwix会对所有搜索词进行逻辑“与”运算，因此像“谁写了《Kokoro》？它是什么时候出版的？”这样的提问几乎匹配不到任何结果；而直接输入“Kokoro”则是一个不错的查询方式。该提取器的核心功能就是一个能够保留原单词顺序的停用词过滤器：

def keyword_query(question: str) -> str:
    tokens = _TOKEN_RE.findall(question)
    keywords = [
        t for t in tokens
        if t.lower() not in _STOPWORDS and t.lower() not in _WEAK_VERBS
    ]
    return " ".join(keywords) if keywords else question.strip()

v2额外增加了两项功能：首先，会将问题中出现的首字母大写的短语作为文章标题来尝试匹配；其次，会对所有匹配结果重新排序，使得消歧义页面、单纯的年份以及“……列表”类页面排在后面。

搜索功能。 Kiwix的全文搜索实际上是基于真正的搜索索引实现的，而非简单的grep操作；正是这一点使得搜索功能得以实现。我在开发时，该搜索功能能在3到30毫秒内从1919万条条目中返回相关标题。2026年9月16日，在同一台机器上，于流量较高的时段执行同类查询时，耗时则变为90至730毫秒。我推测此时索引可能已从页面缓存中清除；不过无论如何，与模型处理所需时间相比这点延迟几乎可以忽略不计。整个系统中不存在任何嵌入向量、向量数据库，也没有需要在数据更新时重新构建的块存储机制。维基百科的编辑者们早已完成了内容分块工作——他们把这些块称为“文章”。

获取并裁剪。 kiwix-serve在本地回环接口上返回文章内容大约需要 1毫秒（处于“热状态”时）。我使用 curl 对刚阅读过的三篇文章进行测试，测得的时间在0.7至1.1毫秒之间；而首次访问时的耗时则为6至9毫秒。最初的草稿中我写的是“0.5毫秒”，却未说明这是热状态下的数值。裁剪环节是唯一需要人工判断的步骤。直接从文章开头截取内容常常会导致丢失正确答案——因为所需信息往往深藏在冗长的文章之中。因此，每篇文章都会保留一小段开头部分（约占总长度的四分之一），再加上一个与问题中出现频率最低的词汇最为匹配的文本窗口。

基础提示语。 这就是整个诀窍所在，它由四句话组成。首先是规则，然后是带编号的信息来源，最后是问题：

您是一个仅依据下方提供的源文本来回答问题的助手。
请仅使用这些源文本中的信息来回答用户的问题。如果源文本中并未包含答案，请明确说明这一点。
当引用源文本中的信息时，请注明文章标题（例如：“根据《文章标题》所述”）。
切勿编造任何源文本中不存在的事实、标题或网址。

来源1：