ax@ax-radar:~/all $ grep -v 'tier=excluded' stream.log
44 srcsignal 72%cycle 04:32

全部 · 2026-03-25

79 items · updated 3m ago
RSS live
2026-03-25 · 星期三2026年3月25日
22:20
32d ago
● P1arXiv · cs.CL· atomEN22:20 · 03·25
超越单一众数:用强化学习让语言模型进行分布式推理
这篇 arXiv 论文提出多答案强化学习,让语言模型单次前向生成多个候选答案。RSS 摘要称,该方法在问答、医疗诊断和代码基准上提升多样性、覆盖率、集合级校准,且生成多答案所需 token 更少。真正值得盯的是,它把部分推理时搜索压进训练目标;但具体模型规模、增幅数字和训练成本,正文摘要未披露。
#Reasoning#Code#Benchmarking#Research release
精选理由
HKR 三轴都过线:钩子是单次前向生成多答案,知识增量是覆盖率、集合级校准和 token 效率三项收益,行业共鸣点是把部分推理时搜索压进训练目标。分数没进更高档,因为摘要未披露模型规模、增幅数字和训练成本。
编辑点评
论文把单次前向扩成多答案输出,这条路我买账;但没给模型规模、增幅和训练账单,离“替代 best-of-k”还差关键证据。
深度解读
这篇论文把一个很实用的目标直接写进了训练:模型单次前向生成多个候选答案,并用强化学习去压答案分布。这个设定比“多采样几次再重排”更像产品路线,不像纯 benchmark 技巧。标题已经给出 multi-answer RL,摘要也写了问答、医疗诊断、代码都有提升;正文摘录没披露模型规模、基线名字、提升幅度、训练 token 和 RL 稳定性,所以现在还不能把它当成 best-of-k 的等价替代。 我对这条的直觉偏正面,原因很简单。过去一年大家做推理增强,主流还是把算力堆在推理时:best-of-n、self-consistency、tree search、verifier rerank,思路都一样,用更多采样换覆盖率。代价也很明确:延迟上去,token 成本上去,线上系统更难控。这个工作想把一部分搜索习惯蒸进策略里,让模型一次吐出一个“答案集合”。如果集合级校准真有提升,这对医疗分诊、agent planning、代码修复都比“单一最终答案”更接近真实需求。临床和代码这两类任务,本来就不是只看 mode。 但我对摘要里的“更省 token、还更准”有点警觉。省的是推理 token,还是把训练期开销转移走了?RL 后训练本身要不要更多 rollout、更多 judge、更多 reward shaping?摘要没说。代码任务里“substantially more accurate”也太宽了,HumanEval、MBPP、SWE-bench 这几个集合的难度和评估口径差很多,不给 benchmark 名字,判断不了含金量。我还想知道多答案之间是不是共享错误模式:看上去有多样性,实际只是同一条错误轨迹的改写。 这条还有个上下文。OpenAI、Anthropic、Google 这波产品线,近一年都在强化 test-time compute,只是包装成 reasoning mode、thinking budget、tool loop。研究圈也一直在追“搜索搬到哪里最划算”:放推理时,灵活但贵;放训练时,便宜但容易过拟合奖励。这个工作站在后者一边,我觉得方向对,但成败不在“能不能多答”,而在校准是否可信、答案集合能否覆盖尾部、训练成本会不会把推理节省吃掉。现在只有标题和摘要,我还没看到足够硬的数据。
HKR 分解
hook knowledge resonance
打开信源
85
SCORE
H1·K1·R1
20:10
32d ago
arXiv · cs.CL· atomEN20:10 · 03·25
用体分类增强结构化语义表示
该论文发布一个英语数据集,在缺少该特征的 AMR 图上补注 UMR aspect 标签,用于刻画事件的内部时间结构。正文给出标注方案、多步仲裁流程和三种基线建模实验;数据集规模、具体分数和模型名称在摘要片段里未披露。真正值得盯的是,它把 states、activities、completed events 这类体信息拉回可训练目标,而不只停在人工标注规范。
#Benchmarking#Research release#Benchmark
精选理由
触发 hard-exclusion-technical-accessibility fail:AMR/UMR体标注属于高门槛语义表示研究,对通用读者缺少入口。HKR 只有 K 成立,摘要也未披露数据集规模、模型名称和分数,所以分数压到排除档。
HKR 分解
hook knowledge resonance
打开信源
42
SCORE
H0·K1·R0
19:44
32d ago
arXiv · cs.CL· atomEN19:44 · 03·25
面向低资源小语种医疗转录的微调 LLM 评估:基于小型验证数据集
该研究用小型验证语料微调 LLaMA 3.1-8B,评估其芬兰语医疗转录效果,并做了七折交叉验证。模型得分为 BLEU 0.1214、ROUGE-L 0.4982、BERTScore F1 0.8230;正文称 n-gram 重合低,但语义相似度强。真正值得盯的是,数据来自 Metropolia 学生模拟临床对话,样本规模与部署条件正文未披露。
#Fine-tuning#Benchmarking#Metropolia University of Applied Sciences#LLaMA
精选理由
这篇稿件有一组可核对的数据:LLaMA 3.1-8B、七折交叉验证、BLEU 0.1214、ROUGE-L 0.4982、BERTScore F1 0.8230,所以 HKR-K 过线。题材局限在芬兰语医疗转录,正文未披露样本规模与部署条件,行业讨论面窄,H 与 R 都不够,放在 all。
编辑点评
这篇论文先证明了一件小事:LLaMA 3.1-8B 能吃下芬兰语医疗转录的领域微调;离临床可用还差一大截,因为样本规模、ASR链路和真实病历场景都没交代。
深度解读
论文用 LLaMA 3.1-8B 微调芬兰语医疗转录,并在七折交叉验证下报出 BLEU 0.1214、ROUGE-L 0.4982、BERTScore F1 0.8230。我的判断很直接:这更像“低资源语言可做通”的可行性演示,不是“医疗转录已可部署”的证据。 先看分数。BERTScore F1 0.8230 不算差,说明语义层面抓到不少内容。BLEU 0.1214 很低,ROUGE-L 0.4982 也只是中段。对医疗转录这类任务,我不会轻易接受“语义相似就够了”的叙事。病历里一个否定词、剂量词、时间词写错,语义向量照样能给高分,临床含义却已经变了。文章摘要没有披露 WER、医学术语错误率、药名和数值抽取准确率,也没说有没有人工医生审阅。缺这些,安全性判断立不住。 我对数据来源也有保留。语料来自 Metropolia 学生模拟临床对话,不是真实门诊,不是真实病房。模拟数据最大的问题不是“小”,而是分布太干净:口音、打断、含混指代、情绪波动、背景噪声、医患抢话,这些麻烦在真实录音里很多。芬兰语又是形态变化很重的语言,口语转书面时,词形、缩略、黏着表达都会放大评测偏差。七折交叉验证能提高统计稳定性,但如果总体样本很窄,它只是在同一分布里反复验证,外推不到医院现场。标题和摘要都没给样本量,这个缺口很关键。 我一直觉得,低资源医疗 NLP 里最容易被高估的,是“模型微调”四个字本身。过去一年不少医院文书项目,最后瓶颈都不在 base model,而在前面的语音识别、说话人分离、时间戳对齐、术语标准化和后面的 EHR 模板映射。这篇只讲 transcription,但正文片段还写了 translation,任务定义本身就有点混。如果它处理的是“口语临床对话转结构化书面记录”,那评测应该加入事实一致性和字段级指标;如果只是“音频内容转文字”,那又必须先交代 ASR 条件。现在这两层混在一起,我不太买账。 外部对比上,英语医疗转录这条线早就不是单看 BLEU/ROUGE 了。Nuance DAX、Abridge、Nabla 这类系统过去一年都把重点放在 clinician-in-the-loop、模板约束和审计轨迹,不再拿一个生成指标当交付标准。我没查到这篇有没有类似设置,摘要没有。芬兰语场景当然更难,数据也更少,所以我愿意给这篇“方向正确”的评价;但它现在证明的是,小语种专科语料哪怕不大,也能把通用 8B 模型往目标分布拉近一些。它还没有证明,模型在真实临床里能稳定少错、少漏、可追责。
HKR 分解
hook knowledge resonance
打开信源
61
SCORE
H0·K1·R0
19:39
32d ago
arXiv · cs.CL· atomEN19:39 · 03·25
为系统综述筛选微调大语言模型
研究者用超过8500条人工标注标题与摘要,微调了一个12亿参数开源LLM,用于系统综述筛选,加权F1较基础模型提升80.79%。在8277篇研究上,模型与人工编码者一致率为86.40%,真阳性率91.18%,真阴性率86.38%,多次推理结果完全一致。真正值得盯的是,这不是提示工程对比,而是任务微调在高重复筛选场景里的稳定性证据。
#Fine-tuning#Benchmarking#Research release#Benchmark
精选理由
HKR-K 明确成立:正文信息给出 8500 条标注、1.2B 开源模型、加权 F1 提升 80.79%、一致率 86.40%,信息密度够高。HKR-H 和 HKR-R 偏弱:标题学术味重,应用场景也偏垂直,所以是 all,不到 featured。
编辑点评
研究者把1.2B开源模型用8500条标注数据微调后,筛选一致率做到86.40%;这条不花哨,它提醒大家垂直任务里“小模型+真标签”还远没到头。
深度解读
研究者用8500多条人工标注微调1.2B开源模型,把加权F1拉高80.79%。我对这条的判断很直接:它证明的不是“LLM会做系统综述”,而是窄任务里高质量标签仍然比花式提示更值钱。系统综述筛选就是一个典型的高重复、低容错、规则逐步固化的流程,这类活一直适合做任务化建模,不适合拿通用模型硬压。 我一直觉得,很多团队过去一年把“提示工程失灵”误读成“LLM不适合严肃筛选”。这篇给了一个更像样的反例。1.2B参数并不大,数据量也只有8500级别,但真阳性率做到91.18%,多次推理完全一致。后一点很关键。做证据综述的人最怕的不是单次准确率不够,而是同一批文献今天过、明天不过,审计链条直接断掉。生成式模型在这类流程里一直卡在可重复性,这篇至少说明:任务微调能把随机性压到很低。 但我不太买“已经可替代人工”这层乐观叙事。正文只有RSS摘要,没披露基础模型名字、训练切分、类别分布、纳排标准复杂度,也没说人工编码者是一人还是多人。86.40%一致率看着不错,可系统综述里更关键的是漏掉关键研究的代价。91.18%真阳性率换算过来,漏检率接近8.82%;对医疗和政策综述,这个数未必够安全。文章也没给置信区间,没说是否做跨主题外推,所以现在只能说“适合辅助初筛”,还谈不上稳定替代。 放到更大的技术背景里,这条其实和今年很多企业实践是同一路子:别急着把通用模型塞进工作流,先把高频、标签清楚、审计要求强的环节拆出来做轻量微调。我记得过去一年临床NLP和客服质检里也反复出现同样结果,7B以下模型在专域分类上经常能打平甚至超过大模型零样本。这个趋势不性感,但很实用。要是后续能补出外部验证集、不同综述主题迁移结果,以及和强基座模型加RAG的正面对比,这篇的说服力会高很多。现在这更像一个扎实的工艺证明,不是能力边界的突破。
HKR 分解
hook knowledge resonance
打开信源
70
SCORE
H0·K1·R0
19:26
32d ago
● P1arXiv · cs.CL· atomEN19:26 · 03·25
SlopCodeBench:评测编码代理在长周期迭代任务中的退化
SlopCodeBench用20道题、93个检查点评测11个编码代理,结果没有任何模型能端到端解完整题,最高检查点通过率只有17.2%。基准跟踪冗余度与结构侵蚀两项轨迹指标;80%轨迹侵蚀上升,89.8%轨迹冗余上升,代理代码比48个开源Python仓库平均冗长2.2倍。真正值得盯的是,单次pass-rate没测到可扩展性,正文给出的结论是当前代理缺少迭代开发所需的设计纪律。
#Agent#Code#Benchmarking#SlopCodeBench
精选理由
HKR 三项都成立:标题有明确失败钩子,正文也给出20题、93检查点、11个代理、17.2%最高检查点通过率等硬数据。它讨论的是编码代理在迭代开发里出现退化,不是单次刷题表现,和开发团队的真实使用场景贴得很近,所以进 featured。
编辑点评
SlopCodeBench把编码代理的短板钉死在 93 个检查点上:它们会写能过测的代码,但还不会维护自己写出来的系统。
深度解读
SlopCodeBench 用 20 道题和 93 个检查点测了 11 个编码代理,结果是 0 个模型能把整题从头走到尾,最高检查点通过率只有 17.2%。我对这条的判断很直接:这不是“代码代理还差一点”,这是今天主流评测把最贵的失败阶段基本跳过去了。单步生成、一次性修 bug、局部补丁,这些环节模型已经能刷出不错分数;连续 5 到 10 次需求变更后,自己还能看懂自己先前的结构,这件事它们还不会。 这组结果扎到行业痛点,是因为它测的不是单次 correctness,而是迭代开发里的 design discipline。文中给了两个轨迹指标:结构侵蚀在 80% 轨迹里上升,冗余度在 89.8% 轨迹里上升,代理代码比 48 个开源 Python 仓库平均冗长 2.2 倍。这个口径我买账,至少比只看 final pass rate 靠谱。很多团队这两年都被 SWE-bench 一类榜单带偏了:修一个 issue、过一组测试,和持续扩展同一代码库,根本不是一个难度曲线。我印象里 SWE-bench Verified 上顶级系统已经能做到相当高的解决率,但那类任务大多还是“找到点、改掉、回归测试”。SlopCodeBench 在问另一件事:你前一轮为了快,埋下了多少下一轮要还的债。 我也有保留。正文只有 RSS 摘要,没披露 11 个模型具体是谁、有没有配工具、上下文窗口多大、是否允许测试反馈压缩进记忆,也没看到 checkpoint 难度分布。17.2% 这个数字很刺眼,但如果里面混了弱基线和强基线,信息量会打折。还有一个细节我很想看:所谓 structural erosion 的计算,是否会把某些合理的“临时集中复杂度”也记成退化。复杂函数不一定就是坏设计,关键是它会不会阻断后续修改。摘要没展开,我没法替作者补完。 但即便把这些疑问都算进去,结论还是站得住:现在很多 coding agent 的强项是局部搜索加语法产出,不是长期软件演化。你看 Anthropic、OpenAI、Google 这一路产品发布,演示常常是“几分钟搭个 app”“自动补全一大段功能”,很少有人把同一仓库喂给代理连做 8 轮需求,再看 diff 会不会开始发烂。这个缺口过去一年其实越来越明显。Cursor、Cline、Aider 这类工具在真实开发里有用,我自己也见过团队靠它们提速;但只要进入第二周、第三周,大家就会开始立规矩:限制改动面、强制测试、先写计划、禁止无关重构。人类工程师加上的这些护栏,本身就在说明模型没有把“收敛地改代码”学稳。 摘要里还有个点我觉得很关键:prompt intervention 只能改善初始质量,拦不住后续退化。这个发现很伤现在很多产品叙事。因为它暗示问题不在提示词技巧,而在状态表示、记忆压缩、代码编辑策略、还有对架构约束的内化。你让代理“保持简洁”“不要重复”,第一轮它会听;第五轮需求一变,它还是会复制、堆条件分支、把复杂度塞进几个巨函数。这个模式跟人类初级工程师很像,只是模型犯错速度更快,输出量更大。 所以这篇东西的价值,不是又多了一个 benchmark,而是它把 coding agent 的评测单位往前推了一格:从“会不会解题”推到“会不会把未来的问题越做越难”。这对做产品的人是个硬提醒。你如果还在拿单次 pass rate、单 PR 成功率当核心卖点,那个数已经不够用了。更接近生产现实的指标,至少要把多轮修改后的代码体积、重复率、复杂度集中度、回归失败率一起拉进来。标题说得很准,slop 不是输出丑一点而已,slop 会吃掉后续迭代速度。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
19:00
32d ago
NVIDIA 博客· rssEN19:00 · 03·25
AI 的未来将同时是开放的和专有的
这篇文章提出,AI 的未来将同时包含开放模式和专有模式两种路径。当前可确认的信息只有标题,正文未提供,因此没有更多数字、机制或可复现条件可供补充。对从业者而言,这表明文章讨论的是 AI 生态形态而非具体产品更新。
#NVIDIA#Commentary
精选理由
这是一篇只有标题可见的观点文,触发 hard-exclusion-零来源内容:没有数据、案例或具名事实支撑,重要性上限 39。HKR 三项都不成立;正文只确认讨论方向,未给从业者可验证的新信息。
HKR 分解
hook knowledge resonance
打开信源
45
SCORE
H0·K0·R0
17:56
32d ago
● P1arXiv · cs.CL· atomEN17:56 · 03·25
比较开发者与 LLM 在代码评估中的偏差
论文提出 TRACE 框架,在聊天编程、IDE 自动补全、指令式代码编辑 3 类场景中,比较 13 个 LLM 评审与开发者偏好的偏差。结果显示,表现最好的模型评审仍比人工标注者低 12% 至 23%,并识别出 35 个显著错位来源;真正值得盯的是,多数错位对应现有代码质量维度,像聊天编程里模型偏好更长解释,人类更偏好更短解释。
#Code#Benchmarking#Alignment#Research release
精选理由
这篇 arXiv 论文有明确的新信息密度:TRACE 覆盖 3 类代码场景,比较 13 个 LLM,并量化出最优模型评审仍落后人工 12%-23%。HKR 三项都成立,尤其 K 和 R 很强;但它还是研究论文,不是主流产品发布或行业事件,分数放在 78-84 档。
编辑点评
TRACE 比对 13 个模型评审后,最佳者仍落后人工 12%到23%。这条把“用模型给代码模型打分”这套省事流程先打回审查期。
深度解读
TRACE 在 3 类编程场景里比较 13 个模型评审。最佳模型对开发者偏好的拟合,仍比人工标注低 12%到23%。我对这条的判断很直接:代码评测圈这两年把 LLM-as-a-judge 用得太顺手了,顺手到很多团队已经把它当近似真值;这篇论文是在提醒大家,评审器本身带着稳定偏置,而且这些偏置不是随机噪声。 有意思的点,不是“模型还不如人”这句废话,而是作者说他们抓到了 35 个显著错位来源,且多数能映射回现有软件工程质量维度。这个结果我比较买账。因为代码任务的争议,很多时候本来就不在“能不能运行”,而在解释长度、局部改动幅度、可维护性、风格一致性、是否过度设计。摘要里给的例子很典型:聊天编程里,模型评审偏好更长解释,人类更偏好更短解释。这个偏差会直接污染 leaderboard。谁更会写长答案,谁就先吃评审红利;但开发者在 IDE 里常常只想快一点拿到可用补丁,不想读一段教科书。 这跟过去一年代码 benchmark 的走向是连着的。我记得从 SWE-bench 系列、LiveCodeBench,到不少内部 agent 评测,大家都在努力把“跑通单测”之外的东西纳入打分。问题是,一旦主观维度上升,很多团队就会把裁判外包给更便宜的模型。成本是降了,评审口径也一起漂了。OpenAI、Anthropic、Google 去年都拿过自家模型做 judge,我不觉得这件事本身有问题;问题在于,很多报告只给相关性,不给错位剖面。TRACE 这类 rubric 级拆解,至少比“judge agrees with humans by X%”更像能落地的审计工具。 我也有保留。正文片段没披露 13 个模型具体是谁,没给场景数据量,没说人工标注者人数、资历、互标一致性,也没说明 12%到23%用的是什么指标。没有这些,论文的外推范围要收着看。比如如果人类偏好本身分歧很大,模型落后 12% 未必致命;反过来,如果任务是高一致性的代码编辑,落后 12% 就已经足够让排序失真。我还没查到 TRACE 抽 rubric 的自动化过程有多少人工介入。若提取步骤本身依赖强模型总结,偏差会不会被“分析器”再放大一遍,这个我想看原文再下结论。 但有一件事已经够清楚:别再把 judge model 当中立仪器。它更像带权重的评审员,而且权重和开发者不一样。对做 coding agent 的团队,比较实际的做法不是停用 LLM judge,而是把它降级成第一层筛子:先用它压缩候选,再拿人工偏好集做定标,再按场景拆 rubric。聊天编程、补全、指令编辑,三类任务的偏好函数本来就不是一个东西。还拿单一 judge 通吃,只会把产品往“会讨好裁判”的方向推,而不是往“开发者真想用”的方向推。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
17:55
32d ago
arXiv · cs.CL· atomEN17:55 · 03·25
当一致性变成偏差:半结构化临床访谈中的采访者效应
论文分析 ANDROIDS、DAIC-WOZ、E-DAIC 3 个数据集,发现抑郁检测模型会利用采访者固定提示词和提问位置区分病例与对照。摘要称这种偏差跨数据集、跨模型架构存在;只保留受访者发言后,决策证据更分散,也更接近真实语言线索。真正该盯的是评估方法:正文摘要未披露具体分数,但已说明把采访者话语算进去会抬高成绩。
#Interpretability#Benchmarking#ANDROIDS#DAIC-WOZ
精选理由
HKR-H 和 HKR-K 成立:标题有反转,摘要也给出 3 个数据集上的具体偏差机制。分层仍是 excluded,因为它属于临床科学 + AI 交叉,正文没有 agent、模型发布或产品链条含义,触发硬排除 4,分数封顶 39。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H1·K1·R0
17:54
32d ago
● P1arXiv · cs.CL· atomEN17:54 · 03·25
检索变强不等于答案更好:面向 AI 政策问答的 RAG 研究
这篇研究用含947份AI政策文件的AGORA语料评估RAG,结论是领域微调虽提升检索指标,却未稳定提升端到端问答表现。系统采用经对比学习微调的ColBERT检索器,并用DPO按人工偏好对生成器做对齐;实验还发现,语料缺少相关文件时,更强检索反而会放大高置信幻觉。真正值得盯的是组件分数上涨≠答案更可靠,做政策RAG要把缺文档场景单独当风险面处理。
#RAG#Fine-tuning#Benchmarking#AGORA
精选理由
HKR 三项都成立。论文在 AGORA 的 947 份 AI 政策文件上给出一个可复现的反直觉结论:检索指标上涨,没有稳定带来更好的端到端回答,缺文档时还会放大高置信幻觉。它对做 RAG 评测的人很有料,但影响面仍窄于主流模型或产品发布。
编辑点评
AGORA 用 947 份政策文件证明了一个常被产品团队回避的事实:检索分涨了,答案未必更真,甚至会更自信地错。
深度解读
这篇 paper 把很多政策 RAG 项目里一个被 KPI 掩盖的问题摊开了:AGORA 在 947 份 AI 政策文件上提升了 ColBERT 检索指标,但端到端问答没有稳定变好,缺文档时还会把幻觉讲得更笃定。这个结论我基本买账,因为政策问答从来不是“找得更准”就结束,后面还有证据覆盖、冲突条款消解、时间效力判断、司法辖区映射这几层。检索器只把上下文喂进去,生成器会不会把“不完整证据”包装成“完整答案”,这是另一套机制。 我一直觉得,很多团队把 RAG 评估做成了组件崇拜:Recall@k、nDCG、MRR 漂亮,demo 就敢上线。这个习惯在企业知识库里已经有问题,到了政策领域会更糟。法律和监管文本的麻烦,不是语义匹配难,而是“缺一条就错方向”。比如欧盟 AI Act、NIST AI RMF、白宫 EO、各国行业指引经常互相补充,生效时间和适用范围还在变化。你把最像的 5 篇文档找全,不等于你找到了决定答案的那 1 篇。文章里说 stronger retrieval 在相关文档缺失时会放大高置信幻觉,这点很关键:检索越强,生成器越容易误以为“证据已经够了”,然后把局部相关性说成完整结论。 这也解释了一个过去一年很常见的落差。很多公开 RAG benchmark 都把任务设成“答案就在库里”,所以 reranker、domain tuning、query expansion 一上,分数就涨。我记得 FinanceBench、一些 legal QA set 也暴露过类似问题:引用更像,不代表结论更稳;尤其在开放世界或库不完备时,系统缺的不是排序能力,而是知道自己不知道。这里 AGORA 的价值,不是又做了一个领域 benchmark,而是把“corpus coverage failure”单独拎成风险面。说实话,这一步比再卷 2 个点的 retrieval metric 更有用。 但我对这篇研究也有保留。正文摘要只给了 ColBERT 对比学习微调、生成器用 DPO 人类偏好对齐,没披露几个会决定结论强度的关键信息:生成模型是哪一个,context window 多大,top-k 设多少,faithfulness 怎么标,missing-document 场景是自然出现还是人工构造,pairwise preference 的标注协议是什么。没有这些,很难判断“检索变强却答得更差”究竟是 RAG 的结构性问题,还是这套生成器对证据不足的校准本来就差。标题给出了方向,正文没给足复现条件,我不会把它读成“检索优化没用”,我会读成“单独优化检索没法担保可靠性”。这两个判断差很多。 我还想补一个文章外的上下文。过去一年不少团队开始加 answerability detection、abstention heads、citation verification,甚至先做 corpus sufficiency check,再决定答不答。这个路线比单纯换更强 embedding 更务实。Anthropic、OpenAI 这类系统在高风险场景里也越来越强调 refusal 和 uncertainty calibration,原因就在这里:错答不可怕,自信错答才麻烦。政策 QA 尤其如此,因为用户通常不会逐条核引文。 所以这篇 paper 对从业者的启发很直接。第一,别再拿检索指标当上线理由,至少要把“库里没答案”设成单独测试集。第二,生成器的奖励函数别只偏好流畅和完整,还要奖励保留、限定和拒答。第三,产品层要把证据覆盖暴露出来,比如明确显示“仅基于 3 份命中文档,未检索到司法辖区 X 的材料”。如果这些机制没有,政策 RAG 做得越顺,风险越大。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
17:16
32d ago
● P1arXiv · cs.CL· atomEN17:16 · 03·25
Steering Vectors 的安全陷阱分析
论文用 JailbreakBench 审计 CAA steering vectors,发现它们会显著改变越狱攻击成功率,最高升高57%,最高降低50%。效应在模板化攻击上更强,作者把原因指向 steering vectors 与拒答行为潜在方向的重叠。真正值得盯的是控制性与安全性存在直接拉扯,不是单纯的提示调参问题。
#Safety#Alignment#Interpretability#Research release
精选理由
JailbreakBench 审计显示,CAA steering vectors 会把越狱成功率最高拉高 57%,也能压低 50%。HKR-H/K/R 都成立,但题目仍属偏研究的安全机制分析,不是大范围产品或模型发布,分数放在 80,tier 给 featured。
编辑点评
论文测到 CAA steering vectors 会把越狱成功率拉到 +57% 或压到 -50%。这不是小瑕疵,它说明很多“可控性”技巧在安全面前还像半盲操作。
深度解读
作者用 JailbreakBench 测到 CAA steering vectors 会把越狱成功率推高 57% 或拉低 50%。我对这条的判断很直接:activation steering 这类方法离“可部署控制层”还差一大截,因为它改的不是表层语气,而是和拒答行为共享的潜在方向。 这点其实不奇怪。2024 年到 2025 年,圈里已经反复见过 activation addition、representation engineering、system prompt editing 这几路方法有个共性:便宜、快、像旋钮,但边界条件很差。你给模型加一条向量,常常会同时动到别的能力轴。论文这次把问题钉在 refusal direction overlap 上,价值在于它不是只说“会坏”,而是给了一个机制解释。对做安全的人,这比单纯再跑一组 ASR 更有用,因为你终于知道为什么一些“更服从指令”的 steering 会顺手把防线拆掉。 我对摘要里的一个点比较买账:模板化攻击放大更明显。这很像我们在越狱评测里老碰到的现象——模型的拒答往往依赖一小撮稳定格式信号,所以一旦 steering 吃到了那条表示方向,攻击者用固定模板反而更容易稳定复现。换句话说,这不是随机脆弱性,而是可编排脆弱性。做 agent 或 inference middleware 的团队要小心了:你以为自己只是在加一个“更有帮助”“更直接输出”的 steering,结果可能是在量产一个更听话也更好骗的版本。 我还是有保留。正文只有摘要,没披露具体模型名单、CAA 向量构造细节、注入层位、系数范围,也没说 ASR 统计是在白盒还是黑盒设定下完成。+57% 这个数字很扎眼,但如果基线 ASR 很低,绝对增幅和部署风险要分开看。还有一个我想追问的点:降低 50% 的那组 steering,会不会顺手把正常帮助性也打穿?很多安全论文爱展示“更安全”,最后其实是“更爱拒答”。摘要没给 utility loss,这块不能替作者补。 跟更广一点的上下文放在一起看,这篇论文是在给“steering 能替代微调和对齐”这条叙事降温。Anthropic、OpenAI、Meta 过去一年在公开材料里都更强调 system card、 policy stack、 tool gating、 constitutional 或 RM 式训练,而不是把 activation steering 当主安全方案。我一直觉得这是有原因的:训练期对齐再笨重,它至少把分布写进参数里;steering 更像推理期外挂,调起来快,漏起来也快。 所以这篇的价值,不在于证明 steering 有风险——大家多少都知道。它把风险从经验感受推进到表示层解释。要是后续正文能给出不同层位、不同强度、不同模型家族上的重叠测量,这条线会很硬;如果没有,那它目前还是一篇很好的警报,不是最终定论。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
17:12
32d ago
arXiv · cs.CL· atomEN17:12 · 03·25
面向可扩展阅读康复的稳健多语言文本到象形图映射
该研究构建了一个多语言 AI 界面,把文本中的关键概念自动映射为上下文相关象形图,并在英语、法语、意大利语、西班牙语和阿拉伯语5种语言上评测。专家审查显示,4种欧洲语言的“正确+可接受”评分超过95%,阿拉伯语约90%;延迟处于可交互阈值内。真正值得盯的是跨语言覆盖差异:阿拉伯语短板来自象形图库覆盖不足,不是映射机制失效。
#Multimodal#Tools#Benchmarking#Research release
精选理由
这篇文章有 HKR-K:给出了5语种评测结果,并把阿拉伯语短板定位到象形图库覆盖,不是映射机制失效。HKR-H 和 HKR-R 都偏弱,题材也更接近辅助康复研究,不是 AI 产业读者当天必须跟进的话题,所以放在 all,分数落在低中段。
编辑点评
论文在5种语言上把文本映射为象形图,并拿到4种欧洲语言超95%可接受率;这条我买账一半,工程方向对,证据密度还不够临床级。
深度解读
研究团队在英语、法语、意大利语、西班牙语、阿拉伯语5种语言上评测文本到象形图映射,4种欧洲语言“正确+可接受”超过95%,阿拉伯语约90%。我的判断很直接:这不是模型能力秀,而是一条很实用的可访问性工程线,问题也同样直接——论文摘要给了可接受率,却没给样本量、评审人数、延迟毫秒数、对照基线,离“可部署”还差一层证据。 我对这条的积极判断,主要来自它把难题放在了一个对的层级上。阅读康复里最难扩展的环节,本来就不是“再造一个更会聊天的模型”,而是把文本里该视觉化的概念稳定抽出来,再映射到能被治疗师接受的图形系统。摘要里点出阿拉伯语掉到约90%,原因是图库覆盖薄,不是映射机制失效。这个拆分很关键。很多跨语言系统一旦效果差,就把锅甩给语言本身;这篇至少在叙事上没偷懒,它承认瓶颈在资源层,不全在模型层。 这让我想到 AAC 和特殊教育里早就存在的现实:ARASAAC、Widgit 这类象形图体系,从来不是“有个模型就够了”。你得有词汇表、文化适配、词形变化处理,还得解决同一个词在不同语境下该配哪张图。我没在正文里看到他们怎么处理多义词、代词、省略、阿拉伯语词形变化,也没看到和简单词典匹配或机器翻译再检索的基线对比。没有这些,你很难判断那95%到底来自映射管线本身,还是任务被设计得偏友好。 我还有个保留意见:专家审查能说明“看上去是否能用”,不能直接说明“是否提升理解”。SEND 场景里,语义正确和教学有效不是一回事。一个 pictogram 选得没错,不代表学生读得更快、记得更牢,或者减少了一对一支持时间。过去一年教育和医疗辅助 AI 最常见的叙事毛病,就是把 clinician-in-the-loop 的可接受性,当成最终结果指标。这里也有这个风险。摘要只说 speech therapists 和 special education professionals 审过,没披露受试者规模、任务完成率、理解提升幅度,也没说长期使用会不会出现视觉噪声过载。 说真的,我反而觉得阿拉伯语这 90% 最有价值。它暴露的不是“多语言做不到”,而是“资源不对称会把一个看似通用的系统拉回本地化苦活”。这和过去一年多语种语音、OCR、RAG 的落地很像:英语管线先跑顺,之后卡住的常常不是模型,而是字库、标注、术语表、检索资源、评测人力。谁能把这些补齐,谁才有资格谈规模化。 所以这篇 paper 我给的结论是:方向靠谱,摘要证据偏薄,离临床或校内采购还早。标题已经给出5语种覆盖和约95%/90%的审查结果,正文摘要未披露样本量、延迟具体数值、基线方法、学习效果提升。这几项不补,论文更像一个做得不错的辅助界面原型,不是已经站稳的康复技术。
HKR 分解
hook knowledge resonance
打开信源
60
SCORE
H0·K1·R0
17:11
32d ago
arXiv · cs.CL· atomEN17:11 · 03·25
用表征学习研究教程式支架的时间动态
该论文用嵌入对齐方法分析 1,576 条 Eedi 数学辅导对话,并用余弦相似度量化导师、学生与题目及正确解的语义贴合。混合效应模型显示,角色相关的语义对齐比消息顺序和长度更能预测辅导进程;导师在早期更贴近题目内容,学生与正确解的对齐只呈温和正相关。真正值得盯的是,它把“支架”从主观教学概念改成了可复现的时序语义指标。
#Embedding#Benchmarking#Eedi#Research release
精选理由
HKR 只命中 K:论文有具体数据与方法,但标题学术味重,行业讨论度弱。更关键的是它属于教育研究与 AI 的交叉,正文未给出代理或产品层面的外溢影响,按 hard-exclusion-传统学科 crossover 处理,重要性封顶在 39 以下。
HKR 分解
hook knowledge resonance
打开信源
42
SCORE
H0·K1·R0
16:42
33d ago
arXiv · cs.CL· atomEN16:42 · 03·25
CRISP:刻画学术论文的相对影响力
CRISP 用 LLM 联合排序同一篇论文引用的全部文献,在人工标注数据集上比先前最佳分类器提升 9.5% 准确率和 8.3% F1。方法把整篇 citing paper 的引用上下文一起输入,并将随机顺序重排 3 次后做多数投票,以压低位置偏置。真正值得盯的是,它用更少的 LLM 调用完成排序,且开源模型也能跑到有竞争力的结果。
#Reasoning#Benchmarking#Tools#Research release
精选理由
HKR 里只有 K 明显命中:论文披露了可核对的提升幅度、去位置偏置机制和调用成本线索。H 与 R 都弱,原因是题材偏文献计量,不是模型、产品或代理工作流更新,对 AI 从业者的话题性有限,所以进 all 不进 featured。
编辑点评
CRISP把“单条引用分类”改成“同篇内相对排序”,这步方向是对的;9.5% 准确率提升好看,但没给数据规模和成本账,我先只记半分。
深度解读
CRISP在人工标注集上把准确率提高了9.5%,条件是它把同一篇 citing paper 的全部参考文献一起排序。这个设定我买账,因为学术影响本来就是相对量,不是把一句引用上下文剪出来就能独立判完的绝对标签。作者顺手点中了旧方法的结构性问题:你单看一句 “following Smith et al.”,很难知道 Smith 是背景铺垫、方法来源,还是整篇工作真正的支点;放回整篇论文的引用分布里,排序才有参照系。 这条和前些年 citation intent classification 那波工作是两条路。SciCite、ACL-ARC 一类数据集,主要分背景、方法、结果比较,任务是句级分类。CRISP改成 listwise ranking,更像 learning-to-rank,不像传统分类。我一直觉得这类任务早该这么做,因为作者写 Related Work 时天然在做预算分配:核心工作会在摘要、方法、实验里反复出现,边缘工作只在一处挂名。把全文引用上下文合起来喂模型,至少机制上更接近人类判断。 我对“随机重排3次再多数投票”这招评价不错。LLM 的位置偏置不是新问题,长列表里前几项和末尾项经常吃亏。这里给了一个可复现修补:3 次随机顺序,最后投票。这个设计朴素,但比空谈“模型会综合判断”诚实。问题也在这儿:正文只说压低位置偏置,没披露偏置本身有多大,也没给 1 次、3 次、5 次重排的收益曲线。少了这组消融,你还不知道 3 次是不是经验值,还是成本和效果之间的随手折中。 作者还强调“更少的 LLM 调用”与“开源模型也有竞争力”。这两个点很关键,但目前信息缺口也最大。少多少次调用,正文没写。输入长度多大,正文没写。是把整篇 citing paper 都塞进上下文,还是只抽取含引用的段落,正文也没写。账要这么算:如果一篇论文平均 30 到 50 条参考文献,联合排序确实把 N 次独立分类压成 1 到 3 次排序;可一旦上下文长到几万 token,成本不一定更低,延迟也未必更友好。没有 token 级成本,这个“高效”只能先打问号。 开源模型能打,我是信的。过去一年不少文献任务都出现过这个走势:封闭模型在零样本上先拉开,开源模型靠指令微调和更长上下文追近。像 Qwen、Llama 系列在信息抽取、长文分类上的差距,很多时候没有宣传里那么大。CRISP 如果真的把开源模型跑到接近闭源模型,那对文献分析工具很现实,因为高校和图书馆更在乎可部署性、价格和数据出域风险。可惜摘要没给模型名、参数量、提示模板,也没给具体分差,我还没法判断“竞争力”到底是差 1 分,还是差 8 分。 我还有个保留意见:影响力标签本身很滑。人类标注的一致性如果不高,模型提升 8.3% F1 也有上限。正文只说 human-annotated,没披露标注人数、Kappa 或 Krippendorff’s alpha,也没说学科覆盖。这个问题在跨学科时更麻烦。计算机论文的“高影响引用”常落在方法复用,生医论文常落在基准发现或临床结论,判断口径不统一,模型学到的就容易是领域文风,不是影响本身。 我寻思了一下,这篇工作的价值不在“LLM 又赢了一个 benchmark”,而在它把 citation analysis 的任务定义往前推了一格:从局部句子判断,推到篇内相对重要性建模。这个方向适合做综述辅助、引文地图、审稿支持,甚至能给 literature review agent 当弱监督信号。前提也很硬:他们得补上数据规模、标注一致性、token 成本、不同模型差距这些账。不然现在这篇更像一个方向正确的原型,不是已经站稳的基础设施。
HKR 分解
hook knowledge resonance
打开信源
70
SCORE
H0·K1·R0
16:27
33d ago
arXiv · cs.CL· atomEN16:27 · 03·25
用后 Transformer 适配器校正语言模型被压制的对数概率
论文称,研究者用一个 78.6 万参数的后 Transformer 适配器,在冻结隐藏状态上训练,校正了 Qwen3-4B、8B、14B 对 31 个意识形态区分事实的对数概率压制,占基座模型约 0.02%。适配器记住了 15 个训练事实,并在 5 组随机切分里对 16 个留出事实取得 11% 到 39% 泛化,锚定训练下未见知识回归;正文还指出 Apple MLX 曾有静默梯度 bug,早期空结果由此产生。
#Alignment#Interpretability#Benchmarking#Qwen
精选理由
论文有明确新信息,HKR-K成立:78.6万参数后置适配器在31个事实上校正log-prob压制,并报告11%到39%留出泛化。它几乎完全停留在对数概率与训练设定层,触发technical-accessibility fail,对通用AI从业者缺少入口,所以排除。
HKR 分解
hook knowledge resonance
打开信源
45
SCORE
H0·K1·R0
16:14
33d ago
● P1arXiv · cs.CL· atomEN16:14 · 03·25
自蒸馏为何有时会削弱 LLM 的推理能力?
论文在 Qwen3-8B、DeepSeek-Distill-Qwen-7B 和 Olmo3-7B-Instruct 上报告,自蒸馏会缩短数学推理链,并让性能最高下降 40%。作者把退化归因于“认知性语言表达”被压制:教师若带更丰富条件信息,模型会少说不确定性,域内任务覆盖有限时优化更快,但 OOD 表现更差。真正值得盯的是,正确答案轨迹不等于稳健推理,正文摘要已给出机制与条件。
#Reasoning#Fine-tuning#Benchmarking#Qwen
精选理由
这篇 arXiv 论文抓住了一个反常识点:自蒸馏在 Qwen3-8B、DeepSeek-Distill-Qwen-7B 和 Olmo3-7B-Instruct 上会缩短数学推理链,性能最高下降 40%。HKR 三轴都成立,且有可讨论的机制与 OOD 条件;但它仍是单篇研究发布,不到必须当天全站头条的级别,所以给 81 分、featured。
编辑点评
这篇把自蒸馏的坑点说透了一半:答案能抄对,不等于推理还活着;把“不确定性”训没,OOD 往往先掉。
深度解读
论文在 3 个 7B-8B 模型上报告,自蒸馏让数学推理成绩最高下跌 40%。我对这个结论基本买账,因为它打到过去一年一个很常见的误区:大家把更短、更像样的推理轨迹,当成了更强的推理能力。 自蒸馏这套东西,过去一直吃的是“教师比学生更稳定”的红利。学生学教师输出分布,常常能把格式、答案风格、拒答边界一起学整齐。问题是,数学推理不是风格迁移。你把教师在特定题分布上的高置信度、短链路、少犹豫一并压给学生,学生学到的未必是解题程序,常常只是“别停下来检查”的行为习惯。摘要里把这个叫 epistemic verbalization suppression,也就是不确定性表达被压制。这个说法我觉得不空,至少和很多人实操时看到的现象一致:训练后输出更干净,错题却更死。 我脑子里最直接的对照,是 2025 年那波推理蒸馏热。DeepSeek-R1 系列把长推理轨迹蒸到更小模型上,社区一度默认“只要 teacher trace 对,student 就会更会想”。这篇论文等于补了一刀:trace 对,不代表内部策略稳。尤其在 OOD 数学题里,模型需要先暴露犹豫,再修正分支。你把这种犹豫从表面语言里洗掉,域内分布也许会涨,出分布就容易断。我还记得不少 process supervision 的工作也碰过类似问题:监督越像“标准答案模板”,模型越会提前收束,而不是继续搜索。细节我没逐篇核,但方向上是对得上的。 我也有一处保留。作者把退化归因到“认知性语言表达”被压制,这个机制听着顺,但摘要还不够让我完全接受因果。因为“不确定性表达减少”有两个解释。一个是模型真的失去校准和自我修正。另一个更朴素:它只是学会了更短的表述习惯,而长度缩短本身就和错误上升纠缠在一起。要把这两件事拆开,最好看干预实验:比如固定答案正确率,单独操纵 uncertainty token;或者在隐藏状态层面测校准变化。摘要只说了 controlled experiments varying conditioning context richness and task coverage,但没给 benchmark 名称、样本量、蒸馏配方、长度控制方式。这些正文未披露,我没法替它补。 还有一点,我不太想让人把这篇读成“别做自蒸馏”。这就读偏了。它给出的条件非常关键:teacher conditioning 更丰富、任务覆盖有限、目标又偏域内优化时,退化更明显。这个条件组合很像很多团队的现实流程:拿一批高质量解题轨迹,覆盖不大,快速做 SFT 或 rejection sampling,再用短响应当成效率收益。论文说的其实是,这种 recipe 会把模型往“少说、快答、别暴露迟疑”那边推。你要是训练目标本来就是客服、摘要、格式化抽取,这种收缩未必是坏事。你要的是数学、代码、复杂 agent 规划,它就危险了。 我觉得这篇对今天的一个主流叙事是有冲击的:大家太爱把“response shorter”当成系统优化收益。短当然省 token,latency 也好看,但短链路和强推理没有天然同向关系。OpenAI、Anthropic 过去一年都在把公开 CoT 收起来,产品上越来越少展示完整推理。那是安全、产品体验、成本的综合权衡,不是证明“少说就更会想”。开源圈如果顺手把这个产品趋势读成训练原则,就容易把外显不确定性一并删掉。 我还想补一个更实际的判断。摘要里说 rich teacher information 会加速域内优化,这很像数据放大了 shortcut learning。教师知道得越多,学生越容易学到“这类题通常长这样,所以直接走这条路”。任务覆盖一窄,这条捷径在训练集附近很好用。分布一偏,模型缺少回退机制。人做题时会写“先试一下”“这个条件不够”“换个思路”。很多团队嫌这些词啰嗦,会在清洗数据时删掉。我一直觉得这步删得太狠。你删掉的不是礼貌废话,常常是 search process 的表面痕迹。 如果只看这段摘要,我给这篇的定位是:它不是把“为什么推理退化”彻底讲完了,但它至少把一个被忽视的训练副作用钉住了。后面我更想看两类补充。第一,40% 下跌具体出现在哪些 benchmark,GSM8K、MATH、AIME 风格,还是更硬的 OOD 组合题,正文没披露。第二,若保留部分 uncertainty expression,代价是多少:token 增长 10%,还是 2 倍?这直接决定它是研究结论,还是能进训练配方的工程结论。现在这两点都还缺。
HKR 分解
hook knowledge resonance
打开信源
87
SCORE
H1·K1·R1
16:13
33d ago
arXiv · cs.CL· atomEN16:13 · 03·25
不靠数字计数,不靠词语寻找
该论文提出首个多模态宠物重聚系统,结合视觉与声学生物特征做匹配。摘要称系统可处理10Hz大象低鸣到4kHz幼犬叫声,并用概率视觉匹配容忍应激后的外观变化。真正值得盯的是跨物种声纹设计;正文未披露数据集规模、基准结果与误差率。
#Multimodal#Audio#Vision#Research release
精选理由
题目有新鲜感,但这是偏动物识别的应用研究,离 AI 行业主线太远,按硬排除规则4处理。摘要只确认多模态机制、10Hz到4kHz覆盖范围和概率视觉匹配;数据集规模、基准结果、误差率都未披露。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H1·K0·R0
16:12
33d ago
arXiv · cs.CL· atomEN16:12 · 03·25
Mechanic:由 sorry 驱动的自动定理证明形式化分解工作流
Mechanic 提出基于 Lean 的 sorry 占位符分解失败证明,并在 IMO 2025、Putnam 2025 基准上报告更高证明效率。它保留已验证证明结构,把未解子目标抽成独立上下文分别求解,避免整段重写或在长上下文里反复修补;正文未披露具体通过率与样本规模。
#Agent#Reasoning#Benchmarking#Lean
精选理由
论文给出可检验机制:保留 Lean 已验证证明结构,把 sorry 占位拆成独立子目标分别求解,并声称在 IMO 2025、Putnam 2025 更高效;正文未披露通过率与样本规模。题材高度依赖形式化证明背景,触发 technical-accessibility fail,重要性封顶 39。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H0·K1·R0
15:41
33d ago
arXiv · cs.CL· atomEN15:41 · 03·25
大规模说话人验证的学什么、何时学:CURriculum Ranking Loss
论文提出 Curry 损失,在大规模说话人验证中按样本难度分层训练,并在 VoxCeleb1-O 与 SITW 上把 EER 较 Sub-center ArcFace 基线分别降 86.8% 和 60.0%。该方法用主导子中心余弦相似度生成置信分数,再结合运行中的 batch 统计把样本分成 easy、medium、hard 三层,且不需额外标注。真正值得盯的是在线课程排序机制,不是“最大规模训练”这句口号;正文片段未披露训练数据规模与绝对 EER。
#Audio#Benchmarking#Research release#Benchmark
精选理由
这篇有 HKR-K:给出了 CURriculum Ranking Loss 的具体分层机制和两组相对 EER 结果。问题在于它触发 technical-accessibility fail:任务与指标都偏说话人验证细分领域,正文也未披露训练规模与绝对 EER,对通用 AI 从业者的可迁移价值有限,所以排除并压到 40 分以下。
HKR 分解
hook knowledge resonance
打开信源
44
SCORE
H0·K1·R0
15:33
33d ago
● P1arXiv · cs.CL· atomEN15:33 · 03·25
OneSearch-V2:加入潜在推理增强自蒸馏的生成式搜索框架
论文提出 OneSearch-V2 生成式搜索框架,并在在线 A/B 测试中把商品 CTR 提升 3.98%、买家转化率提升 3.05%、订单量提升 2.11%。方法包含三部分:思维增强的复杂查询理解、内化推理的自蒸馏训练、行为偏好对齐优化;手动评测还给出 page good rate +1.65% 与 query-item relevance +1.37%。真正值得盯的是,它声称缓解信息茧房和长尾稀疏,且不增加推理成本或服务时延。
#Reasoning#Alignment#Benchmarking#OneSearch
精选理由
这是一篇少见带真实在线 A/B 指标的生成式搜索论文:CTR +3.98%、转化 +3.05%、订单 +2.11%,还给出“无额外推理成本或时延”的可检验主张,HKR 三轴都成立。分数停在 82,因为来源仍是 arXiv 单篇论文,正文未披露更细部署条件与外部复现。
编辑点评
OneSearch-V2 在在线 A/B 中把订单量拉高 2.11%。如果实验口径站得住,这不是论文分数,是电商搜索团队会直接排期上线的增量。
深度解读
OneSearch-V2 报告了在线 A/B 的 3.98% CTR、3.05% 买家转化率、2.11% 订单量提升,且声称没有新增推理成本或服务时延。我对这条的第一判断是:这篇论文的价值不在“latent reasoning”这个名字,在它把复杂推理留在训练侧,把线上系统继续做成便宜的生成式检索。这个思路我买账,因为电商搜索里延迟预算通常按几十毫秒算,线上每多一层 rerank、每多一次 tool call,收益很快会被 QPS 和成本吃掉。要是他们真做到“训练时用老师推理,部署时学生直出”,这比再塞一个大模型重排器务实得多。 我一直觉得,生成式检索过去一年卡住的点不是能不能生成,而是能不能稳稳地吃到复杂 query、长尾意图、历史偏好过拟合这三件事。很多团队离线指标很好看,上线后 GMV 和订单没动,原因就是模型学会了贴日志,没学会补全用户没说出口但愿意买的东西。这篇里“reasoning-internalized self-distillation”和“behavior preference alignment”就是冲这个去的。外部参照也很清楚:推荐和搜索系统里,线上 0.5% 左右的转化提升通常已经够团队写战报了;这里订单量给到 2.11%,幅度不小。所以我更关心实验设计,而不是术语包装。 我的保留也很直接。正文只有 RSS 摘要,没披露 A/B 流量规模、实验时长、统计显著性、基线 OneSearch 的版本、延迟统计口径,也没给“信息茧房缓解”和“长尾稀疏改善”的可复现定义。没有这些,2.11% order lift 当然很亮眼,但还不能直接当成通用方法论。还有一个地方我会多看一眼:所谓“不增加推理成本”,是指线上模型参数量不变、token 不变,还是把额外计算转移到候选构建和索引侧?这两个差很多。摘要没说,我不想替作者补。 说真的,这篇最像样的地方,是它终于把“推理”从 demo 能力往商业指标上压了一步。生成式搜索这条线以前太爱讲理解力,少讲订单和转化;OneSearch-V2 至少给了业务数。问题也就卡在这里:如果后续正文和附录拿不出实验设置、消融、延迟拆分,那这更像一次精心包装的工业 case,而不是别人能复现的框架。
HKR 分解
hook knowledge resonance
打开信源
88
SCORE
H1·K1·R1
15:27
33d ago
arXiv · cs.CL· atomEN15:27 · 03·25
PINGALA:面向梵语诗歌生成的韵律感知解码
论文提出 PINGALA 解码法,用分组行生成替代整段生成,把梵语诗歌的语义连贯性提高 10%,同时保持相近的格律符合度。方法在选词时偏向更长 token,促使每行形成完整词;对 Phi-4 这类指令微调模型,采用语音感知转写 SLP1 后,格律对齐再提高 46%,语义相似度相近。作者还加入无参考评测,用 cross-encoder 判断生成诗与真实诗的一致性;真正值得盯的是,解码与转写表征本身就在改写诗体约束。
#Fine-tuning#Benchmarking#Tools#Phi-4
精选理由
HKR-K 成立:论文给出两项可核对结果,分组行生成把语义连贯性提高10%,SLP1 转写把格律对齐提高46%。但任务高度依赖梵语诗律背景,行业读者缺少进入点,和产品落地距离远,触发硬排除“技术可达性失败”,重要性封顶 39。
HKR 分解
hook knowledge resonance
打开信源
41
SCORE
H0·K1·R0
15:02
33d ago
MIT 科技评论· rssEN15:02 · 03·25
这家电池公司为何转向 AI
SES AI 把业务重心转向 AI 电池材料发现平台,并称平台已识别 6 种新电解液材料。公司仍做无人机等小市场电池,不再押注电动车大规模制造;正文给出的机制是用历史测试数据和领域知识筛材料,其中 1 种添加剂被称可替代 FEC 且不放气。真正值得盯的是,SES 想卖软件授权和材料,而不是继续硬扛西方动力电池产能战。
#Tools#SES AI#Qichao Hu#MIT
精选理由
这篇有新意,也有细节:SES AI 不再押注电动车量产,正文给出“识别 6 种材料”和“FEC 替代添加剂不放气”两条具体信息。问题在于它属于“传统科学 + AI 工具化”选题,缺少 agent、模型产品或行业竞争外溢,触发硬排除规则 4。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H1·K1·R0
14:53
33d ago
arXiv · cs.CL· atomEN14:53 · 03·25
通过循环一致性微调提升 Lean4 自动形式化
作者用 LoRA 微调 Qwen3.5-2B 做自然语言到 Lean4 形式化,在 FineLeanCorpus 与 PutnamBench 上,带循环一致性奖励的 GRPO 把平均循环一致性从 0.513 提到 0.669、从 0.422 提到 0.561。该奖励用“自然语言→Lean4→自然语言”闭环后的句向量余弦相似度计算;交叉熵只增加 0.011 nats,形式化质量影响很小。真正值得盯的是,课程学习按难度 1 到 10 排序没有测出收益。
#Fine-tuning#Reasoning#Benchmarking#Qwen
精选理由
研究有料:LoRA 微调 Qwen3.5-2B,用“自然语言→Lean4→自然语言”闭环余弦相似度做奖励,循环一致性明显上升,课程学习未测出收益。问题是 Lean4 自动形式化门槛高、迁移面窄,触发 technical-accessibility fail,只能 excluded。
HKR 分解
hook knowledge resonance
打开信源
42
SCORE
H0·K1·R0
13:59
33d ago
MIT 科技评论· rssEN13:59 · 03·25
这家初创公司想改变数学家做数学的方式
Axiom Math 发布免费开源工具 Axplorer,把 2024 年在 Meta 超算上运行的 PatternBoost 改到单机可用;团队称它在一台 Mac Pro 上 2.5 小时复现了 Turán four-cycles 问题结果。正文给出的机制是交互式模式搜索:用户先给样例、筛选有趣候选、再迭代生成;真正值得盯的是它把原先需数千台机器、连续跑 3 周的流程压到个人电脑,但外部学者直说改进幅度仍待验证。
#Tools#Reasoning#Benchmarking#Axiom Math
精选理由
标题有反差,正文也给了 Mac Pro 2.5 小时复现 Turán four-cycles 的机制与条件,HKR-H/K 成立。它仍是数学研究工作流的 AI 工具,离通用 agent、模型发布或产业竞争较远,触发 hard-exclusion-4,故列为 excluded。
HKR 分解
hook knowledge resonance
打开信源
44
SCORE
H1·K1·R0
13:48
33d ago
arXiv · cs.CL· atomEN13:48 · 03·25
Samasāmayik:一个印地语-梵语机器翻译并行数据集
作者发布 Samasāmayik 印地语-梵语并行语料,包含 92,196 个句对,覆盖口语教程、儿童杂志、电台对话和说明材料。论文用 ByT5、NLLB 和 IndicTrans-v2 做微调基准,称域内测试显著提升,其他常用测试集表现相当;具体分数正文未披露。真正值得盯的是,它主打当代语料且与现有语料语义、词汇重叠很低。
#Benchmarking#Fine-tuning#ByT5#NLLB
精选理由
这篇稿子的核心价值在 HKR-K:它给出 92,196 个印地语-梵语句对,并强调当代语料与既有语料的语义、词汇重叠低。HKR-H 与 R 都弱,因为它是窄众机器翻译数据集论文,对主流模型产品、部署成本和竞争格局没有直接牵引。
编辑点评
作者放出 9.2 万条印地语-梵语句对,这比论文里那点微调分数更重要:他们在给梵语 MT 换数据时代。
深度解读
作者这次把 92,196 条当代印地语-梵语句对放出来,价值先大过模型分数,因为梵语机器翻译长期卡在“有文本、没当代文本”。现有很多梵语资源偏古典文献、宗教文本、诗歌,训练出来的系统常见问题不是 BLEU 低 2 分,而是语域直接错位:你拿它翻教程、广播对话、儿童读物,它会往书面化、古典化跑。Samasāmayik 至少在数据侧正面补了这个洞。 我比较买账的是它强调“低语义和词汇重叠”。低资源语种里,很多“新数据集”其实只是旧平行语料换个切分,benchmark 看着进步,泛化没变。这里标题和摘要都说重叠低,这个信号是对的。不过正文只有 RSS 摘要,关键方法没给:重叠怎么测,用 embedding 还是 n-gram,跟哪些已有语料比,阈值设多少,正文片段都没披露。没有这些细节,我不会急着把“novelty”当成已验证事实。 模型选择也有点意思。ByT5、NLLB、IndicTrans-v2 这组覆盖了字节级、多语大模型、印度语系专门模型,算是一个合理的最小基线。我印象里 IndicTrans-v2 这类模型在印度语言对上通常比通用多语模型更稳,尤其在脚本、形态变化、专名处理上更占便宜;ByT5 的好处是对稀有词和拼写变体更耐受。要是这套数据真能让三类模型都在域内明显上涨,那说明增益大概率来自语料分布,而不只是某个架构碰巧吃到了红利。 但我对“其他常用测试集表现相当”还是有保留。相当是多少?差 0.3 BLEU 还是差 3 BLEU?看 chrF、COMET 还是人工评测?摘要没给。低资源翻译里,这种表述经常掩盖一个现实:域内提升很大,跨域退化被平均数抹平。还有一个更硬的问题,92k 句对对英语系不算大,对梵语已经不小,但离“稳健覆盖当代表达”也没到很宽。儿童杂志、广播、教程、说明材料这四类来源,语域比古典文本现代得多,可社会媒体、政府服务、问答式口语、代码混写印地语都还没看到。 说真的,这条我更愿意把它看成数据地基,不是模型结论。过去一年印度语系方向最清楚的一件事,就是很多提升先来自数据清洗、对齐、去重、域匹配,不来自再堆一个更大的 decoder。我没核实 Hindi-Sanskrit 现有公开平行语料的准确排名,但 9.2 万条且强调当代覆盖,这个量级已经足够让后续团队去做 continued pretraining、adapter、synthetic back-translation,甚至做术语一致性评测。要是作者后面补出精确分数、去重方法、许可协议和数据采样规则,这套语料会比这篇 paper 本身更耐用。现在先别急着吹“新 SOTA”;先看数据卡写得有多实。
HKR 分解
hook knowledge resonance
打开信源
63
SCORE
H0·K1·R0
13:38
33d ago
arXiv · cs.CL· atomEN13:38 · 03·25
SpinGQE:面向自旋哈密顿量的生成式量子本征求解器
论文提出 SpinGQE,把自旋哈密顿量的电路设计改写为生成建模任务,并在四量子比特 Heisenberg 模型上收敛到近基态。方法用 transformer 解码器学习低能量电路分布,训练信号是各门子序列能量与模型 logits 的加权均方误差;实验称 12 层、8 头、12 门序列更稳,真正值得盯的是它不依赖问题特定对称性。
#Mindbeam-AI#Research release#Open source
精选理由
HKR-K 成立,因为正文给了具体机制与实验条件。它同时命中 hard-exclusion-传统科学与 AI 交叉、technical-accessibility fail:主题是自旋哈密顿量与量子电路搜索,对 AI 从业者没有明确产品或代理外溢,所以排除。
HKR 分解
hook knowledge resonance
打开信源
40
SCORE
H0·K1·R0
12:52
33d ago
arXiv · cs.CL· atomEN12:52 · 03·25
通过感知规范化的多任务学习,实现古埃及语各阶段语义对齐
这篇 arXiv 论文用一个紧凑型编码器-解码器模型,对古埃及语4个历史阶段做词级语义对齐,并联合训练 MLM、TLM、序列到序列翻译和词性标注。实验用 ROC-AUC 与 triplet accuracy 评估埃及语-英语及埃及语内部同源词数据;正文给出结论是翻译带来最大增益,加入 IPA 与 KL 一致性能改善跨分支对齐,早期融合效果有限。
#Embedding#Benchmarking#Fine-tuning#Research release
精选理由
摘要有具体方法与结论,HKR-K 成立:4任务联合训练,翻译带来最大增益,IPA 与 KL 一致性能提升跨分支对齐。问题在于题材过窄,落点是历史语言学研究,没有 agent、产品或工作流外溢价值,触发技术可达性硬排除,分数封顶在 39 以下。
HKR 分解
hook knowledge resonance
打开信源
41
SCORE
H0·K1·R0
12:35
33d ago
arXiv · cs.CL· atomEN12:35 · 03·25
用于跨文档软件共指消解的语义质心与分层密度聚类
该论文在 SOMD 2026 软件跨文档共指任务中,用 Sentence-BERT、FAISS 检索和 HDBSCAN 聚类取得 0.98、0.98、0.96 的 CoNLL F1。方法先做表层归一化和缩写消解,再用训练集簇质心构建 KB 进行匹配;未能高置信归类的提及交给 HDBSCAN。真正值得盯的是 Subtask 3 用实体类型与规范化表层形式做 blocking,把同一管线扩到大规模场景。
#Embedding#Benchmarking#Tools#FAISS
精选理由
有具体分数和方法细节,HKR-K 成立;但题材过于细分,面向软件共指评测读者,不是通用 AI 从业者的日常关注点。触发 hard-exclusion-technical-accessibility fail,重要性封顶 39,归为 excluded。
HKR 分解
hook knowledge resonance
打开信源
42
SCORE
H0·K1·R0
12:29
33d ago
arXiv · cs.CL· atomEN12:29 · 03·25
通过联邦学习优化多语种 LLM:客户端语言组成研究
该研究扩展 FederatedScope-LLM 做多语种指令微调实验,并提出 LDES-FL 机制,让客户端按本地验证表现暂停或恢复训练。结果显示,在联邦学习里,提高单个客户端内部的多语种混合度,会得到更强且更公平的全局模型;单语本地微调仍最适合单语言专精。摘要未披露具体模型规模、语种数量和绝对指标,真正值得盯的是“客户端语言组成”被证明是性能、公平性和训练成本的关键变量。
#Fine-tuning#Benchmarking#Research release
精选理由
HKR 只命中 K。摘要给出 LDES-FL 的停训/复训机制,并报告客户端内多语混合提升全局性能与公平性;但摘要未披露模型规模、语种数量和绝对指标,议题也偏联邦多语微调研究,所以进 all,不到 featured。
编辑点评
这篇把“客户端怎么混语种”抬成主变量,我买账一半:方向对,证据还不够硬,摘要把模型规模和绝对分数都藏了。
深度解读
这篇论文把客户端语言组成定义成联邦多语微调的关键变量,但摘要没有披露模型规模、语种数量、绝对指标和通信轮次,所以结论现在只能先看方向,不能直接看成可落地配方。 我对这个判断本身并不意外。联邦学习里最麻烦的,从来不是“有没有更多数据”,而是每个 client 梯度在不在同一个几何空间里。单语 client 往往把更新拉向本地语言分布,聚合后就容易互相抵消,低资源语言通常最吃亏。把多种语言先在单个 client 内部混起来,等于先做一次局部对齐,再把更新送进全局聚合,这个机制上说得通。摘要说这样会得到更强、也更公平的全局模型,我基本信这个方向。 有意思的是,它顺手也承认了另一面:单语本地微调对单语言专精还是最好。这点很关键,因为它直接戳破了一个常见幻想——很多人把 multilingual FL 讲成“既保隐私又保通用还保专精”的三赢方案。没那么整齐。你想要一个平衡的全球模型,就得接受局部最优被牺牲;你想要单语言最强,本地单语调优还是更直接。这个 trade-off 才是系统设计里的硬约束。 LDES-FL 这个暂停/恢复本地训练的机制,我觉得是文中另一个像样的点。联邦训练里 client 质量不齐,固定 local epoch 经常浪费算力,还会把过拟合 client 的噪声放大。用本地验证集做动态 early stopping,逻辑上接近给每个 client 单独设步长阀门。这个思路不新,传统 FL 里已经有按 client 重要性、漂移程度、或 loss 变化做调度的工作;但把它放进多语 instruction tuning,至少是实用的。我没查原文,不知道它是按 round、step 还是 patience 触发,也不知道恢复训练会不会带来额外状态管理成本,摘要没说。 我想补一个文章外的背景。过去一年,多语训练的主流经验其实很一致:不管是集中式 pretraining,还是 instruction tuning,语言混合比例、采样温度、低资源语言过采样,往往比“再多堆一点总数据量”更决定尾部语言效果。NLLB、mT5、BLOOM 这一路都反复证明过,数据怎么混,常常比模型口号更重要。这篇把类似结论搬到 FL 场景,不算颠覆,更像是在补一块一直缺的工程理论:联邦端的异质性,不只是设备差异,也是语言混合策略差异。 但我对摘要里的“更公平”有点警觉。公平到底按什么算?是平均语言分数更接近,还是最差语言抬升,还是高资源语言回撤变小?如果只是 macro average 变好,那不等于部署层面的公平。还有训练成本,摘要只说需要更多 optimization steps,却没给通信轮次、每轮本地步数、总 token、能耗,连 central multilingual fine-tuning 的差距有多大都没写。联邦学习论文经常在这里把账算得太轻:少传原始数据,不代表总成本低。 所以我的看法是,这篇最有价值的地方,不是它又证明了 multilingual 有用,而是它提醒做 FL 系统的人,client 划分本身就是训练超参数。以前很多人把 client 当自然给定的组织边界;这篇在说,语言构成如果可以重组、缓存或路由,那就是你能主动设计的一层。如果原文后面给出了清楚的模型规模、语种覆盖、绝对分数和通信成本,这条会很有参考性。现在只有摘要,我还不会把它升格成生产结论。
HKR 分解
hook knowledge resonance
打开信源
70
SCORE
H0·K1·R0
11:50
33d ago
arXiv · cs.CL· atomEN11:50 · 03·25
变化才是常态:在 NLP 中接纳社会语言学
论文提出一个把社会语言学与 NLP 研究结合的框架,并用卢森堡语案例说明正字法变体会显著拉低模型表现。RSS 摘要确认作者比较了含大量变体数据与接近标准拼写数据的效果,还测试了把变体纳入微调;具体模型名、指标和降幅正文未披露。真正值得盯的是,变体不是脏数据,现有模型对真实语言变体仍不稳健。
#Fine-tuning#Benchmarking#Research release
精选理由
论文给出一个明确且可检验的点:正字法变体会拉低模型表现,还测试了把变体纳入微调。分数放在 60 段,因为摘要没披露模型名、指标和降幅,卢森堡语个案的行业共鸣也偏弱。
编辑点评
这篇论文用卢森堡语证明了一个老问题还没被解决:模型一碰到真实拼写变体就掉链子,把变体先清洗掉只是把部署风险藏进数据管线。
深度解读
论文用卢森堡语案例比较了高变体数据、近标准拼写数据与含变体微调条件。正文未披露模型名、指标和具体降幅。就这点信息,我的判断很直接:这不是“小语种特例”,这是 NLP 体系长期把书面标准语当默认接口的后果。 很多团队把 spelling normalization 当成卫生步骤。训练前清洗一遍,评测前再对齐一遍,分数就好看了。问题是线上用户不会按 annotation guideline 说话。社媒、客服、语音转写、方言输入法、移民社群文本,都会把“正字法一致”这件事直接打碎。你在 benchmark 上拿到 90 分,不代表你在生产里见到变体时还能保住 90 分。这个坑其实早就出现过:African-American English、Singlish、阿拉伯语方言、瑞士德语,过去几年都反复证明过,标准语训练出来的模型会把变体当异常值,最后掉在分类、公平性和 ASR/WER 上。我记得几篇工作里误差差距能到两位数百分点,但这篇 RSS 没给对照文献,我就不替它补数字了。 我比较认同作者把“变体不是噪声”说死一点。因为工程上很多失真就发生在这里:你把变体统一,确实能降低词表稀疏和标注成本;你也顺手删掉了社会身份、地区传播、代际变化这些信号。对做 safety、moderation、sentiment、search 的团队,这不是学术洁癖,这是召回和误杀问题。一个最常见的坏结果是:模型在主流标准语上显得稳,在边缘用户群体上系统性失真,但 dashboard 看不出来,因为 preprocessing 先把差异抹平了。 我对这篇论文也有保留。现在只有摘要,没看到任务类型、样本量、变体标注方式,也没看到“纳入变体微调”到底是数据增强、分层采样,还是显式 sociolinguistic conditioning。没有这些信息,你很难判断它给的是通用方法,还是只对卢森堡语这个低资源、正字法仍在收敛的场景有效。还有一个常见问题:把变体加回训练集,短期常常能提平均分;跨群体校准、长尾覆盖、推理成本会不会变差,摘要没说。 我自己的结论是,很多 NLP 评测集接下来得补一列 metadata:变体密度、地区、社群、时间层。没有这列,你测到的只是“标准语条件下的能力”。这篇文章的价值,不在于它告诉我们语言有变化,而在于它提醒从业者:你现在的高分,有一部分是数据清洁工替你挣来的。
HKR 分解
hook knowledge resonance
打开信源
69
SCORE
H0·K1·R0
11:48
33d ago
MIT 科技评论· rssEN11:48 · 03·25
Agentic 商业依赖真实数据与上下文
Reltio 认为,Agentic 商业要在毫秒级交易前完成发现、比价、决策与授权,前提是把代理、用户、商户三方身份和权限做成可验证上下文。正文给出的具体抓手是主数据管理、实体解析、令牌化与可验证意图,并建议企业在未来 12 到 24 个月内先治理收款方、供应商和公私身份边界。别被标题骗了,核心不在模型推理,而在能否用确定性数据替代“差不多”的记录。
#Agent#Safety#Reltio#Mastercard
精选理由
文章把重点放在数据治理与权限边界,这一判断对 agentic commerce 有一些信息量,但正文未给案例、指标或外部验证。更像供应商观点稿,触发 hard-exclusion-zero-sourcing,重要性封顶 39。
HKR 分解
hook knowledge resonance
打开信源
41
SCORE
H0·K1·R0
11:00
33d ago
NVIDIA 博客· rssEN11:00 · 03·25
“释放蒸汽”:电力可调节的 AI 工厂如何稳定全球能源电网
NVIDIA 博客文章讨论了“电力可调节的 AI 工厂”如何帮助稳定全球能源电网。原文仅提供标题,能确认的具体信息只有主题聚焦于 AI 设施与电网稳定性的关系,未给出数字、机制或实验条件。对 AI 从业者而言,这表明数据中心用电灵活性正在被放到能源基础设施语境中讨论。
#NVIDIA#Commentary
精选理由
标题角度有新意,也碰到数据中心电力瓶颈这个真问题;K 失手,因为正文只确认主题,功率调节机制、规模数字和案例都未披露。命中硬排除“零来源内容”,分数封顶 39,tier 设为 excluded。
HKR 分解
hook knowledge resonance
打开信源
40
SCORE
H1·K0·R1
10:27
33d ago
arXiv · cs.CL· atomEN10:27 · 03·25
生成高质量荷兰语医疗对话合成数据
该论文提出一条流程,用荷兰语微调 LLM 生成荷兰语医疗对话,并以真实医患对话作语言与结构参照。定量评估显示词汇多样性较强,但轮次切换过于规整;定性评审给出略低于平均分,正文未披露具体分数。真正值得盯的是,数值指标与人工评价相关性有限,单看自动指标会高估对话自然度。
#Benchmarking#Fine-tuning#Research release
精选理由
这篇稿子主要命中 HKR-K:它给出一个可复核的结论,自动指标会高估合成对话自然度,正文还点出轮次切换过于规整。HKR-H 和 R 都弱,题材过窄,和主流模型、产品更新或 agent 落地没有直接外溢,所以给 all 而不是 featured。
编辑点评
论文用荷兰语微调模型生成医疗对话,但人工评审仅略低于平均;这说明合成数据流程能跑通,离可训练临床系统还差一层临床语用校准。
深度解读
论文用一条荷兰语微调流程生成了医疗对话,自动指标显示词汇多样,人工评审却只有略低于平均。我的判断很直接:这类工作现在已经证明“能生成”,还没证明“能替代稀缺数据”。对做临床 NLP 的人来说,这差别很大,因为训练集里最贵的不是流畅句子,而是病史采集里的省略、误解、打断、纠正,还有医生根据风险动态调整问法的那些细节。摘要里唯一比较硬的信号,是轮次切换过于规整,像脚本,不像门诊。这个问题一旦进训练数据,模型学到的就会是漂亮但失真的对话节奏。 我对这篇的好感,在于它没有假装自动指标等于质量。正文明确说 quantitative 和 qualitative 相关性有限,这个结论比“词汇多样性强”更有用。过去一年合成数据论文里,很多工作还在拿 distinct-n、perplexity、embedding similarity 当主证据,但对对话任务,尤其是医疗对话,这些指标经常只会奖励表面变化,不会惩罚错误的追问顺序。比如英语医疗对话数据集上,之前就反复出现一个问题:模型能稳定生成“症状—时长—严重度”三连问,但很难自然插入澄清、安抚、回顾和条件性追问。这个我记得在若干患者模拟和 OSCE 风格生成工作里都见过,具体论文名我这会儿没核实。荷兰语是更小语种,真实语料更少,这个偏差通常只会被放大,不会自己消失。 我也有个保留意见:正文没披露人工评审的具体分数、样本规模、评审者一致性,也没说生成数据最终用于哪类下游任务。没有这些信息,现阶段很难判断“略低于平均”到底是接近可用,还是明显不可用。医疗合成数据最怕一句“feasible”把门槛说低了。要是评审者只有少量母语者和医生,或者样本很小,那个结论的稳定性就有限。要是没有下游验证,比如训练命名实体识别、摘要生成、问答或对话状态追踪后,和真实数据训练相比差多少,那这篇更像数据生成可行性展示,不是数据有效性证明。 还有一层我比较在意:他们把真实医患对话当语言和结构参照,这做法合理,但也容易把真实数据里的制度性偏差一起蒸馏进去。临床对话不是中性文本,它受科室流程、时间压力、医生个人风格、病人教育程度影响很大。你如果把结构模仿得太像,可能连某些不完整问诊模式也一起复制。你如果把结构约束得太强,又会得到这篇已经看到的问题:轮次过于整齐,像训练脚本。这个张力没有简单解法,靠“更强模型”通常也解决不了,得靠任务设计和评估设计一起改。 我一直觉得,医疗合成数据该先问两个问题。第一,能不能提升具体下游任务,而不是先问文本像不像。第二,能不能明确标注哪些现象是故意保留的临床噪声。像 Hippocratic AI、一些 patient-simulator 项目,过去一年都在强调医学安全评测和角色一致性,而不是只秀生成流畅度。这个方向更实在。回到这篇,价值不在于它把荷兰语医疗对话“做出来了”,而在于它再次提醒大家:低资源医疗场景里,自动指标很容易给团队一种虚假的完成感。正文没给下游实验结果,所以我还不会把它当成可直接扩库的方案;我会把它当成一个合格的前处理管线雏形,后面还得补临床语用评测、评审一致性、以及真实数据混训的增益曲线。
HKR 分解
hook knowledge resonance
打开信源
59
SCORE
H0·K1·R0
10:18
33d ago
arXiv · cs.CL· atomEN10:18 · 03·25
反义词与同义词词对嵌入差向量的 UMAP 投影几何:一项可视化观察
这篇 arXiv 论文报告:在某种特定投影配置下,反义词与同义词词对的嵌入差向量做 UMAP 投影时,多个嵌入模型都会出现“swirl”图形。正文只给出研究动机与现象描述,未披露样本规模、所用模型名称、UMAP 参数、评价指标或该现象能否稳定区分 antonymy 与 synonymy。真正值得盯的是可复现条件,不是标题里的几何直觉。
#Embedding#Interpretability#Research release
精选理由
题目的点击点很明确:反义词与同义词差向量在 UMAP 上出现 swirl。信息量停在现象层,正文未给出样本规模、模型名、参数和判别效果,也没有 agent 或产品含义,HKR 只中过 H,分数落在低位 all。
编辑点评
这篇 paper 现在还停在“看见了图形”这一步。没给样本、参数、指标前,我不把 swirl 当语言几何,只当降维作图事故候选。
深度解读
论文声称某种投影配置下,反义词与同义词差向量的 UMAP 图会反复出现 swirl。我的判断很直接:在没给样本规模、模型名单、邻居数、min_dist、随机种子前,这类几何叙事基本不成立。UMAP 先保局部邻域,再把高维结构压成 2D。它很擅长产出“看起来有意义”的形状,也很擅长把参数选择放大成视觉故事。 我对这条最不买账的地方,是正文把“跨多个 embedding 模型”写成结论,却没披露具体模型名。BERT 的静态 token 向量、sentence-transformer 的句向量、OpenAI text-embedding 系列、E5 或 bge 这类检索向量,几何性质差很多。差向量本身也很脆。你用词表平均、单词孤立嵌入、模板句上下文嵌入,结果都可能变。标题想谈 antonymy geometry,正文却还没把表示层说清,这个缺口不小。 说真的,这类现象我第一反应不是语言学,而是降维老问题。t-SNE 和 UMAP 过去几年反复出现“簇”“环”“带状”“螺旋”这类视觉结构,后来一查,很多是局部密度、初始化、距离度量和随机种子共同作用。UMAP 默认 n_neighbors=15、min_dist=0.1,但只要把这两个值扫一遍,图形经常明显变形。我自己没跑这篇的实验,但经验上,只给一张 2D 图、不报稳定性,证据强度接近零。 还有一个更硬的问题:差向量到底有没有分类效用。文章摘要只说看见 swirl,没说 antonym 与 synonym 能否分开,AUC、F1、silhouette score 都没有。这个顺序不能反。先有可复现分离,再谈几何解释;先有图形直觉,再回头找理论,通常很容易把投影幻觉当结构发现。NLP 里这种事不是第一次了。早年 word2vec 类比任务把“国王-男人+女人=女王”讲得太满,后来大家很快发现,很多所谓方向性关系对词频、中心化、评价集都很敏感。 我还想追问数据构造。反义词和同义词词对来自 WordNet、人工词表,还是自动挖掘?是否平衡词频、词性、多义词义项?“hot-cold”和“good-bad”这种高频、单义、语义轴明确的词,跟“sanction-permit”这类多义词,嵌入行为完全不是一回事。要是没做 sense disambiguation,差向量里混进去的先是语料偏置,再是上下文采样噪声,最后才轮到 antonymy 这件事。 我记得过去一年里,embedding 圈更扎实的做法,是直接测检索、聚类、STS、MTEB 这一类任务,不太会把 2D 可视化当主结论。可视化能启发假设,不能充当证据。要让我认真看这条,至少得补三组信息:一,模型清单和抽取层;二,UMAP 全参数、随机种子、重复次数;三,不降维的判别结果,比如在线性探针或 kNN 下,antonym/synonym 是否稳定可分。现在这些都没有。 所以我会把它当成一个研究备忘,而不是结果。要是作者后续公开代码,固定数据集,给出 5 次以上随机重跑,还能在不同模型上保住同样拓扑,那这条才开始有讨论价值。在那之前,swirl 更像图像学现象,不像语义学发现。
HKR 分解
hook knowledge resonance
打开信源
51
SCORE
H1·K0·R0
10:00
33d ago
OpenAI 博客· rssEN10:00 · 03·25
OpenAI 对 Model Spec 的方法解读
OpenAI 发布了一篇题为《Inside our approach to the Model Spec》的文章,主题是说明其对 Model Spec 的处理方法。当前提供的内容只有标题、正文为空,因此可确认的信息仅限于文章聚焦“approach”和“Model Spec”本身。
#OpenAI#Commentary
精选理由
能确认的事实只有 OpenAI 发了一篇解释 Model Spec 方法的文章,摘录只露出目录结构。没有规则变更、实例、数字或时间线,触发硬排除“零来源内容”,HKR-H/K/R 都不成立,分数压到 39 以下。
HKR 分解
hook knowledge resonance
打开信源
41
SCORE
H0·K0·R0
09:51
33d ago
arXiv · cs.CL· atomEN09:51 · 03·25
MedAidDialog:面向可及医疗的多语言多轮医疗对话数据集
论文提出 MedAidDialog,基于 MDDial 扩展出 7 种语言的多轮医疗对话,并用大语言模型生成合成问诊。作者还用量化小模型做参数高效微调,训练出 MedAidLM,可选接入年龄、性别、过敏史等预设信息;正文未披露数据集规模、基座模型名称与具体评测数字。真正值得盯的是低算力部署设定,但诊断建议能力目前只见摘要表述。
#Fine-tuning#Research release
精选理由
论文有新增事实:基于 MDDial 扩到7语种,并用量化小模型做PEFT。它仍是医疗+AI垂类研究,正文未披露规模、基座与评测数字,也没有明确产品或agent落地,触发硬排除规则4,分数封顶39。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H0·K1·R0
09:35
33d ago
● P1arXiv · cs.CL· atomEN09:35 · 03·25
对齐降低了表达层性别偏见,但未消除编码层性别偏见:统一框架与研究
论文提出一套统一协议,用同一组中性提示同时测量 LLM 内部表征中的性别信息与生成输出中的性别偏见。结果显示,两者在该协议下存在稳定关联;监督微调能降低表达层偏见,但内部性别关联仍可测到,并会在对抗式提示下被重新激活。别被“去偏”标题骗了,正文给出的关键信号是:结构化基准上的改善未必能迁移到故事生成等真实场景。
#Alignment#Safety#Benchmarking#Research release
精选理由
这篇论文的反直觉点很明确:监督微调压低了表达层性别偏见,但内部性别关联仍可测到,还会被对抗式提示拉回。HKR 三项都成立;分数停在 79,因为它是单篇研究发布,不是模型发布、产品更新或跨源大事件。
编辑点评
论文用同一组中性提示同时测内表征和外输出,结论很直白:对齐多半只是把偏见按住,不是把偏见删掉。
深度解读
论文用同一组中性提示同时测量内部性别信息和外部生成偏见,并在监督微调后仍测到可被对抗提示重新激活的关联。这个结果我基本买账,因为它戳穿了很多“去偏”工作默认偷换的口径:把输出更干净,讲成模型更中性。 我一直觉得,安全和对齐社区里有一类评测太依赖表层行为。模型在标准问答里少说错话,不等于内部表征已经改掉。你把它理解成表征层和解码层之间多了一道阀门,会更接近工程现实。RLHF 时代大家就见过类似现象:模型在公开 benchmark 上更稳,但换个提示包装、换成长上下文、换成角色扮演,原来那套倾向又冒出来。Anthropic、OpenAI 过去几版 system card 其实也都反复出现这个模式——拒答和风格约束变强,不代表潜在知识、潜在关联、潜在偏好真的消失。这个工作把“内部还在、外部先收住”用统一协议捏到一起,价值就在这里。 这篇最关键的点,不是“偏见还存在”这句老话,而是它声称在统一协议下看到了稳定相关。正文摘要明确说,过去一些工作报告过弱相关或不一致;他们换成同一组中性提示后,相关性稳定了。这个设计很重要。以前很多论文把 probing、classification、generation 分开做,prompt 分布都不一样,最后当然很难比较。现在至少把测量口径往前推了一步。说真的,这类方法论改进有时比又刷一个 debiasing 分数更值钱。 但我对这篇也有两个保留。第一,摘要没披露模型名单、参数规模、相关系数、对抗提示模板、故事生成任务的具体评价指标。标题给出了方向,正文片段没给强度。如果相关只是统计显著但效应量很小,那工程含义会完全不同。第二,“encoded gender bias”这个表述很容易被读成模型脑子里有一个稳定、可定位、可因果解释的偏见变量。probe 能测到信息,不等于这个信息就是生成偏见的唯一因。近两年 mechanistic interpretability 社区也反复提醒过,线性 probe 读得出,不代表该特征在前向过程中主导决策。我没看到全文前,不会把这个结论上升成“内部表征决定外部偏见”。 外部参照也很清楚。去年不少去偏论文都喜欢在 BBQ、StereoSet、CrowS-Pairs 这类结构化数据集上报改善,但一到开放式写作、招聘文案、人物设定生成,收益经常掉得很快。我记得这已经是老问题了,只是行业一直没彻底修评测。因为结构化 benchmark 好跑、好比、好发论文,真实任务难标注、方差又大。这个工作把 story generation 拿进来,至少是在逼大家承认:你若只在选择题里去偏,部署到内容生成产品里照样会漏。 工程上我会把这篇读成一个很现实的提醒。监督微调更像在输出层加行为约束,不像在表征层做“洗底”。如果你做的是面向用户的 assistant、创作工具、HR 或教育场景,单靠 SFT 后的 benchmark 漂亮分数不够,最好补三层检查:一是对抗提示集,专门测重新激活;二是开放生成任务,不只测结构化问答;三是持续监控,不把一次性去偏当成完成态。这个判断不花哨,但比宣传“我们已经去偏”诚实得多。
HKR 分解
hook knowledge resonance
打开信源
85
SCORE
H1·K1·R1
09:35
33d ago
● P1arXiv · cs.CL· atomEN09:35 · 03·25
对齐税:对齐后 LLM 的响应同质化及其对不确定性估计的影响
论文在 TruthfulQA 的 790 题上发现,对齐后 LLM 在 10 次独立采样中有 40%-79% 题目只落入单一语义簇,导致基于采样分歧的不确定性估计失效,AUROC 只有 0.500。作者用 base-vs-instruct 和训练阶段消融定位到 DPO:单簇率从 Base 的 0.0%-1.0%、SFT 的 1.5% 升到 DPO 的 4.0%-28.5%,且 p<10^-6。真正值得盯的是替代信号:free token entropy 在 TruthfulQA 为 0.603,在 GSM8K 为 0.724,并让 50% coverage 下准确率从 84.4% 升到 93.2%。
#Alignment#Benchmarking#Research release#Safety/alignment
精选理由
HKR 三项都过线:标题把“对齐税”落到不确定性估计失效,点击力够强;摘要也给出 TruthfulQA 790 题、10 次采样、AUROC 0.500、DPO 消融和 free token entropy 的具体数字。它不是大厂发布,但对评测、对齐和部署都很实用,属于值得推荐的 featured 研究。
编辑点评
这篇把一个常被忽略的副作用钉死了:DPO 把答案训得更像人,也把基于多次采样的置信度几乎训废了。
深度解读
论文给了一个很硬的结论:对齐后的模型在 TruthfulQA 的 790 题里,会把 40% 到 79% 的题压成单一语义簇,10 次独立采样也分不出岔,采样分歧做不确定性估计时 AUROC 直接掉到 0.500。我的判断很直接:这不是一个“小损失”,这是很多现成 guardrail 和 abstention 管线的地基在松。你如果还把 self-consistency、multi-sample disagreement、majority-vote variance 当成通用置信号,这篇基本是在说:只要后训练里 DPO 权重大一点,这套东西会在一类题上失灵,而且失灵得非常干净。 我比较买账的地方,是它没有停在“aligned models 更像”这种空话上,而是把责任往训练阶段拆。文中给的消融很清楚:Base 的单簇率是 0.0% 到 1.0%,SFT 是 1.5%,到 DPO 才抬到 4.0% 到 28.5%,而且 p<10^-6。这个量级说明问题不在“会不会礼貌一点”,而在偏好优化把输出压进了更窄的高奖赏盆地。说白点,同一个 prompt 下,模型不是更确定了,而是更会复述那条最安全、最像标答、最不惹罚的句法轨道。你看到的是稳定,机制上更像塌缩。 这和过去一年很多人的直觉其实冲突。社区里一直有人把“多采样仍然一致”当成模型更稳、更可控的证据,尤其在 agent eval、judge pipelines、RAG answer filtering 里很常见。我一直觉得这套解释有点粗。因为一致性有两种:一种是内部表征真的收敛;另一种是后训练把语言表面层压扁了。这篇的价值,在于它把第二种单独拎出来,还证明它会直接污染 uncertainty estimation。这个上下文文章里没展开,但和去年不少模型在 MT-Bench、Arena 这类偏指令跟随评测上“风格趋同、拒答模板趋同”的现象是能对上的。我没逐项核过每家 release note,不过从 Llama instruct、Qwen instruct 到一批 DPO 系列开源模型,你能明显感觉到输出自由度在下降,只是以前大家把它当成“对齐成功”的副产品,没有量化它对置信度的伤害。 我还挺在意它给出的替代信号:free token entropy 在 TruthfulQA 是 0.603,在 GSM8K 是 0.724,GSM8K 上做 selective prediction,50% coverage 时准确率从 84.4% 拉到 93.2%。这组数不算神,但方向很对。原因也不玄:如果语义层被对齐压平,去看“自由生成 token 的局部熵”比看“十次答案像不像”更接近模型当下的内在犹豫。它没被后处理后的句式同质化完全吞掉。我自己会把这理解成一个实务提醒:后训练时代,不确定性信号得尽量往 token 级、过程级、边界级走,别只盯最终答案的表面分叉。 不过我对这篇也有两个保留。第一,基准还是偏小。TruthfulQA 790 题、GSM8K 500 题、WebQuestions 的复现,足够说明现象存在,不够说明你在线上复杂任务里会损失多少。代码代理、长上下文检索、工具调用这几类任务,DPO 造成的同质化强度未必一样。第二,它把原因定位到 DPO,我基本同意方向,但“DPO”本身还太粗。关键变量可能是偏好数据的熵、chosen/rejected 的边界间隔、KL 约束强度、模板化安全回复比例。正文没披露更细的训练配方,所以现在还不能把锅全甩给所有 DPO。你要是用高多样性的 preference data,结果未必长这样。 还有一层更麻烦。很多团队现在在做 uncertainty-aware routing:低置信度就切大模型,或转人工,或加工具调用。若你的置信信号还是 sample disagreement,这篇等于提醒你:被 alignment tax 砸中的不是模型准确率本身,而是调度器的眼睛。模型错了,但十次都错得很像;系统就会把错当成稳。这比单次答错更危险,因为它会系统性低估风险。UCBD 这类 cheapest-first cascade 能省 57% 成本,相关性边界 |r|<=0.12 也挺好看,但我还没法完全买账到部署层。因为 RSS 摘要没给延迟、阈值校准方式、不同模型族上的稳定性,也没给在线分布漂移下的表现。离“拿来上生产”还有一段。 我对这篇的总体评价很高,不是因为它提出了一个新词,而是它戳到了一个大家默认成立的假设:对齐后,多次采样分歧还能当 uncertainty proxy。现在看,这个假设在一批 instruct 模型上已经不稳了。你要是还在做拒答、升级路由、agent 自检,先去测一件事:你的模型在关键任务上,10 次采样会不会已经塌到单簇;如果会,后面那套 calibration 统计大概率都得重做。
HKR 分解
hook knowledge resonance
打开信源
87
SCORE
H1·K1·R1
08:37
33d ago
● P1arXiv · cs.CL· atomEN08:37 · 03·25
LLMpedia:大规模显化 LLM 百科知识的透明框架
LLMpedia在无检索条件下从参数记忆生成约100万篇百科文章,并测得gpt-5-mini在Wikipedia覆盖主题上的可验证真实率只有74.7%。仅能用人工筛选网页证据核验的前沿主题降至63.2%;Wikipedia只覆盖61%的浮现主题,三类模型家族的选题重合率仅7.3%。真正值得盯的是,MMLU式90%+分数没有测出知识覆盖与选题偏差。
#Benchmarking#LLMpedia#Wikipedia#Grokipedia
精选理由
这篇命中 HKR 三轴:无检索生成约100万篇文章有点击钩子,74.7%/63.2%/61%/7.3%给出新测量,MMLU 高分失真直接碰到评测与模型选型。它是强研究稿,不是市场级产品事件,给 80 分、列 featured。
编辑点评
LLMpedia把 gpt-5-mini 的可验证真实率压到 74.7%,这条是在打 MMLU 那套“高分=知识扎实”的脸。
深度解读
LLMpedia 用无检索生成约 100 万篇文章,把 gpt-5-mini 在 Wikipedia 覆盖主题上的可验证真实率测到 74.7%。我对这条的判断很明确:它不是又一个“模型会幻觉”的旧结论,而是在拆穿一类已经被大家默认接受的评测幻觉——固定题库把知识能力测成了答题能力,顺手把选题偏差也一起藏掉了。 这篇东西有劲的地方,在于它把评测对象从“答一道题”换成了“连续写一篇可核验文章”。一旦任务变成成文输出,模型要自己选事实、排结构、处理时间性,还要暴露它到底记住了哪些主题。这里 74.7% 和标题里提到的 90%+ MMLU,不是几个百分点的小修正,是任务定义变了。更狠的是 frontier subjects 只剩 63.2%。这说明参数记忆一旦离开 Wikipedia 那种高覆盖、反复训练的稳态语料,真实性掉得很快。很多团队拿 closed-book benchmark 做发布会 slide,我一直觉得那套东西离真实知识工作流差一层;这篇算是把那层差距量化了。 我还挺在意另一个数字:Wikipedia 只覆盖 surfaced subjects 的 61%,三类模型家族的选题重合率只有 7.3%。这两个数放在一起看,意思很重。第一,模型脑子里的“百科边界”并不等于 Wikipedia。第二,不同模型家族记住和优先调用的主题差得离谱。同一个 prompt,OpenAI、别家闭源、开源家族,最后吐出来的世界地图不是一张图。这和过去一年很多人的经验是对得上的:你问冷门公司、区域政治人物、细分软件、二线科研概念,不同模型经常连“先想起谁”都不一样。以前这个差异只在体感层面,现在开始有了规模化证据。 我对作者的叙事也有一点保留。74.7% 很扎眼,但“verifiable true rate”到底怎么算句级、段级还是主张级,RSS 摘要没展开;capture-trap benchmark 的设计细节也没给。我还没看到误差分布:是大量小错,还是少量灾难性硬错?这两类对产品的意义完全不同。还有一个关键缺口:不同模型的 temperature、解码策略、长度控制、去重规则有没有统一。百科生成对采样很敏感,主题发现阶段尤其敏感;如果这块没锁住,7.3% overlap 里会混入不少 decoding 噪声,而不全是知识边界差异。标题和摘要给了结果,方法学上的这几处,正文之外还得自己去论文里抠。 外部参照也很清楚。过去两年从 TruthfulQA、FreshQA 到 SimpleQA,业界一直在补“考试分数不能代表事实质量”这个洞,但多数还是短答案、单跳问答。LLMpedia 往前走了一步:它开始测知识覆盖和知识选取,而不只是测答对率。我记得 Meta 做早期知识编辑和 hallucination 研究时,也反复碰到一个问题——模型不是只会答错,它会优先生成自己更熟、训练里更稠密的事实簇。LLMpedia 这组 61% 和 7.3%,其实就在把这种“记忆分布偏置”显性化。 所以这条对从业者的价值,不是多了个开源站点,也不是“1M 文章很壮观”。更直接的含义是:如果你的产品依赖模型做无检索写作、研究助手、百科解释、背景 briefing,那你不能再拿 MMLU、GPQA 这类高分给自己壮胆。模型会不会写,并不等于模型知道多少;模型知道多少,也不等于它会先把哪些东西拿出来。LLMpedia 把这三个层次拆开了,这点我买账。 我不完全买账的地方,是作者把“透明”和“可规模化”绑定成了一个优点叙事。开源 prompt、artifact、verdict 很好,但公开流程不自动等于评估公正。证据筛选如果依赖人工 curated web evidence,前沿主题那 63.2% 里会引入很强的标注口径问题。这个问题没法避免,但必须正面写清楚。要是后续社区复现还能把结论打稳,这套框架就不只是论文秀肌肉,而会变成 closed-book factuality 的新基线。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
08:27
33d ago
arXiv · cs.CL· atomEN08:27 · 03·25
ConceptKT:知识追踪中的概念级薄弱点预测基准
论文提出 ConceptKT 基准,要求模型在知识追踪中预测学生未来题目的概念级薄弱点,不再只做对错二分类。数据集同时标注每题所需概念与错误背后的缺失概念,并测试 LLM、LRM 的上下文学习;正文未披露数据规模与具体模型名单。真正值得盯的是历史记录选择机制:按概念对齐和语义相似度选样,本摘要称两项任务表现更好。
#Benchmarking#Reasoning#Research release#Benchmark
精选理由
稿子有一条新机制:知识追踪从对错预测改成概念缺陷预测,还测试了按概念对齐加语义相似度选历史记录。场景偏教育研究,正文未披露数据规模、模型名单和提升幅度,HKR 只中过 K,所以进 all,不进 featured。
编辑点评
ConceptKT 把知识追踪从对错二分类推到概念缺失诊断,这个方向对教育 AI 是加分项;但正文没给数据规模和模型名单,基准现在还不够硬。
深度解读
ConceptKT 这篇先把任务边界改了:模型要预测学生未来题目的概念级薄弱点,不只猜对错。这一步是对的,因为教育场景里“答错”本来就不是可执行结论,老师和系统要的是补哪一个概念、拿什么历史证据去补。文章给出的机制也有点意思:按概念对齐和语义相似度选历史记录,优于随便拼上下文。这个判断我买账,因为知识追踪天然怕噪声,同一个学生做过 50 道题,不是每条历史都该进 prompt。 但我对这条 benchmark 现在的完成度有保留。正文没披露数据集规模、学科范围、标注一致性,也没给具体 LLM/LRM 名单。少了这几项,外部很难判断提升来自任务定义,还是来自提示工程筛样。教育数据尤其麻烦:概念标签一旦做得粗,模型学到的就不是“缺失概念”,而是题目模板和出题老师习惯。DKT、SAKT、AKT 这一系知识追踪工作,过去十年一直在刷 AUC;问题不在模型不会预测对错,问题在标签本身离教学动作太远。ConceptKT 至少在试着补这个洞,这点比再做一个 correctness benchmark 更有用。 我还有个疑虑:文章把 in-context learning 放得很前,但这类任务最后未必是大模型强项。知识追踪通常是长时序、强结构、低容错任务,专门的序列模型和图结构特征常常比通用 LLM 更稳。我记得这两年教育方向已经有不少工作把 RAG、学生画像、题目知识图谱塞进系统里,最后收益经常来自检索和标签设计,不是底座模型本身。ConceptKT 如果后续不能公开“历史选择前后提升多少、不同模型差多少、跨学科是否掉点”,它更像一个合理的新任务提案,还不是一个足够扎实的比较基准。
HKR 分解
hook knowledge resonance
打开信源
63
SCORE
H0·K1·R0
07:33
33d ago
● P1arXiv · cs.CL· atomEN07:33 · 03·25
Schema 放进模型内部:两阶段微调用于高效大规模 Text-to-SQL
论文提出一套两阶段监督微调方法,让 8B 自托管模型内化整库 schema,把 Text-to-SQL 输入从 1.7 万 token 压到 100 以内,降幅超 99%。该系统面向 Dream11 关联应用 CriQ 的板球统计问答,执行成功率 98.4%、语义准确率 92.5%,高于 Google Gemini Flash 2.0 基线的 95.6% 和 89.4%。真正值得盯的是,它用 schema 内化替代长上下文提示,正文未披露训练数据规模与具体基座模型名称。
#Fine-tuning#Code#Benchmarking#Dream11
精选理由
这篇研究同时命中 H/K/R:17k→<100 token 的压缩很抓人,正文也给出两阶段 SFT 机制与 98.4%/92.5% 指标,直击自托管 Text-to-SQL 的成本和时延。训练数据规模与基座模型名称未披露,影响外推性,所以进 featured,不到 p1。
编辑点评
Dream11 把 8B 模型训到吃透整库 schema,输入从 1.7 万 token 压到 100 以内;这条我买账,因为它打的不是长上下文炫技,是线上成本账。
深度解读
Dream11 这篇最扎实的点,是它用一台自托管 8B 模型换掉了 1.7 万 token 的 schema 提示,输入压到 100 以内,执行成功率做到 98.4%。如果数字可复现,这不是一个“Text-to-SQL 小优化”,而是一条很实在的产品路线:把数据库结构从推理时上下文,改成训练时参数记忆。 我一直觉得,过去一年不少 Text-to-SQL 系统有点走偏了。团队拿长上下文模型,把整库 DDL、列描述、样例 SQL、业务规则全塞进去,离线 demo 很顺,线上一算账就不对。17k token 的输入,哪怕用便宜模型,成本和延迟都不轻;一旦多轮对话再叠加历史消息,系统马上变成“能答,但不配大规模跑”。这篇给出的思路反而老派:既然 schema 相对稳定,就别每次都现喂,直接把它训进模型里。这个判断我认同,而且很像很多垂类 agent 迟早要走的路。 给个文章外的参照。去年到今年,业界一条常见路线是 RAG 检索 schema 片段,再配合 function calling 或 constrained decoding,尽量减少无关表进入上下文。很多团队也试过把库切成 domain schema,按问题召回 5 到 20 张相关表。我自己见过的生产系统里,这类方案通常能把 prompt 压到几百到几千 token,已经比“整库硬塞”强很多。Dream11 这里直接压到 100 以内,幅度明显更狠,所以它的价值不只在省 token,而在于它把检索依赖也往后挪了一步:先靠微调学结构,再用极短提示触发生成。这个方向跟前阵子不少“小模型做窄任务”的经验是一致的,模型未必要更大,任务边界清楚才更重要。 但我对这篇也有几处保留。第一,正文没披露基座模型名称。8B 和 8B 差很多,Llama 系、Qwen 系、Mistral 系,SQL 能力和 tokenizer 行为都不一样。第二,训练数据规模没给。两阶段微调到底用了多少 NL-SQL 对,schema 变体做了多少增强,负样本怎么构造,摘要里都没有。第三,评测范围看起来很窄,场景是 CriQ 的板球统计问答。这个垂直域本身就有强约束:实体类型有限,查询模式集中,业务口径稳定。92.5% 语义准确率放在这个场景里很不错,但它不能自动外推到企业 BI、金融风控、跨库联邦查询这些更脏的环境。 Gemini Flash 2.0 的对照我也不会照单全收。摘要说基线是 prompt-engineered,执行成功率 95.6%,语义准确率 89.4%。问题在于,Gemini 输掉这 2.8 和 3.1 个百分点,究竟是模型能力差,还是提示法天然吃亏?如果一边拿“现喂 17k schema 的 API 模型”,一边拿“见过全部 schema 的专门微调模型”,这其实不是同一赛道。公平的对比,应该再加一组:同一个 8B 基座,只做 schema 检索提示,不做内化;或者同一个 API 模型,加 constrained decoding、SQL grammar、execution feedback 之后再比。正文没给这些 ablation,我自己会把结论收着看。 还有一个工程上的问题,论文标题里“Schema on the Inside”很好听,落地时却有维护成本。数据库 schema 一旦频繁变更,新表上线、列重命名、口径调整、权限切换,参数内化会带来再训练或增量训练负担。RAG 路线的好处,是 schema 改了就改索引;内化路线的好处,是推理便宜且稳。两边是典型的训练时成本换推理时成本。Dream11 这个选择成立,我猜一个重要前提是 CriQ 的核心统计库变更频率不高。这个前提摘要没写,但如果没有它,99% 的压缩未必能顺利换成长期收益。 说真的,这条最有意思的地方,不是“8B 超过 Gemini Flash 2.0”,而是它提醒大家:很多企业工作负载根本不需要每次都把知识重新塞给模型。Schema、规则、术语表、固定工具调用路径,这些东西只要足够稳定,就该优先考虑蒸进小模型。过去一年大家太容易被长上下文窗口带着跑,仿佛 1M token 一开,系统设计问题就没了。我不太买账。上下文窗口是租来的,参数记忆才是买断的;对高频、窄域、可控数据面的问题,后者经常更便宜。 我还没查到原文里的误差分析。如果失败样本主要集中在多跳聚合、时间过滤、同义词映射、还是 join 路径选择,这会决定方法到底是“学会了 schema”,还是“学会了这批题型”。标题已经给出两阶段微调和结果数字,正文摘要没披露更细的 benchmark 设计。现阶段我会把它看成一篇方向对、工程味很重的论文,不会急着把它吹成通用 Text-to-SQL 新范式。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
07:32
33d ago
arXiv · cs.CL· atomEN07:32 · 03·25
十年拉锯:用教师引导的 RAG 解决漏洞分析中的冲突
论文称,过去十年超20万个漏洞被披露,超3万个条目后续被修改;作者提出两阶段框架 CRVA-TGRAG,处理 CVE 分析里的知识冲突。检索阶段用父文档分段、语义相似度加倒排索引的集成检索;生成阶段用教师引导偏好优化微调 LLM。真正该盯的是,正文未披露基座模型、数据集规模和具体分数。
#RAG#Fine-tuning#Benchmarking#Research release
精选理由
摘要给出检索与偏好优化框架,HKR-K 成立;但正文未披露基座模型、数据集规模和具体分数,HKR-H/R 都弱。场景集中在 CVE 分析,通用 AI 从业者缺少进入点,触发 hard-exclusion-technical-accessibility,故列为 excluded。
HKR 分解
hook knowledge resonance
打开信源
40
SCORE
H0·K1·R0
07:02
33d ago
arXiv · cs.CL· atomEN07:02 · 03·25
同规模 LLM 的语言适配基准:Llama-3.1-8B、Mistral-7B-v0.1 与 Qwen3-8B 在罗马化尼泊尔语上的研究
论文用 1 万条双语转写指令数据,比较 Llama-3.1-8B、Mistral-7B-v0.1 和 Qwen3-8B 在罗马化尼泊尔语上的零样本与微调表现。三者零样本均无法稳定生成该语言;经 QLoRA+rsLoRA、r=32、双 Tesla T4、总计不足 27 GPU 小时训练后,BERTScore 均接近 0.75,chrF++ 超过 23。Qwen3-8B 被列为综合首选,Llama-3.1-8B 的微调增益最大,PPL 下降 49.77、BERTScore 提升 0.3287。
#Fine-tuning#Benchmarking#Meta#Mistral AI
精选理由
K 轴成立:文章给出训练数据规模、微调方法、硬件条件和量化结果,信息密度够用。H 与 R 都弱:这是罗马化尼泊尔语的小语种微调基准,不是产品更新,也不直接影响多数从业者的路线判断,所以归入 all。
编辑点评
论文用1万条数据把一个常被忽视的事实钉死了:8B 开源模型对罗马化尼泊尔语几乎没内化,便宜微调比幻想零样本更靠谱。
深度解读
这篇论文用 1 万条样本证明,3 个 7B-8B 模型在零样本条件下都不能稳定生成罗马化尼泊尔语,而用 QLoRA+rsLoRA、r=32、双 T4、不到 27 GPU 小时就能把 BERTScore 拉到约 0.75。我的判断很直接:这不是“低资源语言适配成功”的大新闻,更像是在给行业纠偏——很多人还把开源模型的多语覆盖想得太乐观,尤其是这种长期活在拉丁转写、聊天拼写、口语缩写里的变体。预训练语料没吃进去,指望 prompt 自己长出来,基本不成立。 我比较认同作者把 Qwen3-8B 放在综合首选。摘要给出的依据有两个:它是唯一零样本还能产出语义相关内容的模型,SFT 后结构对齐指标也领先。这个结论不突兀。过去一年里,Qwen 系列在亚洲语言、混合脚本、代码切换场景上,经常比同尺寸 Llama 和早期 Mistral 更稳。我印象里,Qwen 2.5 和后来的 Qwen3 在很多非英语 benchmark 上就有这种倾向,不过这篇正文没展开 tokenizer 差异、预训练语料覆盖率、指令数据来源占比,所以“为什么是 Qwen 更强”现在还停在结果层,机制没有拆开。 Llama-3.1-8B 的信号也很有意思。它零样本最差,微调增益却最大,PPL 下降 49.77,BERTScore 提升 0.3287。这个模式我其实更愿意解读成“底座没学会,适配空间很大”,不是“Llama 更适合这个语言”。低起点带来的提升幅度,本来就容易显得漂亮。要是看最终落点,摘要只说三者都收敛到约 0.75 BERTScore、chrF++ 超过 23,优势有没有拉开,正文片段没有完整表格,我还没法替作者下更重的结论。 我对这类论文一直有个保留。BERTScore 0.75 和 chrF++ 23,在低资源转写任务里能说明“像那么回事”,离“可部署”还差一截。罗马化尼泊尔语最大的问题不是词面生成,而是拼写极不统一。同一句口语,转写方案能飘很多种。自动指标会把一部分合法变体当错,也会把语义空泛但表面接近的输出算进分数。摘要提到 5 类指标、7 个维度,但没给人工评测、一致性标注、错误类型拆分,也没说 zero-shot 的“架构特异失败模式”具体是什么。没有这些,我不会把 0.75 BERTScore 直接读成可用性里程碑。 还有一个上下文不能省。过去一年,大家已经见过不少“小数据把语言补起来”的案例:几千到几万条监督数据,配合 LoRA/QLoRA,在方言、转写体、行业术语上都能把小模型迅速拉回正轨。这个结果本身不反常。反常的是,罗马化尼泊尔语这种数字交流里高频存在的变体,直到现在才有一个像样基线。说真的,这暴露的不是方法缺口,而是评测视野太窄。模型公司喜欢报 100 多种语言支持,但对“脚本变体 + 非标准拼写 + 社交文本”这类真实使用面,覆盖常常是空的。 所以这篇论文的价值,我看不在于它把 8B 模型推到了多高,而在于它把一条很现实的工程路径写清楚了:先承认零样本不行,再用 1% 可训练参数和几十 GPU 小时补齐。这个成本对地区团队、学校实验室、甚至小产品组都够低。问题也在这里——摘要只有 RSS 片段,正文没披露训练/验证切分、数据清洗规则、是否处理拼写归一化、测试集是否含泄漏风险。基线是有了,离可复现和可比较,还差这些细节。
HKR 分解
hook knowledge resonance
打开信源
68
SCORE
H0·K1·R0
06:55
33d ago
arXiv · cs.CL· atomEN06:55 · 03·25
Sparse Growing Transformer:通过渐进式注意力循环进行训练时稀疏深度分配
Sparse Growing Transformer 提出训练时稀疏深度分配,把循环计算从深层逐步扩到浅层,并只作用于少量高信息量注意力头。摘要称它在多个参数规模上,较静态块级循环基线表现更好,同时把额外训练 FLOPs 开销从约16%–20%降到1%–3%。真正值得盯的是机制不是统一加深全块,而是按训练阶段选择性加深少数参数。
#Inference-opt#Reasoning#Benchmarking#arXiv
精选理由
这篇论文有 HKR-K:摘要给出选择性加深少数注意力头的机制,并报告额外训练 FLOPs 从 16%–20% 降到 1%–3%。HKR-H 与 HKR-R 都偏弱,题目过于训练架构化,离多数读者的产品决策与日常工作流较远,所以放在 all。
编辑点评
SGT把额外训练FLOPs压到1%到3%,这条我买账一半:方向对,摘要还没给出最关键的头选择稳定性。
深度解读
Sparse Growing Transformer把额外训练开销从16%到20%压到1%到3%,前提是它只循环少量高信息量注意力头。我的判断很直接:这篇东西有研究味,也有工程味,因为它碰的不是“再加深一点”这种老招,而是训练期结构该不该随时间变化。这个问题过去一年被反复证明有价值。MoE在做按token分配计算,test-time scaling在做按样本分配计算,SGT想做的是按训练阶段、按参数子集分配深度,路子是对的。 我对这条最感兴趣的,不是“progressive”这个词,而是作者声称发现了从深层到浅层的成熟轨迹。这个观察如果稳,含义很大:说明Transformer各层不是同步长成,训练前期让深层先吃到额外循环,可能比全块一起反复跑更省。类似的直觉,早几年在early exit、layer dropping、ACT一类工作里都出现过,只是那批方法大多把选择单位放在token、层或block,没细到attention head。我自己觉得,把head当作稀疏深度分配单元,思路比整块循环更干净,因为它更接近真正承载语义整合的位置。 但我对摘要里的叙事有两个保留。第一,所谓“high-entropy heads”到底怎么定义、怎么选、多久重选一次,正文片段没披露。这个细节决定方法能不能复现。头的重要性指标一旦对初始化、seed、数据配比敏感,1%到3%的额外FLOPs就未必能稳定换来收益。第二,比较对象只有“static block-level looping baselines”。这个基线选得不弱,但也不够狠。我要看的是它和更现实的训练效率手段怎么比,比如depth-up scaling、逐步增大context、甚至直接加一点token预算。摘要没给这些对照,我不会先把它判成通用配方。 还有个容易被标题带偏的点:这不是推理时提速。它是训练时把多出来的深度算力用得更窄。很多论文把训练期稀疏直接往部署效率上引,最后落地时发现推理图根本不是一回事。SGT标题里写的是training-time sparse depth allocation,这个边界要扣死。要是作者后面没有给出推理时兼容性、收敛稳定性、不同模型规模下的head分布变化,我会把它看成一篇很聪明的训练技巧,不是新的Transformer默认形态。 我还没查原文表格,所以不确认“多个参数规模”具体是多大,也不确认提升落在语言建模、下游任务,还是两者都有。标题和摘要已经给出一个清楚信号:统一给整块加循环,这条线快碰到性价比墙了。下一步更像外科手术,不像土木工程。SGT抓到了这个方向。它能不能站住,取决于那个“少量头”是不是跨种子、跨规模、跨数据都能选得准。
HKR 分解
hook knowledge resonance
打开信源
71
SCORE
H0·K1·R0
06:38
33d ago
arXiv · cs.CL· atomEN06:38 · 03·25
CoCR-RAG:用面向概念的上下文重构增强 Web 问答中的 RAG
论文提出 CoCR-RAG,用 AMR 概念蒸馏与 LLM 重构多源检索文档,在 Web 问答里生成更统一的知识上下文。实验覆盖 PopQA 和 EntityQuestions,摘要称其优于现有上下文重构方法;具体指标、所用 backbone LLM 名称与增幅,正文摘录未披露。真正值得盯的是它把多文档融合落到概念层,而不是继续堆检索片段。
#RAG#Reasoning#Benchmarking#arXiv
精选理由
论文提出 AMR 概念蒸馏加 LLM 上下文重构,给 RAG 多文档融合一个可辨认的新做法,K 命中。标题偏学术,摘要未披露提升幅度、backbone LLM 与复现条件,H 和 R 都弱,放在 all,不进 featured。
编辑点评
CoCR-RAG 把多文档融合前移到 AMR 概念层,这条路比继续堆 chunk 更像样;但摘要不给增幅和 backbone,我先只给半个赞成。
深度解读
CoCR-RAG 用 AMR 抽取概念并让 LLM 重写统一上下文,这个设计先把 RAG 里最脏的一步拿出来单做了。我的判断是,这比“多检索几段、长上下文硬塞进去”更对症,因为 Web Q&A 的错误常常不是没召回,而是证据粒度不齐、表述互相打架。摘要点名了 2 个数据集,PopQA 和 EntityQuestions,也说了跨多种 backbone LLM 稳定,但增幅、方差、所用模型名、重构长度、检索器配置,正文摘录都没披露,所以现在还不能把它当成可复现的强结论。 我对这条有兴趣,是因为它踩在一个老问题上:RAG 这两年一直擅长“找”,不太擅长“并”。从 FiD、Atlas 到近一年的 GraphRAG、RAPTOR、各种 context compression,大家都在处理同一件事——多文档证据进来以后,怎么别把噪声一并喂给模型。CoCR-RAG 的不同点,是它没有直接在句子层做 rerank 或 summarize,而是先用 AMR 这种结构化语义表示抽“概念骨架”。这套想法不新,AMR 在 NLP 里是老工具了,优势是能把“谁对谁做了什么”拆得比表层文本稳定。把 AMR 拉回 RAG,我觉得是个挺合理的回摆:大家在长上下文和大模型上冲太久,开始重新承认前处理结构化还有价值。 但我有两个保留。第一,AMR 解析本身不是免费午餐。网页文本很脏,标题、列表、表格、半句实体、SEO 垃圾都会让图结构质量波动。只要 AMR 抽歪了,后面的“概念蒸馏”就是在放大前面的偏差。摘要没给解析错误怎么传导,也没给不同网页类型上的消融。第二,LLM reconstruction 这一步听起来干净,实际很容易把“统一上下文”做成“统一口径”。证据冲突是 Web Q&A 的常态,不是噪声而已。一个重构器如果过度追求连贯,可能会把矛盾证据磨平,最后读起来更顺,事实性反而更差。摘要说它只补必要句子成分,但“必要”怎么定义,正文摘录没有。 我还想看一个很具体的对比:它赢的是普通 context reconstruction baseline,还是也能赢掉强一些的 late-interaction 或 citation-first 流程。因为这两年不少系统在产品里宁可保留证据碎片和出处,也不愿先合成一段漂亮上下文,原因就是后者更难审计。若 CoCR-RAG 只能提升最终 EM/F1,却让 citation 对齐变差,那工程价值会打折。相反,如果它能在答案正确率之外,把证据覆盖率、冲突保留率、引用可追踪性一起做上去,这条线就不只是论文技巧了。 坦率地讲,我觉得这篇最可能有用的地方,不在“又一个 RAG 框架”,而在给行业提了个醒:多源检索的瓶颈正在从 recall 转向 semantic consolidation。现在标题信息只够支持这个方向判断,不够支持性能判断。我要等论文里的具体数字,尤其是相对 GraphRAG、compression、直接 long-context baselines 的增幅,再决定这是不是一条能进生产的方案。
HKR 分解
hook knowledge resonance
打开信源
70
SCORE
H0·K1·R0
06:07
33d ago
● P1arXiv · cs.CL· atomEN06:07 · 03·25
价格反转现象:更便宜的推理模型为何反而更贵
论文评测8个前沿推理模型、9类任务后发现,21.8%的模型两两比较出现“标价更低、实际总成本更高”,最高反转达28倍。文中给出一例:Gemini 3 Flash 标价比 GPT-5.2 低78%,跨任务实际成本却高22%;主因是 thinking token 消耗差异可达900%,去掉这部分后反转减少70%。真正值得盯的是单次请求成本监控,因为同一查询重复运行的 thinking token 波动最高达9.7倍,正文据此认为挂牌 API 价格不适合直接做代理成本。
#Reasoning#Benchmarking#Inference-opt#Gemini 3 Flash
精选理由
HKR 三轴都成立:标题的“低标价高总成本”有反差,正文也给出 8 个模型、9 类任务、21.8% 反转和最高 28 倍等可检验数字。它对模型采购与 agent 成本核算很实用,但还是单篇 arXiv 研究,不到 85 分的当天必写档。
编辑点评
论文测出 21.8% 的模型对会出现“低标价高实付”,这基本宣告按官网价选推理模型这套方法已经过时。
深度解读
论文给了一个很硬的结论:8 个前沿推理模型在 9 类任务里,21.8% 的两两比较会出现价格反转,最高到 28 倍。这个数字已经够把很多代理层、路由层的成本假设推翻了。你在价格页上看到的 input/output 单价,并不等于你最后为一次“会思考”的请求付的钱。文中把主因指向 thinking token,而且给了两个关键数字:模型间同题消耗差异最高 900%,同一查询重复运行的波动最高 9.7 倍。只要这两个数站得住,按挂牌 API 价格做选型、做自动路由、做毛利测算,都会系统性偏差。
HKR 分解
hook knowledge resonance
打开信源
87
SCORE
H1·K1·R1
05:31
33d ago
arXiv · cs.CL· atomEN05:31 · 03·25
时间序知识检索:面向施工项目文档的检索增强生成方法
该论文提出一个面向施工会议纪要的 RAG 系统,支持自然语言提问,并返回带时间标注的答案以重建决策时间线。实验基于比利时一家大型公司的匿名项目纪要数据集;正文未披露样本规模与模型名称,但说明数据集、专家查询集和开源实现已公开。
#RAG#Tools#Benchmarking#Research release
精选理由
这是一篇有复现材料的垂直 RAG 应用论文,HKR 里主要命中 K:公开数据集、专家查询集和实现,且给出按时间重建决策的机制。短板也很清楚:正文未披露样本规模与模型名称,场景又偏施工文档,讨论面不够宽,所以只能进 all。
编辑点评
论文把施工会议纪要接成可追时间线的 RAG,这个方向是对的;但样本规模、模型名、基线都没给,我先不给高分。
深度解读
这篇论文把 RAG 落在了一个很具体的痛点上:施工项目的会议纪要会不断推翻旧决定,人真正难找的不是“答案”,而是“哪天改了、谁先提了、后来被谁覆盖了”。如果系统能稳定给出带时间标注的回答,它解决的就不是普通问答,而是责任追踪和决策重建。这个定位我买账,因为很多行业文档检索失败,根子都不是召回率低,而是没有把“时间顺序”当成一等公民。 我对这条的第一反应是,它比常见的企业知识库 RAG 更接近真实工作流。法律、医疗、工程、采购这几类场景,用户经常问的都不是静态事实,而是“版本怎么演化”。过去一年里不少 RAG 系统都在卷长上下文、卷 agent、卷多跳推理,但进到企业文档后,经常卡在一个很土的问题:旧信息和新信息同时被检出,模型却不会判断哪条在时间上已经失效。这个论文至少承认了这个问题,而且试图把时间标注直接放进答案层,而不是只做检索排序。我一直觉得这类工作比再发一个“通用企业 Copilot”靠谱得多。 但我对论文目前披露的信息保留很大疑问。标题和摘要给了方向,正文摘要没给三个关键量:数据集规模、底座模型名称、评测基线。没有样本量,你没法判断这是几十份纪要上的原型,还是跨数年的真实项目语料。没有模型名,你没法判断效果来自时间建模,还是单纯吃了更强的通用 LLM。没有基线,你也没法知道“时间标注回答”到底比 BM25、普通向量检索、按日期过滤的检索强多少。尤其是这种任务,简单规则法常常并不差:先抽日期、议题、实体,再按时间排序,最后让模型只做压缩总结。论文如果没和这种强规则基线比,我会觉得论证没站稳。 还有一个我很在意的点:施工会议纪要里的“时间”不总是显式时间戳。很多改动是隐式发生的,比如“维持上次方案,除非土方成本再涨”“暂缓,待供应商确认”。这类句子牵涉条件生效、否定、覆盖范围、跨会议引用。RAG 把相关段落找回来不难,难的是判断哪条决定在当前问题下仍然有效。这个部分如果只是生成时附带会议日期,那叫“带时间的引用”,还不叫“时间推理”。摘要里没有展开机制,我还没法确认作者做到哪一步。 外部参照也很明确。过去一年学术界和工业界都在补“temporal RAG”这块,常见做法有三类:给 chunk 加时间元数据,在检索阶段重排;把问题改写成带时间约束的查询;或者把时间线显式建成图,再让模型沿图遍历。我没在摘要里看到这篇用了哪一种。如果只是“语义检索 + LLM + 时间标签”,那工程价值有,但研究新意未必高。反过来,如果它开源的数据集和专家查询足够干净,这篇的贡献就可能主要在 benchmark,而不是方法。我其实更看重后者,因为行业文档里的时间冲突数据集一直很少,能公开出来已经有用。 我还有个现实层面的 pushback。施工行业是很好的垂直场景,但它也容易让结果显得比实际更好。项目纪要的写法通常相对规范,日期、参与方、议题都比较固定;换到邮件串、IM 聊天、附件 PDF、扫描件混合的企业环境,难度会陡增。很多公司真正的决策链并不完整地留在正式纪要里,而是散在 WhatsApp、Excel、变更单和口头确认里。论文如果只在单一项目、单一公司、单一文档类型上验证,泛化能力就别吹太满。摘要里只说了比利时一家大型公司,我还没查到跨项目和跨组织测试。 所以我对这条的判断是:问题选得对,开源数据这件事有价值,研究完成度暂时看不够。要不要认真看原文,我会先翻三处:数据集到底有多少会议、多少问答;评测是不是把“时间正确”单独算分;基线里有没有规则系统和普通 RAG。三项里缺两项,这篇更像一个场景化 demo;三项都齐,它才有机会变成企业时序文档检索的一个像样基准。
HKR 分解
hook knowledge resonance
打开信源
64
SCORE
H0·K1·R0
05:19
33d ago
● P1arXiv · cs.CL· atomEN05:19 · 03·25
从 AI 助手到 AI Scientist:用 LLM Agents 自主发现 LLM-RL 算法
论文提出 POISE 闭环框架,并在数学推理实验中从 GRPO 出发评估 64 个候选算法。最佳变体把加权 Overall 从 47.8 提升到 52.5,AIME25 pass@32 从 26.7% 提升到 43.3%。真正值得盯的是,它把提案、可执行实现、标准化评测和自然语言反思接成带谱系的归档,用证据驱动 RL 算法迭代。
#Agent#Reasoning#Benchmarking#Research release
精选理由
HKR 三项都过:标题有“AI Scientist”钩子,正文也给出 64 个候选与 AIME25 pass@32 26.7%→43.3% 的可核对结果。分数停在 82,因为它仍是 arXiv 研究发布,离模型发布或产品更新的即时行业影响差一档。
编辑点评
POISE 用 64 个候选变体把 GRPO 的 AIME25 pass@32 从 26.7% 拉到 43.3%,这条我买一半:提升不小,但离“AI Scientist”还差一整套跨任务复现。
深度解读
POISE 这篇的关键信号,不是“LLM 自己发明了新 RL 算法”,而是作者把算法搜索流程做成了可积累的实验系统。论文说它从 GRPO 出发评估 64 个候选算法,把 weighted Overall 从 47.8 提到 52.5,把 AIME25 pass@32 从 26.7% 提到 43.3%。这两个数字够说明一件事:在 LLM-RL 这块,很多增益还埋在训练机制细节里,不一定非要等下一代基座模型。 我对标题里的 “AI Scientist” 还是保留态度。正文给到的事实,是 POISE 维护了一个带谱系的归档,把 proposal、可执行实现、标准化评测、自然语言反思串起来。这个设计是对的,而且比“让 agent 暴力改代码然后刷 benchmark”高一个层级。问题也在这:它目前展示的是封闭搜索空间里的机制迭代,不是开放式科学发现。起点是 GRPO,任务是 mathematical reasoning,候选数是 64。这个规模更像自动化 research engineering,不像已经跨到“scientist”。 外部参照其实很清楚。过去一年,大家已经见过不少“agent 做研究”的 demo,常见模式是文献检索、提假设、写实验脚本、跑 ablation,最后卡在两处:一是实验噪声大,二是知识没法沉淀。POISE 这次比那些工作更像样的地方,正是它把每次尝试的证据链留住了。这个思路让我想到材料科学和 AutoML 里那些 active learning loop:模型不一定每轮都更聪明,但系统会越来越会少走弯路。放到 LLM-RL,这比单次刷出一个新 trick 更有价值。 但我有两个疑虑。第一,正文没披露训练成本、样本量、基座模型规模,也没说 64 个候选里失败分布长什么样。没有这些信息,很难判断这 4.6 分提升到底是高效搜索,还是靠算力堆出来的。第二,最好变体包含 analytic-variance scaling 和 validity masking,这听起来像很合理的机制修补,但泛化范围正文没给。它们在 AIME25 上有效,不等于在 code、tool use、long-horizon agent 任务上也有效。RL 这几年最常见的坑,就是某个奖励塑形或 advantage 处理在单任务上很亮眼,换数据分布就掉。 我还想追问一个更硬的问题:基线是不是够强。GRPO 是这一轮推理 RL 里常用起点,没问题;但如果没有和 DAPO、PPO 变体、长度归一化奖励、不同 verifier 设定做更完整对比,这个结果的解释空间还是很大。我没在摘要里看到这些细节,所以不能替作者补完。 我的判断是,这篇论文值得看,不是因为它证明了“AI Scientist 已来”,而是它把 LLM-RL 从手工作坊往可追溯的实验工厂推了一步。这个方向一旦跑通,后面最先被改写的不是 headline,而是算法研究的节奏:一个团队不再靠研究员记忆和直觉管理试错,而是靠归档、反思、复用证据管理试错。听起来不浪漫,但这往往才是能稳定产出改进的那种东西。
HKR 分解
hook knowledge resonance
打开信源
88
SCORE
H1·K1·R1
05:10
33d ago
arXiv · cs.CL· atomEN05:10 · 03·25
将论证挖掘建模为文本到文本生成任务
论文提出一个基于预训练编码器-解码器模型的文本到文本方法,同时生成论证跨度、组件和关系标注,替代多子任务流水线与规则后处理。实验在 AAEC、AbstRCT 和 CDCP 三个基准上达到 SOTA;正文未披露具体模型名、分数和参数规模。真正值得盯的是,它把结构化论证解析压成单次生成,少了后处理,也少了超参搜索面。
#Reasoning#Benchmarking#Research release#Benchmark
精选理由
这是一篇窄领域 NLP 研究,HKR 里主要命中 K:把论证跨度、组件和关系压成单次生成,并在 AAEC、AbstRCT、CDCP 三个基准报 SOTA。H 与 R 都弱,摘要未披露模型名、具体分数和落地条件,对多数 AI 从业者更像 benchmark 增量,所以给 all。
编辑点评
论文把论证挖掘压成单次生成,并在 3 个基准报 SOTA;我先不急着叫好,正文没给模型名和分数,这条证据还不够硬。
深度解读
论文用预训练编码器—解码器同时生成论证跨度、组件和关系,并在 AAEC、AbstRCT、CDCP 3 个基准报 SOTA。我的判断是,这条路子方向没问题,但眼下更像“把工程复杂度收回来”,还没证明它把论证挖掘这件事真正做深了。标题和摘要给了方法框架,正文片段没披露模型名、参数规模、输入输出格式、约束解码方式,也没给具体分数;这些信息一缺,SOTA 的含金量就没法判断。 我一直觉得 argument mining 这类任务最麻烦的地方,不在分类器换成生成器,而在结构约束很难一次说清。你要同时预测 span、stance、support/attack 关系,还要保证结构合法,老 pipeline 虽然笨,但每一步错在哪还能拆出来看。现在压成 text-to-text,一次生成全吐出来,确实省掉了 rule-based postprocessing 和一堆超参搜索,可代价是错误会纠缠在一起:span 边界偏了 3 个 token,后面的 component 和 relation 全连带出错。摘要没讲他们怎么处理非法结构,也没讲输出序列长度一长之后是否掉点。我对“省掉后处理”这句有点保留,因为很多结构化生成方法只是把后处理从显式规则挪到了输出模板、special tokens、解码约束里,不是凭空消失。 外部参照其实很清楚。信息抽取、事件抽取、语义解析这几条线,过去两年都在做同一件事:把多阶段 pipeline 改成 seq2seq 或 instruction generation。T5、BART 那波之后,大家早就知道生成式统一接口有工程优势,尤其在低资源和跨 schema 迁移上比较顺手。argument mining 现在补上这一步,不算意外。我没查到这篇具体用了哪一个 encoder-decoder,但如果还是 T5 系、FLAN-T5 系,或者 BART 的变体,那它的贡献更像任务表述而不是基础模型突破。这个定位我觉得没问题,只是别把它讲成 reasoning 能力跃迁。 还有一个老问题,这篇摘要完全没碰:3 个数据集的标注体系差异很大。AAEC 偏 essay 论证结构,AbstRCT 是 scientific abstract,CDCP 又是 policy/rulemaking 语料。一个统一生成格式能跨这三套 schema,说明方法有弹性;但如果每个数据集都单独设计 verbalization template,那“统一”二字就得打折。我自己更想看 zero-shot 或 cross-dataset transfer,比如在 AAEC 上训、到 CDCP 上掉多少,而不是只看各自 benchmark 的封闭测试分数。正文片段没给,这里没法替它补。 说真的,这类论文最容易被“SOTA on three benchmarks”这句话带偏。argument mining 基准本来就不算大,很多数据集规模只有几千样本量级,split 的处理、span matching 口径、relation evaluation 是 exact match 还是 softer metric,都会让结果差出一截。没有数字,没有方差,没有 ablation,没有 error breakdown,我不会把这条当成领域拐点。我更愿意把它看成一个很合理的整理动作:把过去拆开的 span/component/relation 预测,改写成一个统一生成接口,降低维护成本,也让迁移到新 schema 更省事。 这条值不值得继续跟,不在“SOTA”三个字,在两个还没披露的点。第一,输出约束怎么做;如果没有约束,结构合法性大概率靠运气。第二,和强 pipeline 的差距到底有多大;如果只是高 0.5 到 1 个点,但换来更差可解释性,很多实际系统未必会换。我要是做法务文本、政策评论、学术摘要里的论证解析,会先等作者放出完整论文和代码,再看 error case,而不是先把现有 pipeline 推翻。
HKR 分解
hook knowledge resonance
打开信源
68
SCORE
H0·K1·R0
04:58
33d ago
arXiv · cs.CL· atomEN04:58 · 03·25
用于循证医学指南代理开发的对话转问题生成
该研究用 Gemini 2.5 在 80 份去标识化真实临床对话上生成循证医学问题,并比较 zero-shot 与多阶段推理两种提示策略。6 名资深医生完成超 90 小时结构化评审;结果称模型已能提出有临床意义且贴合指南的问题,但可靠性仍不足。真正值得盯的是任务设定:它做问题生成,不做问答,用提问来支架医生推理。
#Reasoning#Agent#Benchmarking#Gemini
精选理由
HKR-K 明确成立:文章给出80份去标识化临床对话、zero-shot 对比多阶段推理、6名资深医生超90小时评审。分数停在 all,因为这是医疗垂直研究,不是通用产品更新,也没有公开系统能力、价格或大范围部署证据。
编辑点评
这篇论文拿 80 份真实门诊对话试问题生成,方向选得比“直接给答案”更稳,但离临床可用还差一层可验证性。
深度解读
研究团队用 Gemini 2.5 处理 80 份去标识化临床对话,并让 6 名资深医生做了 90 多小时评审。这个设计里,我最认同的不是模型效果,而是任务切法:先生成循证问题,再把判断权留给医生。医疗场景里,问错问题通常比答得不全更容易被人类纠偏;反过来,系统一旦直接给诊断或处置建议,责任链和误导成本都会陡增。 这条路其实跟过去一年医疗 AI 的一个回摆很一致。前几年很多团队爱做“问答式临床助手”,宣传里常把指南压缩、诊断建议、处方建议放在一起。落地时就撞上同一个墙:医生不缺会说话的系统,缺的是在 10 到 15 分钟门诊里,帮他少漏问一个关键条件。我记得 Abridge、Nuance DAX 这类环境临床产品,主力价值一直是记录和总结,不太敢把“主动医学判断”顶到前台。这个论文把模型放在“提问支架”位置,我觉得更像现实产品路线。 但我对结果表述还是有点保留。摘要只说“有临床意义”“贴合指南”“可靠性不足”,没给通过率、医生间一致性、专科分布、问题类型错误率,也没说 multi-stage reasoning 比 zero-shot 好多少。没有这些数字,你很难判断它是在 80 例里偶尔提到几个好问题,还是已经稳定覆盖病史采集、危险信号、指南分层这几类核心点。正文如果有,我这里没看到;目前只有 RSS 摘要信息。 我还会追问两个部署层面的硬问题。第一,转录质量怎么控。临床对话里的 ASR 错一个药名、剂量、时间词,后面的“好问题”就会沿着错前提继续推。第二,触发阈值怎么设。门诊里每多弹一个问题,都是打断;如果召回高但精度低,医生很快就会关掉。这也是为什么“问题生成”听上去保守,产品上反而更难:你得证明每次插话都值那几秒注意力。 所以我对这篇的判断是:方向对,证据还不够硬。它提示了一个比“医疗大模型给答案”更靠谱的产品姿势,但离指南级 agent 还有一段距离。下一步最该补的不是更多主观好评,而是错误分型、跨医生一致性、不同病种的分层表现,还有在真实门诊流里是否真的减少遗漏。
HKR 分解
hook knowledge resonance
打开信源
69
SCORE
H0·K1·R0
04:00
33d ago
arXiv · cs.CL· atomEN04:00 · 03·25
用于多 Token 预测的自蒸馏
论文提出 MTP-D 自蒸馏方法,把多 Token 预测头的接受率提高 7.5%,同时尽量保住主头性能。作者还给出 looped extension 策略,使扩展后的 MTP 头相对 1-head MTP 再提速 220.4%;结果基于 7 个基准,正文未披露模型规模、训练算力和具体延迟绝对值。
#Inference-opt#Fine-tuning#Benchmarking#Research release
精选理由
K 轴成立:论文至少给出两组可检验数字,并覆盖 7 个基准。问题在于题材偏向推理优化细节,正文又未披露模型规模、训练算力和绝对延迟,普通 AI 从业者很难判断外推价值,触发技术可达性排除,故 capped 到 excluded。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H0·K1·R0
02:09
33d ago
● P1arXiv · cs.CL· atomEN02:09 · 03·25
BeliefShift:评测 LLM 代理的时间性信念一致性与观点漂移
BeliefShift 发布一套纵向基准,评测 LLM 代理在多轮多会话中的信念一致性与观点漂移,数据集含 2400 条人工标注轨迹。它覆盖时间性信念一致性、矛盾检测、证据驱动修正三条任务线,并评测 GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro 等 7 个模型在 zero-shot 与 RAG 下的表现。真正值得盯的是权衡:强个性化模型更难抵抗漂移,重事实模型又会错过合理更新。
#Memory#RAG#Benchmarking#OpenAI
精选理由
这篇研究不只是刷分基准,它把多会话 Agent 的“保持一致”与“根据新证据改口”拆成 3 条任务线,并给出 2400 条标注轨迹和 7 个模型对比。HKR 三项都成立,但它仍是单篇 arXiv 论文,不到同日必写级。
编辑点评
BeliefShift 用 2400 条轨迹把“长期记忆”从检索题改成了更新题;这条我买账,因为很多 agent 现在坏就坏在把用户昨天的话当永恒真理。
深度解读
BeliefShift 构建了 2400 条人工标注轨迹,并把评测对象从静态记忆改成多会话中的信念更新。这个设定我认同,因为现在不少 memory benchmark 还停在“记住用户最爱蓝色”“记住过敏史”这类 slot retrieval,离真实 agent 差一截。人会改口,也会被新证据说服,还会在不同语境里表达冲突偏好。模型如果只会把旧信息塞进向量库,时间一拉长,输出就很容易变成温和版的确认偏误机。 这篇东西有价值,不在它又发了四个新指标名,而在它把一个长期被忽略的问题钉死了:一致性不是越高越好。文章给出三条任务线,时间性信念一致性、矛盾检测、证据驱动修正,这个拆法基本对路。做 agent 的人都见过两种坏结果:一种是模型过度迎合,用户今天说一句就全盘漂;另一种是模型过度守旧,明明有新证据,还是抱着旧 profile 不放。BeliefShift 把这两个错误放进同一张卷子里考,这比单独测 memory hit rate 更接近部署现场。 我想到的外部参照,是 2024 到 2025 年那波“长期记忆产品化”。OpenAI、Anthropic、Google 都在推更长会话和记忆功能,很多 demo 都把“记住你”当卖点,但公开评测大多没有认真处理 belief revision。更接近的旧问题其实不是 memory,而是 persona stability 和 sycophancy。OpenAI 之前就因为模型过度迎合挨过批评;Anthropic 也一直把 harmlessness 和 honesty 的拉扯放在 system card 里讲。BeliefShift 把这些分散问题收束成一个 longitudinal benchmark,这一步是补课,不是锦上添花。 我也有两个保留。第一,正文只给了模型名单和任务框架,没有给出关键结果表、误差分布、跨领域差异,也没说 2400 条轨迹在健康、政治、价值观、消费偏好四类里的占比。没有这些,你很难判断 benchmark 是在测通用能力,还是被某几类高争议样本牵着走。第二,RAG 设置的细节正文没披露。检索源是什么,检索到的是用户历史原话、结构化画像,还是外部事实证据?这三种东西混在一起,分数解释会完全不同。很多团队会把“接了 RAG 后更稳”当结论,但稳的是引用旧缓存,还是正确吸收新证据,差别很大。 我还想追问一个更硬的问题:这里测的到底是 belief consistency,还是 instruction hierarchy 下的表面对齐?如果用户新说法和系统安全约束冲突,模型不改口,算 stubborn 还是 correct?如果用户表达含糊,模型主动求证,指标怎么记?BRA、DCS、CRR、ESI 这四个名字听着完整,但正文没披露标注协议和阈值。我自己没看到论文原文里的 rubric,所以不会先认这些数一定站得住。 即便这样,这条研究还是有现实含义。做 memory agent 的团队以后很难再拿“召回率高”糊弄过去了。你至少得证明三件事:模型能保留稳定偏好,能发现自相矛盾,能在证据足够时更新,而且不会因为个性化过强而一路漂走。BeliefShift 把考题出出来了。下一步就看谁敢把自己的 production agent 放上去跑。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
02:01
33d ago
● P1arXiv · cs.CL· atomEN02:01 · 03·25
语言模型规划器不扩展,形式化器会吗?
论文称,LLM formalizers 在 BlocksWorld 状态空间达 10^165 时,部分模型仍保持 100% 准确率,明显强于同类 LLM planners。摘要还给出两种机制:对较小 formalizers 用 divide-and-conquer formalizing 提升鲁棒性;对一行描述对应指数级 PDDL 展开的任务,用“LLM-as-higher-order-formalizer”生成程序生成器。真正值得盯的是,正文片段未披露具体模型名、基线设置与样本规模。
#Reasoning#Tools#Benchmarking#Research release
精选理由
这篇研究命中 HKR 三轴:标题有反转,摘要给出 10^165 与 100% 准确率,还碰到 agent 规划路线之争。分数停在 80,因为正文未披露具体模型名、基线设置与样本规模,证据链还不够完整。
编辑点评
论文声称 formalizer 在 BlocksWorld 的 10^165 状态空间仍达 100% 准确,但正文没给模型名和样本量,我先不买“可扩展”这顶帽子。
深度解读
论文给了一个很硬的结论:部分 LLM formalizer 在 BlocksWorld 状态空间到 10^165 时,准确率仍是 100%。这句话如果实验口径站得住,打到的不是“规划做得更好”这层,而是另一层:把自然语言先编译成求解器友好的形式,可能比让模型直接搜计划稳得多。 我对这个方向一直是认可的。原因很简单。planner 要同时做状态建模、约束保持、长程搜索,还要扛住上下文噪声。formalizer 把问题拆开了。LLM 只负责把描述转成 PDDL、程序或约束系统,真正的组合搜索交给符号求解器。这条路其实不新。去年到今年,很多代码 agent、定理证明、SQL 生成系统都在干同一件事:把“直接回答”换成“先生成中间表示”。只要中间表示可验证,规模上去以后,稳定性通常比端到端生成强。 但这篇的标题有一点我会按住不吹。“formalizer 会扩展”不等于“模型会规划”。BlocksWorld 到 10^165 听着吓人,可状态空间大,不代表测试集就难到同一个量级。关键要看 4 个条件。用了哪些模型。planner 基线是谁。每档复杂度各有多少样本。100% 是 exact match、可执行成功率,还是经求解器修补后的成功率。正文片段都没披露。这不是小缺口,这是决定结论能不能成立的骨架。 我还有个具体疑虑。BlocksWorld 是经典域,但也正因为经典,模板化风险很高。物体、动作、先决条件、目标形式都很规整。一个强一点的模型学会“把句子翻成固定 schema”,拿高分不奇怪。难点在域外泛化。要是换到 logistics、gripper、甚至带数值约束和时序约束的 domain,100% 还在不在?摘要没说。我自己更想看的是跨 domain 的 formalization 成功率,而不是单域里把规模一路拉大。 文中两招倒是有意思。第一招是 divide-and-conquer formalizing,给小模型补鲁棒性。这很像过去一年 agent 工程里的常识:别让一个模型同时吃下解析、分解、生成、校验四件事,拆阶段通常比加 CoT 更有效。第二招“LLM-as-higher-order-formalizer”更关键。它让模型生成 program generator,而不是直接吐指数级展开后的 PDDL。这个思路我比较买账,因为它正面处理了 token 长度和组合爆炸的错位:难的不是推理链不够长,而是输出接口太短。把一次性文本输出改成生成器,本质上是在换计算图。 外部参照也很清楚。过去一年不少“reasoning model”在规划、博弈、搜索类任务上都暴露过同一个问题:链条写得更长,不自动等于搜索更深。我记得至少有几类工作都指出,LLM 在需要严格状态转移时,错误会累积得很快;反过来,一旦接上 SAT、SMT、规划器、解释器,性能曲线会平很多。这个结果如果完整实验能复现,价值就在这里:它给“LLM 做编译前端,solver 做求解后端”又补了一根证据。 但我还是要泼点冷水。100% accuracy 这种数字太整齐了。我看到这种数字,第一反应不是惊艳,是问评测集有多大、是否有数据污染、失败样例是否被过滤、以及求解器是否替模型擦了屁股。没有这些,标题只能说明“这条路线值得继续看”,还说明不了“planner 不行,formalizer 已经行了”。 所以这篇我会先记成一个方向信号,不记成能力定论。它押注的不是更会想的 LLM,而是更会把问题翻译成机器可验证接口的 LLM。这个判断我基本同意。至于“do formalizers scale”这句,现在证据只够回答半句:在 BlocksWorld 的某种设定里,作者说能。离通用结论还差模型名、基线表、样本规模和跨域结果。
HKR 分解
hook knowledge resonance
打开信源
86
SCORE
H1·K1·R1
01:09
33d ago
arXiv · cs.CL· atomEN01:09 · 03·25
Perturbation:一种用于语言模型表征学习的简单高效对抗追踪器
该论文用单个对抗样本微调语言模型,并测量扰动向其他样本的传播,以追踪表征学习。方法把表征定义为“学习的传导通道”,不依赖线性等几何假设;摘要称它不会在未训练模型里误检表征。真正值得盯的是,它在已训练模型中观察到跨多种语言粒度的结构化迁移;正文未披露实验规模、基座模型与量化结果。
#Interpretability#Fine-tuning#Research release
精选理由
这篇论文有一条可测试的新机制,HKR-K 成立:单样本对抗微调后观察扰动传播来追踪表征。它仍触发硬排除“技术可达性不足”,题材偏表征学习内圈,正文也未披露实验规模、基座模型与量化结果,所以 importance cap 到 37,tier 设为 excluded。
HKR 分解
hook knowledge resonance
打开信源
43
SCORE
H0·K1·R0

更多

频道

后台