问“最近10场”和问“本赛季”为什么完全不是一个问题？半岛体育AI如何理解体育查询中的时间

示例队甲过去5场几乎每场都用4-3-3，可整个赛季里出场次数最多的阵型却是4-2-3-1。有人问“这支球队最常用什么阵型”，两个答案都没有错，错的是系统如果只给出其中一个，还不告诉用户它默认了哪个时间范围。体育查询里的时间从来不是一个可有可无的修饰语，它决定了参与计算的到底是哪些行。半岛体育AI在处理体育问题时，把时间条件当作和实体、指标同等重要的一等公民来解析，本文就沿着“最近10场”和“本赛季”这两个看似相近的说法，看看时间在一条体育查询里到底意味着什么。

同一个“最近”，背后是三种完全不同的坐标系

中文里描述时间的说法非常灵活，但落到数据库里，几乎都可以归入三类坐标。

• 相对窗口：以“现在”或某个基准日期为起点往回数，例如最近10场、最近5轮、最近30天。它的特点是窗口的起止日期会随着数据更新而滑动。
• 日历区间：起止日期是固定的，例如本赛季、上个月、2024年秋季。它对应的是一个封闭的日期范围，只要范围定下来，结果就不会随时间漂移。
• 事件锚点：以某个事件为界，例如换帅以后、某次伤停复出以后、转会之后。事件本身的日期需要先从另一张表里查出来，才能得到真正的时间范围。

这三类坐标的区别，直接决定了SQL的写法。相对窗口通常要先排序再截取，日历区间是简单的范围过滤，事件锚点则需要先做一次关联查询。把它们都当成“加个日期条件”，是体育查询里最常见的简化，也是许多错误的源头。

对“球员A最近10场”和“球员A本赛季”这两个问题来说，前者的窗口大小固定为10行，后者的行数取决于赛季进行到哪里；前者的平均值天然聚焦于近期波动，后者则更平滑，也更容易被赛季初的表现拖住。两者之间没有谁更好的说法，只有谁更适合回答用户真正想问的那件事。如果用户是想判断近期状态，前者更贴切；如果想评价整体贡献，后者更稳妥。系统在解析时如果不知道用户想问哪一种，就应当追问，而不是替用户选一个。

相对窗口：从“最近N场”到滚动窗口

“最近10场”是体育问答里出现频率最高的时间说法。实现上有两个层次：单次的“最近10场汇总”，以及在一条时间线上反复计算的“滚动窗口”。前者的写法在自然语言体育查询一文中已经出现过，先按日期倒序再截取。这里看后者，也就是每一场比赛都对应一个“截至这场的最近5场均值”，用来画出状态曲线。

示例表 player_game_stats 中每人每场一行，字段包括 player_id、game_id、game_date、minutes、points。下面是一个滚动5场平均得分的查询示例，数据均为演示用。

SELECT game_date,
       points,
       AVG(points) OVER (
           PARTITION BY player_id
           ORDER BY game_date
           ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
       ) AS rolling_avg_5,
       COUNT(*) OVER (
           PARTITION BY player_id
           ORDER BY game_date
           ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
       ) AS window_size
FROM player_game_stats
WHERE player_id = 'P_000123'
  AND played_flag = 1
ORDER BY game_date;

这段SQL里最容易被忽视的是最后那个 window_size 字段。赛季最初的几场比赛，窗口里其实不足5行，滚动平均值只是“前几场的平均”，如果不标出来，曲线的头几个点会给人一种“状态稳定”的错觉。系统在绘图时，应当把窗口不足的点用不同样式标出，或者干脆只从窗口填满之后开始画。

另一个细节是 ROWS 与 RANGE 的区别。ROWS 按行数计窗口，RANGE 按值的范围计窗口。“最近5场”对应的是 ROWS；“最近30天”则应当使用按日期的范围，而不是按行数，因为球员在30天里可能只打了3场，也可能打了9场。同一个“滚动窗口”的说法，在这两种用法里给出的结果和含义都不同，语言模型如果在生成SQL时不区分它们，得到的就是一份形式完整但含义错位的查询。

