LLM 的概念是「找」出来的还是「设计」出来的？一篇论文选了后者

2026年7月30日

跟模型打交道多了——调 prompt、做 RAG、搭 Agent——都碰过同一件事：LLM 能理解「概念」，很多时候靠运气。

聊「苹果」说得头头是道。但想精确控制它怎么理解「责任」、区分「建议」和「命令」、或者在生成代码时把「安全性」约束嵌进每一行——prompt 搞不定。

问题不是模型里没有这些概念信息。它们都在，只是以分布式统计关联的隐式形式存在，不是显式结构化的。设计阶段没法告诉模型「这是我希望你用来组织知识的概念骨架」。

2026 年 7 月上 arXiv 的一篇论文把这个局面摊开了。标题很直白：「From Found to Designed: Concepts as a Design Axis for Large Language Models」，作者 Chen Shani。它说现在对 LLM 中「概念」的处理基本是事后挖掘——训练完了再用 probing、字典学习之类的工具去「发现」，没有架构上的稳定性保障，不可组合、不受控，跟人的概念组织方式也不一定对齐。

论文提了一个更激进的方向：概念应该成为 LLM 的一个设计轴。不是训练完了去里面找，而是在设计模型时就把概念结构放进去。

作者画了一个二维设计空间。一维是「在哪个阶段引入概念结构」——训练目标、核心架构、推理阶段、事后解释。另一维是「概念结构来自模型内部，还是外部资源」。这张地图铺开后，几个问题很扎眼。

推理阶段的方法，在论文分析里属于明显被低估的那一类。多数人把精力花在训练前做数据筛选、训练后做 probing 上，但模型跑推理时，能让概念显式参与决策的手段反而最少。散落在不同 pipeline 阶段的相关工作也彼此隔离——做训练目标的不跟做架构改动的对话，做事后解释的跟做推理干预的隔着沟。外部知识注入这条线倒是全 pipeline 都有方法在跑，但常常不叫同一个名字，明明在做类似的事，互相不知道。

这篇论文更接近一份设计宣言加研究路线图，不是拿来就能跑的工具。但指的方向，对任何跟模型可控性较劲的人来说都很切身。做过 Activation Steering、用 SAE 找过特征、试过 Concept Bottleneck 或尝试把知识图谱塞进模型的，应该能感受到论文说的那种断裂感——这些方法各自在自己 pipeline 阶段里很努力，但合在一起讲不出一套完整的故事。

论文 7 月 29 日提交，PDF 和 HTML 已在 arXiv 公开，编号 2607.26825。全文 30 KB。如果做模型可解释性、对齐或下一代架构设计，这篇比某次模型发布更值得花时间。

从「设计概念」到真正做出能跑的新一代架构，中间还有很长的路。论文没给 roadmap，只画了一张地图。但对一个习惯了在训练完之后才去猜模型在想什么的领域来说，有人认真地说「换个顺序」，本身就是个值得讨论的信号。

相关链接

论文 arXiv 页面：https://arxiv.org/abs/2607.26825
论文 PDF：https://arxiv.org/pdf/2607.26825