企业官网建设流程全解析

1. 从“答非所问”到“心里有图”：为什么语言模型总在时空关系上翻车

先说一个我实测过的场景。你给模型一段话：“张三从书房走到厨房，把杯子放在餐桌上，然后去阳台收衣服，回来时发现杯子被李四挪到了茶几上。”然后问它：“张三回来时，杯子最初放的位置在哪个房间？”很多模型要么答“厨房”，要么答“茶几”，却忽略了一个关键事实——杯子最初放的位置是厨房里的餐桌，而不是最终所在的茶几。这就是典型的时空关系推理任务，看似简单，背后却牵扯到方位跟踪、事件排序、视角切换三层能力。

我接触这个方向，是从一次内部评测开始的。某项目组需要让助手类产品理解“上周你把车停在哪个停车场负二层”这类用户查询，结果发现市面上主流语言模型在带空间介词和时间锚点的问题上，准确率普遍不到六成。更麻烦的是，错误不是随机发生的，而是带有系统性偏差，比如模型倾向于“默认最后提到的位置就是最终位置”，或者“把两个地点之间的路径直接压缩成一次跳转”。这些偏差在单轮问答里还能忍受，一旦放到多轮对话或者文档级推理里，错误会被累积放大，最后给用户一个完全偏离事实的答案。

问题的根子，在于语言模型的建模方式。语言模型（Language Model）看到的是Token序列，它的注意力机制本质上是沿着时间轴单向“读”文本的。对于文本里描述的物理空间，模型并没有一个显式的“地图”去承载这些信息。它只能在Token之间建立相关性，用隐式的方式“猜”出一些空间关系。而时间是另一种麻烦：事件在文本里的出现顺序，有时候是叙述顺序，有时候是实际发生顺序，两者会倒置、会穿插，比如倒叙和插叙，模型如果没有显式的时间线建模，就会把“提到顺序”当成“发生顺序”。

所以，单纯加大模型参数量、堆更多数据，在这个任务上收益很有限。我见过不少团队给模型喂了几十万条带空间标注的语料，评测分数只涨了一两个点，还是过不了“穿房间”这种基础测试。真正有效的做法，是改变模型对时空信息的表征方式，让它从“记忆文本”变成“构建场景模型”。这篇文章想系统聊聊我在这条路上的实践：包括怎么构造训练数据、怎么设计推理链路、怎么选择评测集，以及那些踩过之后才明白的坑。

2. 先把任务拆清楚：时空关系推理到底在考什么能力

2.1 三个层次的推理任务划分

在动手提升模型表现之前，我先把任务做了一次分层。这个分层决定了后面所有的数据设计、模型改造和评测方式，值得先花点篇幅说清楚。

第一层是静态空间关系。问“杯子在餐桌的左边还是右边”，这类只需要提取文本中的方位词和参照物，模型做的是信息抽取加简单逻辑判断。这一层大多数模型已经做得不错，准确率能到八成以上，因为预训练语料里有大量类似场景的描述。

第二层是动态空间变化。问“张三从书房走到厨房之后，书房里还剩几个人”。这里需要模型跟踪实体的位置变更，记录“谁去了哪里”的状态更新。这一层就开始暴露问题了，模型经常会漏掉已经离开的实体，或者对“经过走廊”这类过渡性描述产生错误的位置绑定。我把这层叫做“状态跟踪”，它考察的是模型对文本事件的增量更新能力。

第三层是时间+空间的复合推理。问“张三在去阳台之前把杯子放在哪里”，或者“如果李四是在张三去阳台之后才挪动杯子的，那么张三回来时是否知道杯子被挪走了”。这一层需要同时维护时间线和空间状态，并且能基于时间点做回溯查询。这是目前模型表现最弱的一层，我自己的评测集上，最强的开源模型也只有不到四成的准确率。

把任务拆成这三层，最大的好处是能精准定位模型的短板。很多团队一上来就追求“大而全”的推理能力，结果评测分数上不去，也不知道该优化数据还是优化模型结构。我的建议是先跑一层诊断测试，确认模型具体在哪一层掉链子，再决定后续方案。

2.2 模型为什么总在“最后一刻”出错