还有一层：滚动窗口默认的排序依据是 game_date，但同一天可能有两场比赛（例如补赛），此时仅按日期排序是不稳定的。稳妥的做法是引入第二排序键，例如 game_id 或开球时间，使得窗口顺序在任何时候都是确定的。这类细节不出现在用户的问题里，却决定了系统给出的数字是否可复现。

日历区间：赛季并不总是一个日历年

“本赛季”听起来比“最近10场”简单，因为它是固定区间。但在数据层面，赛季本身就是一个需要维护的实体，而不是一个可以从日期推出来的简单函数。原因有几个。

1. 赛季常常跨年。一个赛季可能从某年秋天开始，到次年春夏结束。如果用“年份”来判断赛季，会把同一赛季的比赛切成两半。
2. 赛季内有阶段。常规赛、季后赛、杯赛、季前赛的比赛可能存放在同一张表里，用 game_type 区分。用户说“本赛季”时，默认是否包含季后赛，需要有明确的规则并告知用户。
3. 赛季的起止日期需要显式存储。推荐的做法是建一张 seasons 表，记录 season_id、start_date、end_date，games 表通过 season 字段关联，而不是每次靠日期推断。

有了这张表，“本赛季”的解析就变成一次查表：找到包含数据截止日期的那条赛季记录，取出起止日期和 season_id，再作为过滤条件传给后面的查询。“上个赛季”则是相邻的前一条记录。这样的设计也让“某个月”“上半赛季”这类说法有了明确的落点，例如“上半赛季”可以被定义为赛季起点到赛季中点，而中点如何定义（按日期还是按场次），同样需要事先规定，并出现在答案的口径说明里。

在公开研究里，篮球技术统计的本体知识图谱工作就把赛季、阶段、轮次、日期范围显式建模成本体的一部分，目的是让语义过滤有稳定的落点。这个思路和上面的 seasons 表并不冲突，只是把它放在了图结构里表达。这里只是借来说明一件事：时间在体育数据中值得单独建模，而不是被当成字符串顺手处理。关于时间在图里如何保存，可以参考球员转会以后旧数据怎么办。

事件锚点：“换帅以后”需要先查出那一天

“示例队乙换帅以后，谁的进攻角色变化最大？”这类问题的时间条件不是任何一个日期，而是一个事件。系统必须先回答：换帅是哪一天？然后才能把“以后”翻译成过滤条件。示例中的教练任期表可以这样设计。

系统先在这张表中找到示例队乙最近一次主帅变更，得到 start_date，然后把它作为“以后”的起点。对应的SQL是一个先关联再过滤的写法。

SELECT s.player_id,
       AVG(s.shots)  AS avg_shots,
       AVG(s.touches_in_box) AS avg_box_touches
FROM player_game_stats s
JOIN games g ON g.game_id = s.game_id
JOIN coach_tenures c
  ON c.team_id = s.team_id
 AND g.game_date >= c.start_date
 AND (c.end_date IS NULL OR g.game_date <= c.end_date)
WHERE c.team_id = 'T_002'
  AND c.coach_id = 'C_017'
GROUP BY s.player_id;

这里有三个典型问题。第一，临时代理算不算换帅，不同人的答案不同，系统需要把角色字段作为可选的过滤条件，并在答案中写明采用了哪个定义。第二，任期起点当天的比赛，究竟归新帅还是旧帅，需要一个稳定的规则，比如以比赛日期大于等于起点为准。第三，“换帅以后”只有对比才有意义，通常要同时算出换帅之前同样场次的数据，否则得到的只是“新帅期间的数字”，没法说变化。所以这类问题在半岛体育的设计里，往往要拆成“前后两个窗口的对比查询”，并且要求两个窗口的比赛数量都足够、场次的构成也大致可比。

伤停以后的处理类似：先从伤病记录里找到复出日期，再向后取一段窗口。区别在于伤病数据往往更不完整，很多来源只记录“缺席”，而不记录原因，此时系统只能说“某日之后的比赛”，而不能说“伤愈之后”。这属于数据本身对问题的限制，答案里应当如实说明。

时间条件有歧义时，系统应该怎么办

