WiCER：面向 LLM Wiki 系统的 Wiki 记忆编译、评估与精炼迭代式知识编译

# Wiki-memory Compile, Evaluate, Refine：面向 LLM Wiki 系统的迭代式知识编译
来源：https://arxiv.org/html/2605.07068
Juan M. Huerta
Zinnia Tech Solutions
600 Steamboat Road Greenwich, CT 06830, USA
[email protected]

###### 摘要

*LLM Wiki* 模式——将领域知识编译并持久化为一个工件，并通过 KV 缓存推理提供给大型语言模型（LLM）——承诺以亚秒级延迟提供上下文访问，且零检索失败。实现这一目标需要解决*编译鸿沟*：LLM 编译过程将原始文档提炼为维基时，不会灾难性地丢弃关键事实。我们在 17 个 RepLiQA 领域（6,800 个问题）上对这一鸿沟进行了刻画：我们观察到，全上下文 KV 缓存推理在精选知识上的表现优于检索增强生成（RAG）（4.38 对比 4.08/5，首次时间到令牌 TTFT 快 7.3 倍），但由于注意力稀释，其在大规模下的表现低于 RAG；而盲目编译则完全失败（2.14–2.32 对比 3.46，灾难性失败率为 53–60%）。为了解决编译鸿沟，我们提出了 WiCER（Wiki-memory Compile, Evaluate, Refine，即维基记忆编译、评估、精炼），这是一种受反例引导抽象精炼（CEGAR）启发的迭代算法，能够填补这一鸿沟。WiCER 针对诊断探针评估已编译的维基，识别被丢弃的事实，并强制在后续编译中保留这些事实。一到两次迭代即可恢复 80% 因盲目编译而损失的质量（在有基准的 15 个主题中，平均分为 3.24，对比原始全上下文的 3.47），相对减少了 55% 的灾难性失败。针对所有 17 个主题的消融实验证实，有针对性的诊断（+0.95）而非通用固定（+0.16）推动了性能提升。所有代码和基准均已发布，以支持可重复的研究。

## 1 引言

越来越多的面向用户的 AI 应用程序——客户支持聊天机器人、特定领域助手和系统（例如法律、保险等）、交互式知识库——必须同时满足两个相互竞争的需求：回答必须基于权威的领域知识，且响应延迟必须足够低以支持实时对话交互。检索增强生成（RAG）Lewis et al. (2020); Gao et al. (2024) 通过在查询时检索相关文档片段来解决知识 grounding 问题，但这增加了检索延迟，并在检索器失败时有遗漏相关上下文的风险。一种根本不同的方法正受到关注：与其在查询时检索片段，不如*编译*领域知识为一个持久工件，让模型基于完整集合进行推理。Karpathy 的*LLM Wiki*模式 Karpathy (2026) 阐述了这一愿景——一种三层架构，包含原始来源、已编译维基和结构化模式，其中“知识一次性编译并保持最新，而不是在每次查询时重新推导”。Chan 等人将同样的直觉形式化为*缓存增强生成*（Cache-Augmented Generation, CAG）Chan et al. (2025)：将所有知识预加载到上下文中，并缓存由此产生的 KV 状态。

在本文中，我们认为全上下文 KV 缓存推理是 LLM Wiki 模式的一种实用、可部署的实现。通过将精选文档集合加载到模型的上下文窗口中并持久化 KV 缓存状态（例如，通过 llama.cpp 的提示缓存 `--cache-prompt` ggml-org (2024)），每个后续查询都以亚秒级延迟针对完整知识库提供服务，同时最大限度地降低检索失败风险和分块边界信息丢失。

#### RAG 基线。
替代方案嵌入查询并检索前 $k$ 个最相关的文档块，仅使用检索到的段落构建聚焦提示 Lewis et al. (2020); Karpukhin et al. (2020)。这极大地减少了每查询的令牌消耗，但当检索失败时有遗漏相关信息风险。

#### 编译鸿沟。
当知识被预编译时，全上下文 KV 缓存推理实现了 LLM Wiki 方法：例如，使用 Policygenius 语料库的 30 篇精选文章（67K 令牌，占 96K 上下文窗口的 70%），它优于 RAG（4.38 对比 4.08/5），且 TTFT 快 7.3 倍（第 4 节）。但在大规模下该方法会失效：在 17 个领域的每个主题上，针对 80 个原始 RepLiQA 文档 Montero et al. (2024)（55–95K 令牌，填充 57–99% 的窗口），注意力稀释导致全上下文质量低于 RAG（3.47 对比 3.64；第 5 节）。自然的修复方法——将原始文档编译为结构化维基——因编译过程中的信息丢失而灾难性失败：LLM 编译器过度压缩了 22–3 倍，超出了目标，丢弃了关键事实，得分仅为 2.14–2.32，对比原始全上下文的 3.47（第 6 节）。