拆完任务之后，我去分析了大量错误案例，发现模型在时空推理上的错误有明确的规律性。这里总结三类最常见的错误模式，对后续设计和排查非常有帮助。

第一类是最严重的信息丢失问题。模型在阅读长文本时，早期提到的空间信息会被后续信息“冲淡”。比如前文明确说“酒杯在高脚柜上”，中间隔了五六句描述室内陈设的句子，最后问“酒杯在哪”，模型倾向于回答最后一个提到的家具，而不是高脚柜。这说明注意力机制在处理长距离的空间锚定信息时，存在天然的衰减。

第二类是视角混淆问题。文本经常涉及多个人物的视野：张三看到的李四的位置，和李四实际所在的位置，可能是不同的。模型在推理时经常把叙述者的全知视角和角色的有限视角混在一起。比如“李四躲在门后，张三从门边走过没有看见他”，模型会被问到“张三知道李四在哪吗”，依然会回答“知道”。这种问题非常隐蔽，因为它不是事实错误，而是“背景知识”和“角色知识”的错误混用。

第三类是时间锚点漂移。文本里描述了一系列事件，但模型在进行推理时，会把“事件在文本中出现的顺序”当作“事件在实际时间中的顺序”。倒叙和插叙对这种错误影响极大。比如“电饭煲先跳闸，后来张三才想起自己忘了按煮饭键”，模型反而会认为“先忘记按按钮，之后跳闸”是正常顺序。

理解了这三类错误模式，就能明白为什么单纯加数据没用，因为错误不是知识缺失造成的，而是表征机制偏差。需要从位置编码、注意力方式、推理策略三个层面同时下手，才能对每一个错误模式做到真正有效的修正。

3. 位置编码改造：给模型一张“隐形地图”

3.1 用二维坐标扩展Transformer的位置信息

Transformer的位置编码原本是为序列建模设计的，它编码的是“Token在句子里的顺序”，而不是“实体在物理空间中的位置”。要让模型理解空间关系，第一步就是扩展位置编码的维度，从一维变成二维甚至三维。

我在一个模拟项目X里做过一个实验。给每个实体额外加上一个位置向量，这个向量的值来自实体的文本描述。实现方式是修改嵌入层（Embedding），把原本的Token Embedding和Positional Encoding之后，拼接一个Spatial Encoding，这个编码用一个简单的二维坐标系来表示实体的位置。坐标值的来源不复杂，直接用实体词和方位词的共现统计来估算，比如“书在桌子的左上角”这句话，“书”的坐标就偏向左上象限，“桌子”的坐标落在中心基准点。

代码层面，我在标准Transformer的Embedding层后面加了一个可学习的Spatial Embedding模块，输入是文本中所有实体词的Text Embedding均值，输出是每个实体的二维坐标预测值。这个模块不参与语言模型的原有损失计算，而是单独用一个MSE损失去约束，让预测坐标尽量接近从语料统计得到的“相对位置参考值”。

实测下来，二维位置编码对静态空间关系任务的提升最明显，准确率涨了大概十个百分点。动态空间变化任务的提升没那么直接，因为坐标是静态的，没有跟踪实体在文本事件中的移动。这个问题在后面引入了事件状态更新模块之后才解决。

3.2 事件状态更新：让模型学会“移动”实体

空间推理的另一个关键，是让模型具备“状态更新”能力。文本里每发生一个事件，比如“张三从客厅走进厨房”，模型的内部状态里就要把张三的位置从客厅移动到厨房。如果模型只是预测一个静态坐标，这个移动就完全丢失了。

我采用的方案是在模型结构中增加一个轻量的状态跟踪头（Status Tracker）。实现思路是：每读完一个事件句，模型先判断这个事件是否包含“移动”语义，比如有没有“走进、走出、搬到、移到”这类动词；如果包含，就找出主语实体和新的地点实体，然后更新主语实体的位置向量。位置向量的更新方式是把旧坐标和地点的坐标做线性插值，新权重由一个可学习的门控系数决定。

这个方法参考了记忆增强网络的设计思路，但做了简化，没有引入额外的外部记忆库，而是在Transformer的隐层状态里直接做向量更新。效果上，动态空间变化任务的准确率从不足五成提升到了七成以上。最直观的变化是，模型不再出现“把离开的人还留在原房间”的错误了。

