FLARE：在生成中主动检索
FLARE 是一种在答案生成过程中按需发起检索的方法。原论文介绍了通过检索指令触发的版本与直接使用 token 概率的版本，本篇重点讲后者，即 FLARE direct。
FLARE direct 先预测下一句可能写什么，再由程序检查草稿中是否有低概率 token，以此决定是否检索。需要检索时，系统用草稿构造查询，查到资料后重新生成这一句。生成模型提供草稿和概率，不需要为这套触发机制额外训练检索分类器。
写一段长说明时，回答开头需要的资料与后面未必相同。解释差旅申请流程可以先引用提交规则，写到付款环节才需要支付时限。如果检索查询始终只有最初那句用户问题，后半段可能缺少直接证据。FLARE 用接下来要写的内容确定补查方向，草稿要经过这一轮处理后才会成为正式回答。
先预测下一句，再决定是否检索
每一轮生成接收用户任务、已生成文本，以及当前可用的检索资料。系统预测下一句草稿，并取得草稿中各 token 的概率。
设草稿有若干 token，对应概率为 p1, p2, ...。当任一 token 的概率低于触发阈值 θ时，FLARE direct 发起检索；否则接受该句并继续生成。这个判断可以写成 min(p1, p2, ...) < θ。若接口返回的是 log probability，应先转换到对应的概率尺度，或在对数尺度下比较相应阈值。
生成下一句草稿及 token 概率
├── 全部概率达到阈值 → 接受该句 ─────────────────┐
└── 存在低概率 token → 围绕草稿构造 query │
↓ │
检索资料 │
↓ │
用新资料和此前正文重新生成这一句 │
↓ │
接受该句 ─────────────┤
↓
进入下一轮概率低只是一项触发信号。它不等于事实错误，概率高也不保证事实正确。
查询怎样利用草稿
直接拿整句草稿搜索，可能把猜错的实体或数字当成查询条件。论文介绍了两种处理：一种遮去低置信度 token，把余下内容作为隐式查询；另一种针对低置信度部分生成显式问题。
用于遮去 token 的阈值 β 与是否触发检索的阈值 θ 职责不同。前者决定 query 保留什么，后者决定这一轮查不查。调参时混用它们，会同时改变检索频率和查询内容，难以定位效果变化。
例如用户原本询问 2026 年境内差旅流程，模型草稿为：“审批通过后，款项会在两个工作日内支付。”假设“两个”对应的 token 概率偏低，可以构造如下查询：
隐式查询：2026 年境内差旅 审批通过后 款项 工作日内支付
显式问题：2026 年境内差旅报销审批通过后，支付时限是多少？隐式查询保留了付款事件和时间单位，删去了草稿猜测的时长；显式问题则把这个信息缺口直接改写成问句。两者都可以避免用“两个工作日”约束搜索结果。
工程实现还应让后续查询继承原问题的年份、适用范围，以及应用可信状态中的权限过滤条件；下一句草稿只提供补查方向，不能重置这些约束。
查到之后为什么要重新生成
差旅条款规定：2026 年境内差旅结束后 30 个自然日内提交，审批通过后 5 个工作日内支付。检索返回支付条款后，模型应基于新资料重写刚才那句，保留“审批通过后”和“工作日”两个限定。
模型据此重新生成：“审批通过后，款项在 5 个工作日内支付。”这句被接受后，才进入正式回答，随后再预测下一句。
重新生成针对整句进行。若草稿写的是“提交后两个工作日内支付”，只把“两”替换为“五”仍会留下起算事件错误。新证据需要同时修正时长、单位和前提。
如果补查没有找到支付时限，这句就没有获得新的事实依据。应用需要允许省略未知部分或结束回答，并设置补查次数上限，避免同一个信息缺口反复触发检索。
接口与延迟上的前提
实现 FLARE direct 要能获得生成 token 的概率，并控制草稿生成、句子切分和重新生成。只有普通文本输出、没有 logprob 的接口，无法直接实现这一版本。改为让 LLM 判断“这句话需要查证吗”可以做实验，但那是另一个触发器。
生成草稿再检索、再重写，会增加串行依赖。长文本包含多个触发点时，端到端延迟不容易预测。因此应记录句子级触发次数与重生成耗时，并设置检索次数、总时间和最大输出长度等限制。
流式界面还需要区分草稿与已接受的正文。若把未核验草稿立即发给用户，随后检索才发现数字错误，纠正就变成了用户可见的反复改口。
哪些任务值得尝试
长篇知识性回答、人物或项目综述等任务，会在生成推进时引入新事实，比较符合 FLARE 的设计动机。只回答“提交期限是多少”这样的短问题，预先检索通常更直接。
低频专名、产品编号和少见表达也会触发低概率。对型号问答，先用型号精确检索可能更可靠。反过来，模型熟悉的过期说法可能获得很高概率，FLARE 也可能不触发。因此不能用它替代当前制度必须检索的业务规则。
调整触发阈值时，可以记录草稿、低概率位置、检索查询和重写句子，逐条查看补查修正了什么。把 FLARE 与生成前一次检索、每句固定检索对比，才能判断按需触发是否既补到了后续证据，又减少了不必要的调用。