#### WiCER。
我们提出 *WiCER*（Wiki-memory Compile, Evaluate, Refine），一种关闭此编译鸿沟的迭代算法。受 CEGAR Clarke et al. (2000) 启发——每当虚假反例揭示精度不足时精炼抽象模型——WiCER 针对诊断探针评估每个已编译的维基，诊断编译器丢弃了哪些事实，并强制下一次编译保留它们。在十七个主题中，一到两次 WiCER 迭代恢复了盲目编译损失的 80% 的质量（15 个有基准的主题平均分为 3.24，对比原始全上下文的 3.47），相对减少了 55% 的灾难性失败（第 7 节）。至关重要的是，在部署系统中，真实查询流可以作为免费、持续更新的探针集：常见问题自然地揭示用户最需要的 facts，从而无需合成探针即可驱动持续的维基精炼。

我们的贡献包括：(1) *WiCER* 算法，一种带有失败驱动事实固定的迭代编译-评估-精炼循环，在 17 个 RepLiQA 主题中恢复了 80% 的盲目编译质量差距，相对减少了 55% 的灾难性失败；(2) 一项*消融研究*，确认 WiCER 的收益来自有针对性的诊断（相对于盲目编译 +0.95），而非通用固定（+0.16）；(3) KV 缓存维基的*操作包络*，刻画了文档数量交叉点以及影响质量的对立力量（注意力稀释与信息丢失）；(4) *端到端方案*——WiCER 实现；以及 (5) 涵盖 17 个领域和 6,800 个问题的*可重复基准*。

## 2 相关工作

#### 检索增强生成。
RAG 由 Lewis et al. (2020) 引入，作为一种结合参数化和非参数化记忆以用于知识密集型任务的方法。稠密段落检索 Karpukhin et al. (2020) 建立了使用双编码器架构的高效稠密检索。Sentence-BERT Reimers and Gurevych (2019) 为语义搜索提供了轻量级句子嵌入。后续工作探讨了分块策略以及检索精度与上下文利用率之间的权衡 Gao et al. (2024)。我们的工作直接将 RAG 与将整个语料库加载到上下文中的替代方案进行比较。

#### KV 缓存优化。
高效的 KV 缓存管理对于长上下文推理至关重要。Pope et al. (2023) 分析了大模型的内存受限推理。PagedAttention Kwon et al. (2023) 实现了服务的高效内存管理。量化 KV 缓存（例如，q8_0）在保持质量的同时减少内存占用 ggml-org (2024)，近期工作表明低至 2-bit 精度的可行性 Liu et al. (2024c)。Flash Attention Dao et al. (2022); Dao (2023) 加速了预填充和解码。MInference Jiang et al. (2024) 通过识别每个注意力头中的动态稀疏注意力模式（A-shape, Vertical-Slash, Block-Sparse）并仅计算显著条目，直接解决了预填充瓶颈，在长上下文上实现了高达 10 倍的预填充加速，无需微调。我们的基准专门衡量在比较设置下缓存和上下文传递优化对端到端的影响。

#### KV 缓存共享与分离。
最近的系统支持在请求和机器之间共享、组合和分布 KV 缓存：RadixAttention Zheng et al. (2024b) 用于前缀感知的重用，Mooncake Qin et al. (2025) 用于分层分离，CacheBlend Yao et al. (2025) 用于非前缀缓存组合，CacheGen Liu et al. (2024b) 用于压缩流式传输，ChunkAttention Ye et al. (2024) 用于运行时前缀共享，以及 Prompt Cache Gim et al. (2024) 用于可重用注意力状态。RAPTOR Sarthi et al. (2024) 构建层次化文档树，自然地映射到按主题组织的缓存分片。