不过，状态更新模块也引入了新的开销。每个事件句都要额外做一次移动语义判断和向量更新，推理速度会慢大概百分之十五。对于在线服务场景，这个开销可以接受，但如果是离线批量处理，需要做一下延迟优化。我当时用了一个小的技巧，把“移动”语义判断做成一个单独的轻量分类器，只在分类器输出高置信度时才触发向量更新，这样大部分事件都能跳过更新流程，速度损失降到了百分之五以内。

4. 训练策略：让模型从“背答案”变成“推过程”

4.1 构造带干扰项的合成数据

数据是时空推理提升的另一个支柱。我在这里踩过最深的坑，是直接用现成的空间问答数据集训练，结果模型学会了“找关键词”而不是“做推理”。因为那些数据集里，问题里出现的地点和答案里的地点高度重合，模型只需要做词汇匹配就能答对，根本没有建立真正的空间推理能力。

后来我改成了合成数据方案。写了一个数据生成器，按固定剧本随机生成室内场景和人物移动事件。剧本里会故意加三类干扰项：一是不相关实体的活动描述，比如“窗外有小鸟在叫”，这类干扰测试模型是否会捕捉无关信息；二是时间倒叙事件，比如先交代结果再交代原因，测试模型的时间线建模能力；三是挑战记忆极限的路径描述，比如“经过走廊、绕过玄关、穿过储物间才到达客厅”，测试模型对中间节点的保留能力。

合成数据的一个关键参数是事件密度。我试过每篇文本从5个事件逐步加到20个事件，模型的表现随着密度增加而下降，但不同改进措施的下降曲线斜率不同。位置编码改造让静态关系保持得比较好，但动态状态的衰减依旧明显，这说明模型的内存容量有限，事件越多，早期的状态更新越容易被覆盖。

针对这个问题，我在数据生成时引入了一个“记忆强化”策略，在训练数据里随机中断叙事，插入“根据当前掌握的信息，物品A现在在哪里”这类回顾问题，并要求模型只依据前文回答，不允许用后续信息。这个做法相当于给模型做“记忆抽查”，强制它维护一个可查询的状态表。经过这个数据增强之后，20个事件的场景准确率也能稳定在六成以上，比起初的四成好了很多。

4.2 链条分解推理取代直接回答

另一个有效的策略是让模型先输出推理过程，再给出答案。我之前用的是标准的思维链（Chain-of-Thought），但发现CoT在空间推理里效果一般，因为模型“心里没有图”的时候，即使让它“一步步想”，它也会编造出一套看似合理但实际错误的空间关系。

换成了“结构化推理链”后效果明显好转。所谓结构化，就是把推理过程拆成三个固定步骤：

1. 实体状态抽取：列出所有实体及其初始位置。
2. 事件增量更新：按时间顺序列举每个事件对实体位置的影响。
3. 目标查询定位：根据问题的时间点，回溯到那一刻的状态，得出答案。

这三步用代码实现的话，就是让模型在输出答案前，先输出一个JSON结构，中间步骤用JSON格式而不是自然语言。比如：

{ "step1_state": [ {"entity": "张三", "location": "书房", "time": "T0"}, {"entity": "杯子", "location": "餐桌", "time": "T0"} ], "step2_events": [ {"event": "张三走出书房", "time": "T1", "effect": "张三: 书房 -> 走廊"}, {"event": "张三进入厨房", "time": "T2", "effect": "张三: 走廊 -> 厨房"} ], "step3_query": {"time": "T3", "target": "杯子", "location": "餐桌"} }

为什么用JSON而不是自然语言？因为自然语言的推理链自由度太高，模型经常在中间步骤里引入不存在的实体或者自创的空间关系。JSON结构强制了信息槽位，模型必须在有限的字段里完成推理，这相当于给推理过程加了一个模板约束，大幅降低了自由度带来的错误。

实测效果非常显著，复杂时空推理任务的准确率从三成多提升到了六成以上。特别是带有时间倒叙场景，结构化推理链能强制模型按时间顺序重建事件流，而不是按文本出现顺序回答。这个方案的开销是解码时间变长了，因为模型要额外输出一个JSON结构，但换来的是准确率的大幅提升，我认为很值。

4.3 混合训练：在通用能力与时空推理之间找平衡