很多时候用户的时间说法并不明确。半岛体育在设计时把常见的歧义整理成几类，并为每一类规定了默认处理与是否追问的策略。下面是一张示意表，说明的是设计思路，而非某个已上线产品的规则。

这张表体现的是一个原则：默认值可以有，但默认值必须被看见。如果一次追问就能消除较大的不确定性，就追问；如果差别有限，就采用默认值并把它写进答案。追问不是系统无能的表现，而是对用户负责的表现。这部分在产品层面如何呈现，可以参考半岛体育App为什么有时会要求你补充条件。

一个完整的例子：同一支球队，两个时间范围，两个答案

用开头的场景把上面的部分串起来。用户输入：“示例队甲最常用什么阵型？过去5场呢？”这里的球队与数字均为虚构示例。

系统首先注意到这句话里有两个时间条件：一个是没有说出口的默认范围，一个是明确的“过去5场”。它把问题拆成两条子查询，分别带上不同的窗口参数：第一条使用当前赛季的日期区间，从 seasons 表里取出起止日期；第二条使用相对窗口，取示例队甲截至数据更新日的最近5场比赛。两条查询读取的都是阵型时间片数据，而不是球队标签，统计的是各阵型在场时长的合计，而不是出现次数。

两个结果并不矛盾，它们描述的是同一支球队在不同时间尺度上的习惯。如果系统只回答“最常用4-2-3-1”，用户会错过一个重要信息，近期的战术已经发生变化；如果只回答“最近常用4-3-3”，又会掩盖赛季整体的使用情况。更好的答案是把两者并列，并写明各自的比赛场次与统计口径。

这个流程里可能出错的地方也很具体：赛季表里没有维护当前赛季的起止日期，会导致“本赛季”落空；数据滞后一场，会让“最近5场”少算了一场最新的比赛；阵型时间片缺失，则会退化成用单一标签回答。系统对这三种情况都应当给出明确的提示，而不是悄悄降级。

三个更隐蔽的时间陷阱

陷阱一：比赛日期与数据入库日期不是一回事

数据库里可能同时有 game_date 和 updated_at 两个时间。按前者排序才是“最近的比赛”，按后者排序得到的是“最近被更新过的记录”。如果数据源曾经修订过历史数据，后者会把很久以前的比赛推到前面。这类错误在结果上很不显眼，但只要系统生成SQL时选错了排序字段，就会发生。

陷阱二：时区和跨日比赛

一场在当地晚上进行的比赛，换算成另一个时区可能落在第二天。“昨天的比赛”在不同时区下可能指向不同的场次。稳妥的做法是在数据里保存比赛的当地日期和统一的UTC时间两个字段，查询时明确使用哪一个，并在需要时向用户说明。

陷阱三：样本量随时间条件变小

时间条件收得越紧，样本越少。“过去5场的常用阵型”只有5个数据点，“赛季初三场比赛的命中率”更是一个随机性很强的数字。系统应当把样本量作为答案的一部分，样本太小时明确提示“这只是较小样本，结论不宜外推”。这与其说是技术问题，不如说是统计上的基本诚实。阵型数据还有一层额外的复杂性：同一场比赛内阵型也会变化，需要按时间片来存放，这在“某球队最常用阵型”到底怎么查中有专门的讨论。

时间条件写清楚，问题才算问完整

回到开头的两个说法：“最近10场”和“本赛季”。它们的区别不是长短，而是坐标系不同：一个随数据滑动，一个由赛季表固定；一个回答“近况”，一个回答“整体”；一个更容易受个别比赛影响，一个更容易被早期表现稀释。任何一个可靠的体育查询系统，都应当在回答之前先把这个选择做出来，并让用户看见。

半岛体育AI在这件事上的设计取向可以归纳为三条：第一，把时间条件从自然语言里显式抽取出来，落成结构化的参数，而不是留给语言模型自由发挥；第二，把赛季、任期这类时间实体存在专门的表里，而不是每次靠日期推断；第三，把最终采用的窗口、起止日期和样本量都写进答案。做到这三点之后，“最近”这个词才不再是一个模糊的形容词，而是一个可以被检查、被复现、被质疑的查询条件。体育数据的可靠性，很大程度上就藏在这些看起来琐碎的时间细节里。