#### 知识编译与缓存增强生成。
作为查询时检索的一种新兴替代方案，是离线*编译*知识并从缓存中提供服务。Karpathy 的*LLM Wiki*模式 Karpathy (2026) 提出了三层架构：原始源文档被提炼为结构化维基，进一步浓缩为模式和摘要；编译后的工件（~100K 令牌，对应 ~100 篇文章）加载一次并缓存。Chan et al. Chan et al. (2025) 将其形式化为*缓存增强生成*（CAG）：将所有相关知识预加载到 LLM 的上下文中，缓存 KV 状态，并以零检索开销提供服务。CAG 完全消除了检索失败，但当文档数量变大时会继承*迷失在中间*（lost in the middle）问题 Liu et al. (2024a)。我们的工作首次对这些想法进行了大规模实证测试，量化了编译为单一上下文何时失效（第 5 节）。

#### 结构化知识编译。
几种方法在检索或生成之前将文档组织为更丰富的中间表示。RAPTOR Sarthi et al. (2024) 递归地将文档块聚类并总结为树，支持在多抽象级别进行检索。GraphRAG Edge et al. (2024) 提取实体关系图并生成社区摘要，支持跨越多个文档的全局查询。经典层次化摘要 Chang et al. (2023) 以递增粒度构建自底向上的摘要。这三种方法都产生静态编译：一旦树、图或摘要层次结构建立，它就是固定的。WiCER 在两个方面有所不同：(1) 它针对的是优化用于 KV 缓存服务的*扁平*维基工件，而不是检索索引；(2) 它通过针对诊断探针评估已编译工件并迭代地精炼它来闭环——这是一种静态编译管道中缺乏的反馈机制。

#### LLM-as-Judge 评估。
使用 LLM 评估生成文本已成为人类评估的可扩展替代方案 Zheng et al. (2024a); Chiang and Lee (2023)。我们遵循这一范式，使用带有结构化评分标准的 Claude Sonnet，对两种方法应用相同的法官以确保公平比较。在本文中，我们使用一个小样本（100 样本）的人类评估来验证这种法官方法（附录 J）。

## 3 实验设置

### 3.1 文档语料库

#### Policygenius（精选）。
30 篇 Policygenius<sup>1</sup><sup>1</sup>https://www.policygenius.com/articles 文章（~67K 令牌总计，~2,250 令牌/文章，占 96K 上下文窗口的 70%），涵盖人寿保险、残疾保险和遗产规划。这些经过编辑精选的文章在 Karpathy 的分类中已经构成了*已编译维基* Karpathy (2026)，使其成为全上下文推理的最佳情况。

#### RepLiQA（原始，多领域）。
RepLiQA Montero et al. (2024)（NeurIPS 2024）是一个无污染 QA 基准：所有文档均为合成生成，并验证不存在于训练语料库中。它涵盖 17 个主题领域，每个主题有 80 篇文档和 400 个 QA 对（1,360 篇文档，6,800 个问题，~1.5M 令牌总计）。每个主题的语料库从 55K 令牌（公司政策，~690 令牌/文档，占 96K 窗口的 57%）到 95K 令牌（地方民俗，~1,190 令牌/文档，占窗口的 99%）不等。每个问题只能从其源文档回答，从而能够精确测量检索准确性。与 Policygenius 不同，这些原始文档未经编辑编译，使其成为编译鸿沟（第 6 节）和 WiCER（第 7 节）的试验台。

### 3.2 问答生成

对于 Policygenius，我们使用 Claude Sonnet 生成了 240 个问答对（每篇文章平均 8 个），每篇文章产生 5–10 个多样化问题（事实性、定义性、比较性、实用性），每个答案*仅*能从其来源回答，并标记有源文件名。RepLiQA 自带每个主题 400 个 QA 对（总计 6,800 个），由 Montero et al. (2024) 生成和验证。第 4 节使用 Policygenius 语料库建立精选知识的全上下文 KV 缓存优势；第 5–7 节使用 RepLiQA 在 17 个领域中对可扩展性、编译和 WiCER 进行压力测试。

### 3.3 系统配置

所有实验均在 Apple M4 Pro（24 GB 统一内存）上运行，使用来自 llama.cpp 生态系统 ggml-org (2024) 的 `llama-server`，它支持在消费级硬件上使用 GGUF 量化模型进行高效本地推理。Apple Silicon 的统一内存架构特别适合 LLM 推理，因为 GPU 可以直接访问模型权重而无需 PCIe 传输。我们使用 Llama 3.1 8B Instruct Q5_K_M Dubey et al. (2024)，96K 上下文窗口，q8_0 KV 缓存，Flash Attention（Metal），以及贪心解码（T=0）。

### 3.4 推理配置

#### 全上下文。
所有 30 篇文章连接为单个系统提示（~67K 令牌）。预飞行请求预热 KV 缓存；后续查询