训练时空推理模型，还面临一个很实际的工程问题：如果只拿时空推理数据微调，模型的语言能力和通用知识会退化，表现为生成文本变得机械、表达能力下降、甚至出现重复词。如果拿通用数据和时空数据一起混着训练，又可能让时空推理信号被淹没。

我试过几种混合比例，最终固定在一个比较合理的方案上：通用语料和时空推理语料按4:1的比例混合。这个比例是基于我实验里的一组对比得出的，纯时空语料训练的模型，在空间任务上准确率最高，但通用能力下降明显；通用语料占比越高，通用能力保持越好，但空间任务掉点也快。4:1是一个相对合适的中间值，既能保持住推理能力的提升，又不至于让模型变得“偏科”。

具体的训练流程是两阶段。第一阶段用通用语料继续预训练，目的是不遗忘基础能力。第二阶段用混合语料微调，重点是教会模型理解结构化推理链的输出格式。两阶段的切换点是从loss值来判断的，第一阶段训练到验证集loss不再下降，再启动第二阶段。

有一点值得注意，训练时的格式标记很重要。我对比过加特殊标记（比如<REASON>、<ANSWER>）和不加标记两个版本，加了标记的模型在推理任务上效果好很多。原因可能是明确的标记帮助模型在内部区分“我现在在推理”和“我现在在回答”两种模式，减少模式混淆带来的错误。

5. 评测方法论：不能只看一个“平均分”

5.1 按推理层级分层评测

模型提升之后，评测方法也必须跟着变。如果只看整体准确率，你很难知道优化的方向是否正确，甚至可能会被平均分误导。比如整体准确率从五成涨到六成，但可能是静态空间关系提升了一截，动态推理反而没变甚至降了，只是被平均分掩盖了。

我的做法是把评测集按前面说的三个层级分层统计。每一层单独算准确率，再按层级的难度加权算一个综合分。权重方案是静态占百分之二十，动态占百分之三十，复合占百分之五十。这个权重不是拍脑袋定的，而是根据实际应用场景里各类问题的出现频率来定的，毕竟复杂推理才是最接近真实需求的部分。

每次训练迭代之后，我会跑一遍分层评测。如果发现某一层的指标下降了，即使综合分涨了，我也会慎重对待，不会直接采纳这个模型版本。分层评测还能暴露一个很微妙的过拟合信号：如果复合层指标涨幅异常高，但动态层没变化，我基本能判断模型是在背训练数据里的推理模式，而不是真正学会了推理。这时候需要增加合成数据的多样性，尤其是随机化事件顺序和干扰项的位置。

5.2 对抗性样本是试金石

除了分层评测，我还维护了一个小型的对抗性评测集。这个评测集是人工构造的，专门收集模型最容易被骗的场景。比如：

• 反常识空间关系：文本描述“小明把椅子放在桌子上面”，然后问“桌子在椅子上面吗”，很多模型会答“是”，因为它们从来没想过参照物反转。
• 多人视角冲突：前文说“A看到B进了房间”，后文说“C没有看见B”，问“C是否知道B在房间里”。
• 时间模糊表达：“过了一会儿”vs“三天后”对事件排序的影响，有些模型分不清这两个时间粒度的差异。

对抗性样本的价值在于它们能快速暴露模型的推理边界。有一次我在对抗集上发现模型所有带“否定词”的推理样本几乎全错，排查之后发现原因是训练数据里否定句的比例太低，模型根本没有见过“不在、没看见、从未”这类否定表达下的状态更新。后来在数据生成器里增加了否定句模板，这个问题就解决了。

如果没有对抗性评测，这种隐藏的短板可能很久都不会被发现，等到上线之后才在某类用户查询上集中爆发，那就比较麻烦了。

6. 一个完整的实践案例：空间问答系统从55%到82%

6.1 项目背景与初始方案

前面讲的都是方法论，这一节用一个完整案例串一下实操过程。某项目组要做一个内部文档分析工具，用户会问“这份报告里，第三季度那个产品发布会在哪个城市举办，当时谁负责物流协调”。这类问题需要模型从长文档里抽取时间、地点、人物三个要素，并建立关联。

