AI-Workshop 文献分享 #23 — WiCER：知识增强型推理的 Wiki 记忆编译、评估与精炼

分享人：qyr | 日期：2026-09-12 21:30

论文：WiCER（Wiki-memory Compile, Evaluate, Refine）

主题：WiCER（Wiki-memory Compile, Evaluate, Refine）—— 借鉴 CEGAR 思想修补 Compilation Gap

---

这篇文献属于知识增强型推理的范畴

文献沿革

知识增强型推理，在于解决一个问题：LLM如何记住专业知识，避免胡编乱造。

RAG

RAG是最先的尝试，其思想为：将知识作为提示词的一部分。
- 1.将知识文档（文本）做切块（chunk）
- 2.使用Embedding，将每一个chunk转为向量
- 3.用户提问后，将提问也转为向量，计算和每一个chunk的相似度
- 4.返回相似度最高的chunk文本
- 5.将文本接入用户提示词，再提交给LLM

RAG是独立于LLM的，可以方便的扩展（加chunk就行）。当前的扩展RAG还可以保存多模态数据和DB

但是RAG也有缺陷，包括：
- 首token延迟，因为查RAG不是LLM的开销，需要额外花费时间走另外的程序
- 多跳难题：chunk间可能有跳转，但是单纯的RAG无法实现
- 检索失败，返回空chunk，LLM仍然会报错

CAG

CAG全称是Cache-Augmented Generation，原理是把文档放进KV缓存里

具体来说，对于transformer，其注意力层一般公式是：

其中，Q K V是矩阵，有通过训练的 \(W_Q, W_K, W_V\) 和输入的提示词token组成的矩阵\(X\)相乘得到

每次提新的问题，会输入新的 \(X_{new}\)，得到新的 \(Q_{new}, K_{new}, V_{new}\)
其中，\(K_{new}, V_{new}\)会被拼接在原先的K和V上，即 \(K \gets (K;K_{new}); V \gets (V;V_{new})\) 新的\(K,V\)保存了历史知识

CAG就基于上述的想法，在使用LLM前，先提前将文档喂给LLM，生成对应的KV-cache，这样大模型就拥有了一部分知识。
区别于普通对话的KV缓存，这部分缓存被冻结了，除非需要更新知识，不然不会改变，保证每次都能使用到；普通对话的缓存会动态的清理（如用LRU算法）。

CAG一定程度解决了RAG的问题：
- 不需要访问其他程序，没有额外开销，TTFT很小
- 不存在chunk的说法，相当于直接了解了全文，解决了多跳推理的问题
- 不再检索，因此不会出现检索是错误，当然没有的知识仍然不会回答

但是CAG也有劣势：
- 上下文窗口限制，K和V的大小 - 显存开销大，因为每次回答问题都要加载知识库缓存进显卡
- 知识库更新成本高，每次更新需要重置KV缓存
- 注意力稀释问题（Compilation Gap 编译缺口），太大的缓存会导致softmax时的QK太大，单个token得到的概率变低

LLM-Wiki

LLM-Wiki的目标是解决CAG的问题，其方法很简单：用尽可能精简、结构化的方式保存知识，用来压缩CAG的大小
目前并没有一个软件或者严格的校验机制，这个思想更像一个总纲，其思想包括：
- 用md保存整理后的知识
- 保存原始文档到raw/目录，AI可溯源，只读不改
- 一个页面仅保存一个主题
- 通过[[另一个页面]]的方式实现链接，支持多跳
- TLDR前置，即加一个frontmatter用来概括基本信息
- 索引页面index.md，用来做目录
- 页面规范，不同类型的页面负责不同的功能（如摘要、实体、概念、对比）
obsidian就是根据这些原理设计的，也有系列技能，包括wiki-init、wiki-ingest、wiki-lint、wiki-query等
用LLM-Wiki整理好的知识，再保存进CAG，可以有效的减小CAG大小

附上一个链接，供了解

但是LLM-Wiki的问题很明显，就是编辑文档会丢失信息，尤其在知识很多的时候，也叫做 Compilation Gap（编译缺口）

WiCER：Wiki-memory Compile, Evaluate, Refine

这篇论文借鉴了CEGAR的思想，解决的问题是 Compliation Gap。 其思路是构建QA探针来检测CAG中是否存在需要的知识，并将缺失的知识补充回Wiki

QA探针

本质上就是让LLM构建问题Q，并且准备好答案A： 将Q输入给带有Wiki-CAG的LLM，让他回答，然后和A比对，并让LLM打分。 如果评分低，则说明该问题没有被加入到Wiki中。
实验中，每一个事实文档raw仅生成一个QA对

诊断和优化

对于失败的QA对，去对应的文档里提取相关的最简知识，重新加入Wiki，得到迭代后的Wiki
然后，重新获取CAG

迭代

重复上述操作，直到停止条件，包括：
- 提升小于10%
- 没有错误的QA对
- 到达最大迭代次数

原文发现，一般迭代1~2轮就达到极限，因为存在知识置换现象：
因为Wiki的总长度受到限制（保证CAG不要太大），总有一些知识保存不进来，加入新的知识会挤出旧的知识

消融实验

本文的消融实验测试的是QA探针的作用。
对于回答失效的raw，使用其中随机文本代替QA问题的最简知识输入进CAG，提升很小，证明提取最简知识是必要的。

商业应用

本文提出设想：QA探针不必事先由LLM主动，可以在生产环境中，将用户的提问保存为Q，这样可以针对用户关心的问题做Wiki增强