← 返回 2026-02-26

NanoKnow:如何知道你的语言模型知道什么 NanoKnow: How to Know What Your Language Model Knows

Lingwei Gu, Nour Jedidi, Jimmy Lin 📅 2026-02-23 👍 7 2026-07-13 08:35
检索增强生成 知识溯源 语言模型评估 问答系统 预训练数据分析

利用开源预训练数据构建基准,量化LLM参数知识与外部知识的交互机制

前置知识

参数知识(Parametric Knowledge)

语言模型在预训练过程中通过梯度更新存储在模型权重中的事实性知识。这种知识不依赖外部检索,而是通过闭卷问答(Closed-book QA)来检验——模型仅凭自身参数就能回答问题。例如,模型参数中可能编码了“法国首都是巴黎”这样的事实。论文发现,参数知识的可靠性与预训练数据中该事实出现的频率高度相关:出现51次以上的答案准确率可达30%以上,而仅出现1-5次的答案准确率仅为10%左右。

理解参数知识是本文的核心研究对象——论文旨在量化参数知识如何被预训练数据的频率影响,以及它如何与外部知识互补。

检索增强生成(RAG, Retrieval-Augmented Generation)

在推理时将外部检索到的文档作为上下文注入语言模型,引导其生成更准确的回答。RAG的核心思想是弥补参数知识的局限性——当模型没有记住某个事实时,通过检索相关文档提供证据。在本文中,RAG的具体形式是向nanochat模型提供来自FineWeb-Edu语料库的相关文档片段(约200词的上下文窗口),作为“提醒”来辅助回答。

RAG是本文研究的另一核心对象,论文系统地比较了闭卷(纯参数知识)和开卷(参数+外部知识)的性能差异。

nanochat模型家族

由Andrej Karpathy发布的完全开源小型语言模型系列,其预训练数据为FineWeb-Edu语料库的随机打乱版本。nanochat包含三个规模:d20(约5.61亿参数)、d32(约19亿参数)和d34(约22亿参数)。由于预训练数据完全公开且可追踪,nanochat提供了一个“透明”的实验环境——研究者可以精确知道模型看过什么数据,从而真正理解知识的来源。

nanochat是本文的实验基础,其开源特性使得论文能够构建精确的“支持/不支持”标注,这是使用闭源模型无法实现的。

BM25检索

一种经典的基于词频-逆文档频率(TF-IDF)思想的稀疏检索算法。BM25通过计算查询词在文档中的出现频率和稀有程度来评分排序文档。在本文中,BM25被用于在FineWeb-Edu语料库(约9723万篇文档,索引大小326GB)上建立倒排索引,然后对每个问题检索前100个候选文档,作为投影流水线的第一步。论文使用Anserini工具构建索引,使用Pyserini进行检索。

BM25是NanoKnow投影流水线的第一步,决定了哪些文档会进入后续的答案验证流程。

答案投影(Projection)

将问答数据集中的问题-答案对映射到预训练语料库中的具体文档的过程。投影通过三步完成:BM25检索候选文档、答案字符串匹配、LLM验证过滤假阳性。投影的结果是将问题分为“支持”(答案存在于预训练数据中)和“不支持”(答案不存在)两个集合。例如,NQ数据集66.2%的问题被投影为“支持”,SQuAD为70.9%。

投影是NanoKnow的核心方法论,它使得研究者能够精确知道模型在预训练时是否见过某个问题的答案。

干扰文档(Distractor Documents)

在RAG设置中,与问题不相关但被检索系统错误召回的文档。本文研究了干扰文档对模型回答准确率的影响,包括不同位置(Far/Mid/Near)和不同数量(1/2/4个干扰文档)的组合效果。实验发现,仅使用干扰文档(无正确答案文档)的回答准确率低于闭卷设置,且随着干扰文档数量增加,准确率持续下降。

干扰文档的影响直接关系到实际RAG系统的设计——检索精度和上下文构造对最终效果至关重要。

研究动机

大型语言模型在各类任务上展现了卓越能力,但它们“知道什么”以及“如何知道”仍是未解之谜。一个核心困难在于:预训练数据通常是“黑盒”——未知或不可访问的。当研究者试图理解模型为什么能回答某个问题时,无法确定这个知识是来自预训练数据中的记忆,还是模型的多跳推理能力,亦或是某种组合。例如,当模型回答“法国首都是巴黎”时,我们不知道它是从预训练数据中记住了这个事实,还是通过参数中的其他线索推断出来的。已有研究(如Kandpal et al. 2023)尝试通过统计实体出现频率来关联预训练数据与下游能力,但由于无法访问完整预训练数据,这些方法只能提供间接证据。数据溯源方法(如FASTTRACK、OLMoTrace)虽然能将模型输出追溯到训练样本,但它们是事后的、局部的,无法系统性地评估知识来源。