初始模型用的是某通用大模型的纯提示词方案，零样本测试准确率只有55%左右。问题集中在三类：一是报告里时间倒叙描述事件时，模型定位季度错误；二是发布会地点被描述成“在北京的X酒店”，模型只记住了“北京”但丢失了“X酒店”这个更精确的信息；三是人物角色变换频繁，负责物流协调的人在发布会前一个月才接手，模型经常答成前一任负责人。

6.2 改造过程与效果对比

我按前面讲的思路做了三轮改造。

第一轮加位置编码调整。因为文档场景的空间信息相对稀疏，我没有用完整的二维坐标方案，而是给实体词拼接了“地点粒度标签”，比如场馆、城市、部门，让模型在表示层就区分不同粒度的空间实体。这一轮改造后，准确率从55%提升到64%，主要提升的是地点信息的精确维度，模型不再把“北京”和“X酒店”混为一谈。

第二轮引入结构化推理链。要求模型在回答前先输出一个JSON结构，内容包含“事件时间轴”和“角色状态表”。这一步是提升最明显的，准确率直接从64%跳到76%。模型先列出报告里所有时间节点和对应的地点信息，再定位“第三季度”的位置，最后追踪发布会前后的角色状态变换。

第三轮加了合成数据混合训练。项目组之前积累了几百条真实标注样本，但训练模型远远不够。我用合成方式把训练集扩充到一万条，模拟了不同风格的文档描述，包括倒叙、插叙、多地点并行等。这轮之后准确率到了82%，虽然涨幅没有第二轮大，但模型在对抗性样本上的表现变得稳定了，不再出现“报告里温度计的度数都能被当成答案”这种低级错误。

整个改造过程花了两周多时间，大部分工作量不在模型结构，而在数据管线搭建和评测体系完善上。模型结构改动其实很小，核心代码量不到两百行，这让我意识到，这个方向的瓶颈不在架构创新，而在如何把现有模型的表征能力、推理形式和训练信号更好地组合起来。

6.3 部署后的实际表现

上线后的实际效果比离线评测略低一点，稳定在78%到80%之间，主要原因是真实文档的噪声更大，比如表格里嵌着段落、图片里含着地址信息等。文档里一些信息是以表格形式存在的，但模型只有纯文本输入，表格结构被拍平成文本流之后，空间线索会更加淡薄，时间锚点也容易被间隔的文本冲散。

部署中还发现一个有意思的现象：用户的问题样态和评测集差异很大。评测集里大多数是“在哪、什么时候”这类直接查询，而真实用户经常问“对比一下两次发布会的地点差异”，这是更复杂的跨实体比较推理。后来我们调整了提示词模板，在回答这类问题时强制模型先输出两次发布会的独立JSON结构，然后再做比较，效果有所回升。

这个项目的经验让我更确信一件事：提升语言模型在时空关系推理上的表现，不是单点优化，而是一条完整的方法链。数据、表征、推理形式、评测缺一不可，每一步都要可度量、可反馈、可持续改进。

7. 避坑指南：这些弯路人人都可能绕进去

7.1 数据层面的常见错误

合成数据生成时，最容易犯的错误是“场景模板太固定”。如果每次生成的句子都长一个样，模型的泛化能力会非常差。比如你老是生成“张三从A走到B”这种句式，模型就只能在“走到”这个动词下理解空间移动，换成“张三穿过走廊来到阳台”就又不会了。解决方法是做句式多样化，准备至少二十种表达移动、停留、经过的句式模板，再配合随机的场景词表。

第二个数据层面的坑是“位置状态不闭环”。文本描述了实体从A移动到B，但没有交代B到哪去了，或者实体从此消失。模型很难在这种不完整信息下做推理，因为真实场景中有些实体确实会离开视野。但如果训练数据里这种情况太多，模型会养成“默认实体还在原地”的偏见。我在数据生成器里加了一个约束：每一个实体要么被明确指出离开，要么有路径描述，不能凭空消失。

第三个坑是“标注过于干净”。真实文本里各种表达误差很多，比如有人会把“左边”写成“靠窗那侧”，或者把时间说成“上周三”。如果训练数据里全是规范的方位词和时间词，模型遇到口语化表达就抓瞎。我在合成数据里加入了“模糊表达增强”，把一部分规范的方位描述替换成语义等价的模糊说法，让模型学会推断而不是只做词汇匹配。

