论文很扎实，但有几个细节值得挑刺。
"小模型碾压大模型"的叙事有误导性。 OCC-RAG 只在"忠实性问答"这一个任务上超过通用模型。放到 general QA、代码生成、创意写作上，0.6B 肯定打不过 1.7B。论文自己也承认，8B 以上模型在多跳推理上仍有优势。所以这不是"小模型全面胜利"，是"任务专用模型在特定任务上赢了通用模型"——这个结论本身不新鲜，MiniLLM、Phi、DistilBERT 都是这个路数。OCC-RAG 的新意在于数据生成 pipeline 和训练课程设计，而不是"小能胜大"这个命题本身。
反事实测试的设置有选择性。 论文用了一个极端例子（戴高乐是美国总统），这种明显反常识的上下文，模型很容易判断"这和我知识冲突，所以我该跟上下文"。但如果上下文是"半真半假"——比如一个常见错误说法，模型还能保持忠实吗？论文没有测试这种边界情况。现实文档里，错误信息往往不是故意编造的，而是 outdated、partially correct、或者 subtlely misleading。OCC-RAG 在这些场景下的表现更重要。
300万合成数据的覆盖度存疑。 论文说数据从"Wikipedia 和开源知识图"生成，但没有公开具体源数据分布。如果知识图偏向西方知识（Wikipedia 的语言分布确实如此），那模型在非西方知识领域（比如中国法律、印度医学）的忠实性可能打折扣。这对"落地直接用"的宣传是个潜在风险。
训练成本被低估了。 8张 H100 训练 17-28 小时，单次训练成本约 500-1000 美元。这看起来不多，但如果你想在自己的领域数据上重新 mid-training，需要重复这个流程。数据生成 pipeline 本身也需要 GPU 资源。对创业公司来说，"直接用 checkpoint"是可行的，但"定制化训练"的门槛并不低。
结构化输出格式有潜在问题。 强制推理轨迹增加了输出长度。如果上下文很长（比如 10 篇文档），推理轨迹可能比答案本身长 5-10 倍。这对 latency 敏感的场景（客服、实时搜索）是负担。论文没有报告推理速度和输出长度分布，只给了准确率数字。
总结：OCC-RAG 是一个设计精良的任务专用模型，数据生成策略和训练课程值得学习。但"小模型碾压大模型"的标题党叙事掩盖了它的真正价值——不是参数效率，而是训练数据质量和任务目标的精确对齐。