本文的目标是本文的具体目标是构建一个基准数据集NanoKnow,能够精确地将问答数据集中的问题分为两类:一类是模型在预训练时“见过”答案的问题(supported),另一类是模型在预训练时“没见过”答案的问题(unsupported)。有了这个分类,研究者就能系统性地回答以下问题:(1)预训练数据中答案出现的频率如何影响闭卷问答准确率?(2)外部证据(RAG)能在多大程度上弥补参数知识的不足?(3)即使提供了外部证据,模型在“见过”和“没见过”的问题上表现差异有多大?(4)干扰文档如何影响模型的回答质量?这些问题此前由于无法访问预训练数据而无法系统研究。

与已有工作不同的是,本文的独特切入角度在于利用nanochat这一完全开源的模型家族——其预训练数据(FineWeb-Edu语料库)完全公开且可追踪。这提供了一个“透明”的实验环境,使得研究者能够精确知道模型看过什么数据。与此前依赖闭源模型(如GPT系列)的研究不同,NanoKnow能够建立精确的“支持/不支持”标注。论文的方法论是将Natural Questions(3610个问题)和SQuAD(10570个问题)这两个经典QA基准“投影”到FineWeb-Edu语料库上,通过BM25检索+字符串匹配+LLM验证的三步流水线,建立每个问题与预训练数据之间的精确关联。这种“投影”方法是系统性的、可复现的,而非基于采样或启发式的近似。

核心方法

NanoKnow的方法论可以用一个直觉来概括:如果我们知道模型预训练时看过哪些文档,就能知道它是否“见过”某个问题的答案,从而将问题分为“支持”和“不支持”两类。具体来说,论文构建了一个三步投影流水线(Projection Pipeline):首先,在FineWeb-Edu语料库(约9723万篇文档,171GB)上使用BM25建立倒排索引(326GB),然后对每个QA对检索前100个候选文档;接着,在候选文档中检查是否包含答案字符串(字符串匹配);最后,使用LLM(Qwen3-8B)过滤假阳性——因为字符串匹配可能产生巧合匹配(例如“巴黎”可能出现在关于歌曲Paris的文档中)。技术路线上,论文选择FineWeb-Edu的随机打乱版本(由Karpathy发布),确保索引与预训练数据完全一致。文档ID采用shard_XXXXX_YYYYY格式编码,可精确追踪到parquet文件中的具体行。

本文的核心创新在于:不是事后追踪模型输出到训练数据,而是事先(a priori)将任务数据集投影到预训练语料库上,建立精确的知识映射。这与已有的训练数据归因方法(如梯度分析、表示分析)有本质区别——后者是“输出→训练数据”的方向,而NanoKnow是“问题→预训练数据”的方向。这种事先投影的优势在于:(1)可以系统性地分析整个数据集,而非单个样本;(2)投影结果可以复用于不同模型规模和检查点的实验;(3)支持/不支持的标注是确定性的,而非概率性的。另一个关键创新是三步验证机制:BM25粗筛→字符串匹配→LLM验证,逐层过滤假阳性,确保标注的准确性。论文验证了这种方法的有效性:不支持集合中,nanochat-d32的闭卷准确率仅为0.8%(NQ)和1.5%(SQuAD),说明标注是可靠的。

方法步骤详情

投影流水线的完整步骤如下:第一步是BM25检索(Step 1: BM25 Retrieval)。论文使用Anserini工具在FineWeb-Edu语料库上构建倒排索引,索引大小约326GB,覆盖9723万篇文档。对每个问题,使用Pyserini进行BM25检索,返回前100个候选文档。第二步是答案字符串匹配(Step 2: Answer String Matching)。对于每个候选文档,检查是否包含问题对应的黄金答案字符串。匹配过程将所有文本转为小写并去除多余空白,然后检查答案是否作为子串出现。这一步快速但会产生大量假阳性。例如,问题“巴黎最好的面包店是什么?”可能匹配到关于歌曲Paris的文档。第三步是LLM验证(Step 3: LLM Verification)。对于通过字符串匹配的候选文档,提取答案出现位置前后各256词的上下文窗口,发送给Qwen3-8B,让它判断该上下文是否真正回答了问题。这一步过滤掉巧合匹配。完成三步后,问题被分为两类:支持(通过字符串匹配和LLM验证)和不支持(未通过任一步骤)。支持问题生成qrels文件,将问题链接到FineWeb-Edu中的具体文档;不支持问题仅提供问题文本。

技术新颖性