7.2 训练和评测层面的坑

训练层面最常见的误区，是“把推理准确率当成唯一指标”。我在项目早期只盯着准确率，结果发现某个版本准确率高了但输出的JSON结构经常格式不合法，要么少字段要么多字段，下游解析器直接报错。后来我在训练损失里加了一个“格式完整性”约束，不合法格式的样本会被加重惩罚，格式错误率从15%降到了2%以下。

评测层面的坑是“评测集和训练集重叠太大”。合成数据如果不做去重，评测分数会虚高，尤其是一些固定模板的句子可能在训练集和评测集中重复出现。我的做法是评测集单独生成，绝不复用训练数据生成器的同一批随机种子，并且定期人工抽检评测样本确认模型不是靠背模板答对的。还有一个技巧是专门设计“未见地点组合”，评测集里放一些训练数据从未出现过的家具布局、楼层结构、人物关系，这样才能测出真正的推理泛化能力。

日常做实验还有一个很容易被忽视的坑：随机种子不固定导致实验对比不公平。模型训练本来就有随机性，如果不锁定随机种子，你都不知道某个指标的提升是策略带来的还是随机性带来的。我的习惯是每个配置跑三次，取平均值和方差来对比，同时优先选用“相对提升稳定”的策略。

7.3 关于推理链路长度的一些经验

前面提到用结构化推理链让模型先规划推理模板再回答，这个方法虽然效果好，但推理链长度需要控制。我有一次为了让模型“想得更全面”，把推理链拆成了七个步骤，结果模型越往后越容易出错，准确率反而下降。后来观察了一下，模型在长推理链末尾经常出现重复输出，可能是隐层状态在长时间解码中积累了误差。

经验是推理链长度控制在三到五步比较合适，覆盖“实体抽取、事件更新、目标定位”三个关键环节即可。更复杂的场景不要靠延长推理链解决，而是靠提升单步推理质量。如果模型连“当前实体在哪”都维护不好，给它更多步骤也只是在错误基础上越错越远。

8. 后续还可以尝试的方向

时空关系推理这个方向，我目前做的事情还只是基础版。推理链配合结构化JSON的方式已经验证有效，但离“真正理解空间”还有不少距离。后续有几个方向我认为值得探索。

第一是把视觉模型的场景理解能力引进来。语言模型处理空间信息之所以吃力，本质是因为它只有一个文本通道。如果能让模型在推理前先从视觉模型提取一个场景图描述，比如“房间里有沙发、茶几、电视柜，茶几在沙发前方”，再基于这个场景描述做推理，相当于让模型“看到”空间布局而不是“猜”空间布局。我在小范围实验里验证过这个思路，问题是多模态特征的接入方式和训练损失配比还需要优化，目前效果还不稳定。

第二是引入显式的内存机制。目前的Transformer用隐层状态存储所有信息，容量有限。我曾经尝试过把实体的位置状态显式保存在一个外部内存表里，每次事件更新就重写内存表，推理时从内存表读取。这个思路在手写实现时效果很好，但还没找到优雅地融入预训练模型的方式。后续可以考虑用工具调用（Function Calling）的形式，让模型通过调用一个“状态维护函数”来更新和查询实体位置，让模型不再自己硬记。

第三是时间推理的精细化。目前主要处理的是事件顺序和时间锚点，但真实世界的时间远比这个复杂，包括持续时间（“会议开了三个小时”）、频率（“每天早晚各一次”）、时间粒度切换（“下午3点”和“15:00”的等价关系）等。如果想要系统解决时空推理，时间维度的复杂度需要被更严肃地对待。

这些东西短期内可能没法完全落地，但我个人觉得方向是对的。时空推理是通往更接近人类理解能力的一条路，现在做的每一步积累，后面都会成为基础。

最后再分享一个实际使用中的小技巧。我在做这类推理任务时，给模型的系统提示词里固定加了一句话：“先检查文本中是否有倒叙或插叙现象，再开始回答。”就这么一句简单的话，就能让模型在大多数场景下避免把“提到顺序”当成“发生顺序”。这也说明，有时候推理能力的提升不只是模型的事，聪明的提示词设计也能触发模型已经具备但平时没有激活的能力。