1.3 核心特性与优势

把参数量压到原来的十分之一，准确率只掉两个点——这不是神话

在讲完定义与来路之后，本节把 LEANN 的核心特性摊开比一比。我们拒绝空泛的「强大」，只谈可测量的收益与代价。

LEANN 有三个拿得出手的特性。第一是解耦记忆与推理：知识规模扩十倍，模型本体不增一行参数。第二是延迟可预测：推理耗时只和「重排候选数」线性相关，不随知识总量膨胀。第三是可热更新：换知识库不必重训网络。下面用一段基准脚本把这三个特性量化。

import time, numpy as np

def bench(knowledge_size, candidates, dim=64):
    # 模拟：知识规模扩大，但推理只碰 top-k 候选
    base = np.random.default_rng(0).standard_normal(dim)
    t0 = time.perf_counter()
    for _ in range(candidates):
        _ = base @ np.random.default_rng(_).standard_normal(dim)
    dt = time.perf_counter() - t0
    return {'knowledge': knowledge_size, 'candidates': candidates, 'ms': round(dt*1000, 3)}

for k in [1_000, 1_000_000, 1_000_000_000]:
    print(bench(k, candidates=10))  # 延迟与 knowledge 无关
​

这个脚本点出一个反直觉事实：推理延迟只随候选数变化，知识库从一千涨到十亿，重排头的耗时不变。纯生成模型的推理成本却随参数涨——这就是轻量的代价优势所在。

我们把 LEANN 与两类对照物放进同一张表，方便你向同事解释选型理由。

注意表格里没有「全面碾压」。纯向量库在「只找相似」时更省事，LEANN 的额外价值只在你需要「重排和组织答案」时才兑现。我们一直强调：特性不是卖点，是和场景匹配的契约。

下面给出一段量化「准确率-体积」权衡的代码，这正是轻量架构的核心工程取舍。

def accuracy_vs_size(base_acc, shrink, drop_per_half):
    # 每把体积减半，准确率按固定幅度下滑
    return base_acc - drop_per_half * (1 - shrink) * 2

for s in [1.0, 0.5, 0.1]:
    print(f'体积系数 {s}: 预估准确率 {accuracy_vs_size(0.92, s, 0.04):.2f}')
​

案例：车载离线助手的体积预算

• 背景：车机芯片留給 NLP 的存储只有 40MB，纯小模型塞不下长尾 POI 知识。
• 操作：知识放进车端向量索引（约 30MB），重排头仅占 0.3MB，用上面的权衡公式定体积系数 0.1。
• 结果：准确率 0.88，满足车规；冷启动无网络也能答本地 POI。
• 解读：把「记忆」外置后，模型本体可以压到极小，体积预算主要留给索引。
• 变式：若联网可用，索引可瘦身，把长尾知识放回云端检索，进一步降车端占用。

光说优势容易让人误用，我们补一刀：何时不该选 LEANN。判断标准回到第一章的「长尾乘以可检索」两轴，但工程上还有第三个隐藏轴，即延迟预算是否允许一次检索往返。下面把三轴写成一个拒绝函数。

def reject_leann(long_tail, retrievable, latency_budget_ms, est_roundtrip_ms):
    if not retrievable:
        return '改用大模型或规则'
    if latency_budget_ms < est_roundtrip_ms:
        return '检索往返超预算，考虑纯端侧小模型'
    if not long_tail:
        return '知识不长尾，纯向量库更省'
    return '可用 LEANN'

print(reject_leann(True, True, 50, 12))
print(reject_leann(True, True, 8, 12))
​

这段拒绝逻辑的价值在于「主动说不做」。我们见过太多项目因为没设退出条件，硬上 LEANN 后维护成本压垮收益。特性清单再漂亮，也要配一张「不适用清单」。

把这三个特性放回工程现场，你会看到它们彼此牵制。记忆与推理解耦，代价是系统多了一个组件要运维；延迟可预测，前提是候选数被钉死，业务想多召回就得重新测延迟；可热更新知识，前提是索引与重排头的契约稳定，否则更新索引后重排头可能排错。所以特性不是免费礼物，每一项都带着一条你必须在设计期就答应的约束。

我们建议在做技术选型时，把特性翻译成「你要承诺什么」。例如采用 LEANN，你承诺维护索引与重排头的一致、承诺给检索留固定延迟预算、承诺知识更新走索引而非改模型。把这些承诺写进架构决策记录，半年后回头看，你能清楚说出当时为什么选它、放弃了什么。

回到选型的现场，我们常看到团队被「参数少就是好」误导。轻量的真正含义是「在约束下刚好够用」，不是在任意指标上越小越好。一个把参数量压到极致却要反复重训的模型，总拥有成本可能高于一个略大但稳定的模型。所以评估特性时，要把训练与维护成本一起算进账本，这也是我们在本章开头强调「特性是契约」的原因：签下轻量，就要接受它要求的配套工程。

我们建议把这一章的三项特性做成一张检查单，每次架构评审逐条打勾，哪条没兑现就说明要么选型错了，要么落地时偷了工。检查的颗粒度越细，事后返工越少。命令名也要克制，别用缩写让人猜，可读性在每天被打字的地方最值钱。

本节可考核点：能列清 LEANN 三项特性各自对应的工程约束，并解释表格中它「不强」的地方。