NanoKnow的技术新颖性体现在三个层面。首先是方法论层面:与已有的训练数据归因方法(如OLMoTrace的语义聚类、FASTTRACK的检索导向方法)不同,NanoKnow采用“事先投影”而非“事后追踪”的范式。这意味着投影结果可以在不同实验设置下复用,且标注是确定性的。其次是三步验证机制的设计:BM25粗筛→字符串匹配→LLM验证的逐层过滤是针对“假阳性”问题的有效解决方案。论文通过实验验证了这一步骤的必要性——字符串匹配后73.9%(NQ)和78.9%(SQuAD)的问题被标记为支持,但经过LLM验证后分别降至66.2%和70.9%,说明约8%的匹配是巧合。第三是实验设计的系统性:论文在三个模型规模(d20/d32/d34)、多个检查点(每规模2-3个)、两种评估方法(精确匹配和LLM-Judge)、多种实验设置(闭卷/开卷/干扰文档)下进行了全面实验,每个实验都回答了一个具体的研究问题。这种系统性在同类研究中较为罕见。

NanoKnow在问题-答案对上的示例
Figure 1: NanoKnow在问题-答案对上的示例

实验结果

论文的核心发现可以归纳为四个方面。第一,闭卷问答准确率与预训练数据中答案出现频率高度相关。在NanoKnow的四个频率桶(Rare: 1-5次, Low: 6-20次, Medium: 21-50次, High: 51+次)中,nanochat的准确率随频率增加而显著提升。以SQuAD为例,Rare频率的LLM-Judge准确率约为10%,而High频率可达30%以上——准确率翻了三倍。然而,最小的d20模型(5.61亿参数)未表现出这种频率依赖性,说明小模型可能没有足够的容量“记忆”信息。第二,RAG能缓解但不能消除频率依赖性。当提供FineWeb-Edu中的正确答案文档时,准确率大幅提升——例如SQuAD上d20模型的LLM-Judge准确率从约1%提升到约5%(4.4倍提升),d32从约17%提升到约55%(3.2倍提升)。但即使在开卷设置下,支持问题的准确率仍高于不支持问题,说明参数知识和外部知识是互补的。第三,即使提供了标准答案文档(oracle document),nanochat在支持问题上的表现仍优于不支持问题。以SQuAD(w/ Original Context)为例,d34-sft模型在支持问题上的LLM-Judge准确率为77.9%,而在不支持问题上为73.3%,差距约4.6个百分点。这证明参数知识能够增强模型对外部知识的利用能力。第四,干扰文档对准确率有负面影响。仅使用干扰文档(无正确答案)的准确率低于闭卷设置,且干扰文档数量越多、位置越靠近问题,准确率下降越明显。以NQ为例,使用4个干扰文档(Far设置)的LLM-Judge准确率从49.2%(仅答案)降至37.8%,下降11.4个百分点。

支持和不支持NQ问题的示例
Table 1: 支持和不支持NQ问题的示例
NQ和SQuAD在FineWeb-Edu上的投影率
Table 2: NQ和SQuAD在FineWeb-Edu上的投影率
NQ和SQuAD支持集合上闭卷与开卷QA的比较
Table 3: NQ和SQuAD支持集合上闭卷与开卷QA的比较
SQuAD(原始上下文)上支持与不支持问题的QA准确率比较
Table 4: SQuAD(原始上下文)上支持与不支持问题的QA准确率比较
干扰文档对nanochat(Antigma/nanochat-d32)在支持问题上有效性的影响
Table 5: 干扰文档对nanochat(Antigma/nanochat-d32)在支持问题上有效性的影响
NanoKnow支持问题按答案频率的分布(NQ和SQuAD)
Figure 2: NanoKnow支持问题按答案频率的分布(NQ和SQuAD)
预训练数据答案频率对nanochat准确率的影响
Figure 3: 预训练数据答案频率对nanochat准确率的影响
查看结构化数据
任务指标本文基线提升
NQ 闭卷问答(支持集合) LLM-Judge准确率 d34-sft最佳检查点达到28.3% d20最佳检查点为1.4% d34相对d20提升约26.9个百分点(相对提升约19.2倍)
SQuAD 闭卷问答(支持集合) LLM-Judge准确率 d34-sft最佳检查点达到22.8% d20最佳检查点为1.1% d34相对d20提升约21.7个百分点(相对提升约19.7倍)
NQ 开卷问答(FineWeb上下文,支持集合) LLM-Judge准确率 d34-sft达到52.8% d20最佳检查点为2.3% 开卷相比闭卷,d20/d32/d34分别提升约2.4x/2.1x/1.9x
SQuAD 开卷问答(FineWeb上下文,支持集合) LLM-Judge准确率 d34-sft达到58.7% d20最佳检查点为2.0% 开卷相比闭卷,d20/d32/d34分别提升约4.4x/3.2x/2.6x
SQuAD 开卷问答(原始上下文,支持vs不支持) LLM-Judge准确率 d34-sft支持问题77.9%,不支持问题73.3% d20支持问题8.1%,不支持问题6.8% d34-sft在支持问题上比不支持问题高4.6个百分点
干扰文档实验(NQ,d32,支持集合) LLM-Judge准确率 4个干扰文档(Far)下37.8% 仅答案文档下49.2% 干扰文档导致准确率下降11.4个百分点

局限与改进

论文存在几个值得讨论的局限性。首先,NanoKnow的投影方法依赖于BM25检索,这意味着如果答案出现在BM25无法有效检索到的文档中(例如需要语义理解而非词汇匹配的情况),该问题可能被错误地标记为“不支持”。论文承认了这一点,但未量化这种误差的影响。其次,LLM验证步骤使用Qwen3-8B作为判断器,引入了额外的模型偏差——如果Qwen3-8B本身存在判断错误,会影响支持/不支持标注的准确性。论文通过验证不支持集合的低准确率(0.8%/1.5%)间接证明了标注质量,但未直接评估验证步骤的精确率和召回率。第三,实验仅限于nanochat模型家族,这是一个相对较小的模型(最大22亿参数)。虽然论文的目的是利用nanochat的开源特性,但结论能否推广到更大的模型(如70B或更大)尚不确定。第四,干扰文档实验的上下文窗口限制为200词,这与实际RAG系统中的长上下文设置不同——现代LLM可以处理数万甚至数十万词的上下文,干扰文档的影响模式可能不同。第五,论文未研究多跳推理场景——NanoKnow中的问题大多是单跳的事实性问题,对于需要多步推理的复杂问题,参数知识和外部知识的交互机制可能不同。

独立分析的弱点

独立分析本文的弱点,可以发现以下几个方面。第一,BM25检索的局限性可能导致投影结果不完整。BM25基于词汇匹配,对于答案表述多样化的情况(如同义词、不同语言表达)可能漏检。改进方向是结合语义检索(如DPR或ColBERT)来提高投影的召回率,建立更全面的支持/不支持标注。第二,LLM验证步骤的可扩展性较差。当前使用Qwen3-8B逐个验证候选文档,在大规模数据集上成本高昂。改进方向是开发更轻量级的验证方法,例如基于规则的过滤器或更小的分类模型。第三,实验设置较为理想化——论文使用的是BM25检索到的正确答案文档作为oracle证据,而在实际RAG系统中,检索结果的精度远低于100%。改进方向是引入不同质量的检索结果,模拟真实的RAG性能。第四,NanoKnow仅覆盖NQ和SQuAD两个数据集,问题类型以事实性单跳问题为主,缺乏对复杂推理、多跳问题、长文档理解等场景的覆盖。改进方向是将投影方法扩展到更多数据集和任务类型。

未来方向

论文在结论中提出了几个未来研究方向。首先,虽然NanoKnow构建在FineWeb-Edu上,但其方法论可以推广到任何开源语料库——索引是一次性成本,投影新基准很快。这为研究不同语料库的组成如何影响下游能力打开了大门。其次,答案频率信息能否指导更有效的数据策展(data curation)是一个值得探索的问题——例如,在预训练时增加低频知识的重复次数是否能提升模型在这些知识上的表现?第三,论文未深入研究的主题包括:预训练数据的主题组成如何影响下游能力、数据去重和清洗对知识分布的影响、不同预训练策略(如课程学习)如何改变频率-准确率关系。基于NanoKnow的成果,还可以延伸到:研究不同规模模型的记忆容量阈值、探索RAG系统中检索精度与上下文构造的最优平衡点、开发基于频率感知的自适应RAG策略。

复现评估

NanoKnow在复现性方面做得非常好。论文在GitHub(https://github.com/castorini/NanoKnow)上开源了所有实验代码,包括评估脚本、LLM-Judge提示词和评估指标。数据方面,论文发布了qrels文件(支持问题与FineWeb-Edu文档的映射)、不支持问题集合、以及预构建的Lucene索引(326GB,托管在HuggingFace)。实验使用的nanochat模型家族全部开源,可在HuggingFace上获取(如karpathy/nanochat-d32、Antigma/nanochat-d32等)。算力方面,主要成本在于构建FineWeb-Edu的倒排索引(326GB),这是一次性成本;投影流水线的运行成本相对较低。整体复现难度中等——索引构建需要较大的存储空间和计算资源,但实验本身可以在单GPU上完成。论文的开源程度在同类研究中属于较高水平,为后续研究提供了坚实基础。