大语言模型与预测

大语言模型最初是为自然语言任务（natural language tasks）训练的，但预测任务与语言建模（language modeling）共享一个重要结构：都在已有序列的基础上推断下一个元素。语言模型预测下一个 token，时间序列模型预测下一个观测值。这个相似性让大语言模型可以参与预测，但它只是机会，不是质量保证。关于 LLM 成功原因及其对预测领域影响的讨论，也提醒我们要把生成能力放回可评价的预测流程中 Makridakis et al., 2023。

传统统计模型通常追求用较少参数（parameters）凝练规律，例如趋势、季节性、自相关和误差结构。大语言模型走的是另一条路：用大规模数据和大量参数学习丰富的上下文表示（contextual representation），再根据任务提示生成结果。未来的预测系统很可能同时使用这两类能力：统计模型提供可检验结构，LLM 提供上下文理解、非结构化信息（unstructured information）处理和自然语言交互。

因此，本章讨论的重点不是“大模型是否会替代所有预测模型”，而是三个更实际的问题：数值时间序列如何进入 LLM？LLM 在预测流程中可以扮演什么角色？怎样避免把一次看似合理的回答误当成可靠预测？

学习目标¶

完成本章后，你应该能够：

• 解释大语言模型如何把文本、图像、视频和时间序列切分为 token。

• 说明 embedding 为什么不是简单编号，而是对上下文含义的向量表示。

• 区分 LLM 作为预测器、特征提取器、助手和模型接口的不同用法。

• 解释 prompt 与 API 在预测流程中的角色差异。

• 识别大语言模型用于预测时的幻觉、隐私、成本、格式和验证风险。

大语言模型的基本能力¶

大语言模型是在大规模数据上训练的深度学习模型，能够理解和生成自然语言，也能处理代码、表格说明、图像、视频和多轮对话。它可以总结、翻译、问答、写代码、生成报告，并在一定程度上进行推理。与传统任务专用模型不同，大语言模型更像一个通用接口：同一个模型可以通过不同提示词适配不同任务。

这种能力对预测很有吸引力，因为真实预测任务很少只有一列数字。销量预测可能伴随促销方案、新闻舆情、客户反馈和渠道调整；金融预测可能伴随公告、会议纪要、研报和监管政策；旅游预测可能伴随航班、签证、搜索和地缘政治信号。LLM 可以把这些非结构化信息整理成事件、假设、解释或结构化特征，再交给预测流程使用。

我们把大语言模型比作“带有联想能力的超级输入法”。早期输入法可以根据前几个字补全词语，或者按规则纠正拼写；大模型则在海量文本、代码和多模态数据中学习上下文关系，能够根据一段输入继续生成解释、步骤、表格或代码。这个比喻有助于理解它的底层任务：给定上下文，预测后续最可能出现的 token。

大模型也可以帮助做分类、数据标注、文献梳理、代码生成和初步咨询。它可能给出传统专家没有想到的联想，也可能生成不存在的论文、错误引用或貌似专业的解释。把它用于预测时，必须把“生成了合理文字”和“给出了可靠预测”分开看。

也要注意，LLM 给出的是基于已学知识和当前上下文的概率性判断，而不是确定事实。它可能提供传统专家没有想到的视角，也可能生成听起来合理但没有数据支撑的解释。学习 LLM 预测的第一原则，就是把它放在可检验流程里，而不是把它当成自动正确的专家。

统计模型与大模型的两种哲学¶

传统统计模型通常强调浓缩和凝练。一个回归模型（regression model）、ARIMA 模型（Autoregressive Integrated Moving Average, ARIMA）或状态空间模型（State Space Model, SSM），用有限参数刻画趋势、季节性、自相关和误差结构。模型越简洁、假设越清楚，解释和检验通常越容易。

大模型走的是另一条路线。它不追求用五个或十个参数解释一个小问题，而是用大规模数据和大量参数吸收语言、图像、代码、知识和上下文模式。传统统计训练常问“这个参数是否显著”；大模型训练更关心“这么多参数能否学到可迁移的表示”。两条路线逻辑不同，并不互相替代。

当领域机制清楚、数据较少、解释要求高时，统计模型和专家判断仍然重要。当场景陌生、文本和图像信息丰富、专家成本高，或者需要把复杂资料整理成结构化输入时，LLM 可以提供新的工具。预测系统的现实选择通常不是“统计模型或大模型”，而是把两者放进同一个可评估流程。

Token 与 Embedding¶

LLM 不直接处理人类看到的完整句子，而是先把输入切分成 token。Token 可以是一个字、一个词、词的一部分，也可以是图像中的图像块（patch）、视频中的帧或片段。对于时间序列，token 可以是一个数值、一个变化方向、一个分桶标签，或者一段时间窗口。

Token 本身只是最小输入单元。模型真正使用的是 embedding，也就是把 token 映射成向量（vector）。Embedding 的作用不是记录这个词在字典里的编号，而是用一串数值表示它在上下文中的含义。比如 powerful 和 strong 的含义接近，它们的向量距离可能较小；但二者仍有细微差别，模型可以在大量语料中学习这种差别。

图像和视频也能用类似方式进入模型。一张图像可以切成许多 patch，每个 patch 成为一个 token；视频可以先拆成帧或片段，再映射成 token。无论输入是文字、图片、视频还是数值序列，模型真正处理的都是 token 及其向量表示。

时间序列进入 LLM 时也需要类似处理。假设一个销售序列是 [100, 120, 90]，至少有几种表示方式：

这些表示没有绝对优劣。原始数值保留精度，但模型未必理解业务含义；分桶和差分损失部分信息，却能突出趋势和变化；学习型 embedding 更灵活，但解释性较弱。选择哪一种，取决于数据频率、数值范围、预测目标和后续模型。

茅台价格例子可以帮助理解 embedding 的价值。1940 单独出现时只是一个数字；如果告诉模型这是某一天京东上茅台酒的价格，再给出过去价格、节日位置、去年同期、上周价格和市场背景，这个数字就有了上下文。它可能意味着“比去年同期低很多”“临近节日出现小幅波动”“本周处在相对低位”。Embedding 的价值就在这里：它把数字放回场景，把单点数值转化成带有历史和业务含义的表示。

另一个直观例子是收入数字。出租车司机说“今天挣了 300 元”，这个数字本身不足以判断好坏；如果同时知道今天堵车、换电、空驶、平台派单不顺，300 元就带有完全不同的含义。数值 embedding 的目标也是如此：不仅表示“是多少”，还表示“在当前上下文中意味着什么”。

但 embedding 不是魔法。一个向量如果捕捉的是与预测目标无关的信息，或者把节日、价格、竞争对手、时间位置和空间关系混在一起却没有学到真正有效的结构，就不一定改善预测。早期的 TF-IDF（Term Frequency-Inverse Document Frequency, TF-IDF）也可以看作一种文本向量化；现代 embedding 的进步在于能从更丰富的数据和上下文中学习表示，但它仍然需要与目标变量、预测步长和评价指标匹配。

从词频到 GPT¶

自然语言处理的发展说明了为什么 Transformer 会成为预测课程的关键工具。早期处理文本时，可以先列出关键词，再统计每个词在文档中出现多少次，形成词频矩阵。TF-IDF 在词频基础上进一步惩罚过于常见的词，让更有区分度的词获得更高权重。这些方法直观、便宜、可解释，但它们主要停留在词面层面，很难理解词序、上下文和跨语言语义。

Word2Vec 代表了下一步：把词映射到稠密向量空间，使语义相近的词在向量空间中更接近。这里需要特别说明，Word2Vec 的经典结构主要是 CBOW（Continuous Bag-of-Words, CBOW）和 Skip-gram，而不是通常意义上的 CNN（Convolutional Neural Network, CNN）。它的贡献不是完成了全部语言理解，而是把文本从稀疏词频表转成了可计算、可比较的 embedding。

BERT（Bidirectional Encoder Representations from Transformers, BERT）则把 Transformer 编码器（Transformer encoder）引入文本理解。它不是给一个词固定向量，而是根据上下文生成带语境的表示。同一个词出现在不同句子中，embedding 可以不同。GPT（Generative Pre-trained Transformer, GPT）系列进一步把 Transformer 用于生成任务：给定前文，预测后续 token，并在大规模数据和参数上学习更通用的文本生成能力。Transformer 的自注意力结构（self-attention mechanism）是这一路线的关键技术基础 Vaswani et al., 2023，入门时也可以把 LLM 看作由 token、embedding、注意力和生成头组合起来的系统 Alammar & Grootendorst, 2024。

这条路径和时间序列预测直接相关。时间序列也可以从原始数值、差分、分桶标签或局部窗口转成 embedding；一旦变成模型可读的序列表示，就可以用注意力机制学习哪些历史片段和模式对未来更重要。因此，LLM 与时间序列基座模型并不是两个完全分离的话题，它们共享“把输入 token 化、embedding 化，再用 Transformer 学上下文”的基本路线。

为什么 LLM 可以做时间序列预测¶

时间序列预测和语言建模都依赖上下文。语言中的上下文是前面的词和句子；时间序列中的上下文是过去观测值、外生变量和事件。只要能把时间序列转化为模型可读的序列形式，LLM 就有机会学习其中的模式。

这种“可读”可以来自零样本提示（zero-shot prompting），也可以来自少量示例。零样本时，我们只告诉模型任务和历史数据；少样本提示（few-shot prompting）时，我们再给它几个输入-输出样例，让它模仿预测格式或推理步骤。可以用代码助手类比这一点：模型不一定真正证明了牛顿法的数学性质，但它可以根据示例和上下文生成可运行的近似流程。时间序列预测也类似，prompt 中的数据表、历史窗口、差分和业务说明都会被转成 token 和 embedding，成为模型生成下一段输出的上下文。

LLM 与时间序列预测结合通常有四条路径：

1. 直接预测：把历史数据写入 prompt，让模型输出未来值。

2. 特征提取：用 LLM 从新闻、报告、会议纪要或评论中提取事件变量，再交给时间序列模型。

3. 表示学习：把数值片段映射为 embedding，让模型学习趋势、季节、异常和局部形状。

4. 混合框架：让 LLM 连接统计模型、专用时间序列模型和业务规则，形成可解释的预测工作流。

直接预测最容易上手，也最容易误用。把 CSV 上传到聊天框，要求模型预测未来五期，模型通常能给出一个看起来合理的结果。但这个结果可能只是语言模型根据上下文生成的文本，并没有经过滚动验证、基准比较或业务损失评估。更稳健的做法是把 LLM 放在完整流程中，让它辅助表示、提取、解释和自动化，而不是单独承担所有预测责任。

还要区分两种“AI 预测”。一种是模型真正使用数值 embedding、上下文表示或时间序列基座模型能力来生成预测；另一种只是识别了数据格式，然后在背后调用 ARIMA、ETS 或其他传统包。后者仍然有工程价值，但它更像自动化编排或工具调用，不应被误认为大模型自己理解了时间序列机制。判断一个系统是否可靠，仍然要看它的输入、模型、输出和评估证据。

Prompt 与 API¶

Prompt 是给模型的任务说明和上下文，决定模型应该看到什么、完成什么、怎样输出。API 是调用模型的接口，使这个过程可以被程序重复执行、记录和评估。

在预测任务中，prompt 至少应说明：

• 目标变量是什么；

• 历史数据是什么格式；

• 时间频率是什么；

• 预测步长是多少；

• 是否需要只输出 JSON；

• 是否需要给出预测区间或解释；

• 不允许编造不存在的数据。

聊天框上传文件适合探索，但不适合稳定生产。它依赖人工操作，输入格式和输出格式很难完全固定，也不容易批量评估。API 的价值在于把模型能力嵌入工作流：程序可以构造同样格式的请求，接收同样结构的输出，解析成表格，再和真实未来数据比较。

一个概念性的 LLM 预测流程可以写成：

1. 整理历史序列，明确时间频率和预测步长。

2. 把历史数据、任务说明和输出约束写入 prompt。

3. 要求模型返回严格结构化结果，例如 JSON。

4. 解析输出，检查行数、日期、数值类型和量级。

5. 用留出集或滚动窗口评价误差。

6. 与简单基准、统计模型或专用时间序列模型比较。

Prompt 不是装饰，它定义了模型能看到的信息和必须遵守的输出约束。API 也不是预测质量的保证，它只是让模型能力进入可复现流程。真正决定质量的，仍然是数据、表示、验证、基准和决策后果。

LLM 的角色¶

LLM 用于预测时不只有一种用法。更准确地说，它可以在预测系统中扮演不同角色：

• 直接预测器：根据历史数值和上下文输出未来值，适合教学演示和低成本原型。

• 特征提取器：从文本、公告、新闻、政策或客服记录中抽取事件、情绪、风险和约束。

• 解释助手：把异常、预测假设和业务背景翻译成可沟通的语言。

• 代码与流程助手：生成清洗、画图、调用 API、解析 JSON 和评估误差的辅助代码。

• 模型接口：帮助用户用自然语言调用统计模型、专用时间序列模型或时间序列基座模型。

在多源数据和复杂业务语境中，LLM 的价值往往不是“直接预测一个数”，而是把预测任务组织得更清楚，把文本信息转化为模型或决策可以使用的结构化信息。对于关键业务，LLM 直接给出的数值应被视为候选预测，而不是最终答案。

组合预测也给了一个有用类比。没有一个模型在所有场景都最好，不同模型可能在不同数据、不同步长和不同损失函数下各有优势。LLM 可以作为其中一个专家，也可以帮助组织多个专家的输出；但最终仍要根据验证表现分配信任，而不是因为某个模型更大就自动相信它。

局限与风险¶

LLM 预测的风险可以分成几类：

这些风险并不意味着不能使用 LLM，而是说明 LLM 预测必须有约束。语言模型预测下一个 token，时间序列模型预测未来观测；二者都依赖上下文，但数值预测必须回到时间序列验证、输出解析和基准比较，才能判断是否可靠。

成本和部署方式也需要进入决策。云端 API 使用方便，但涉及费用、速率限制和数据外发；本地部署能降低隐私风险，但需要硬件、运维和模型压缩能力。预测系统不是只比较精度，还要比较投入、产出、隐私、延迟和可持续维护成本。

本地大模型与隐私¶

个人 AI 算力盒子的意义在于提醒我们：大模型不一定只能放在云端。随着小型 AI 计算设备、共享内存架构和开源模型发展，小团队、实验室、医院或家庭可能在本地运行专门模型。这样做的核心价值不是炫耀硬件，而是让敏感数据留在本地：病人数据、学生数据、企业销售数据、家庭健康数据和个人行为记录，都不必默认上传到外部平台。

本地模型尤其适合细分领域。很多场景并不需要一个知道全世界所有知识的通用模型，而是需要一个熟悉本团队、本行业或本人历史数据的小模型。一个二十人的团队可以把内部文档、实验记录和领域数据放在本地微调；一个家庭也可以把长期健康、生活和行为数据留在自己的设备中，让模型提供个性化提醒。对预测来说，这意味着“模型能力”要和“数据归属”一起讨论。

本地部署（local deployment）也有代价。用户要管理硬件、模型文件、内存、能耗、依赖版本和远程访问。传统 GPU 的显存（Video RAM, VRAM）可能限制模型大小；共享内存（unified memory）设备可以缓解这一点，但仍要考虑量化（quantization）、精度、推理（inference）速度和并发使用。云端 API 与本地模型不是谁彻底替代谁，而是两种不同的部署选择：前者轻便，后者更可控。

模型蒸馏会进一步把这个问题连接到部署形态。未来很多 AI 能力可能不再以“云端大模型聊天框”的形式出现，而是嵌入手机、手表、企业内网或专用设备中。要做到这一点，通常需要把大模型压缩、迁移或蒸馏成小模型，让它只保留当前用户或当前业务真正需要的能力。这样，本地部署不只是硬件问题，也是一套从 Teacher Model 到 Student Model 的模型工程问题。

一个实用判断¶

当你考虑用 LLM 做预测时，先问六个问题：

1. 它是在直接预测数值，还是在辅助提取信息？

2. 输入数据是否清楚说明了目标、频率、历史窗口和预测步长？

3. 输出能否被程序稳定解析和校验？

4. 是否与简单基准或专用时间序列模型比较过？

5. 是否经过留出集或滚动窗口验证？

6. 成本、隐私和延迟是否符合业务要求？

如果这些问题答不上来，就不要把 LLM 输出直接用于决策。它可以作为探索工具、解释工具或辅助工具，但还不是可靠的预测系统。

练习¶

1. 将一个月度销量序列分别表示为原始数值、分桶标签和差分符号，比较三种表示各自保留和损失了什么信息。

2. 解释为什么 1940 单独作为数字意义有限，而“某日期的茅台价格 1940 元”可以成为预测上下文。

3. 写一个不调用 API 的 prompt，要求 LLM 对月度销量序列只输出 JSON，并说明必须包含哪些字段。

4. 比较聊天框上传 CSV 和 API 批量调用在可复现性、成本、隐私和评估上的差异。

5. 设计一个实验，比较 LLM 直接预测、季节性 naive 和一个统计模型在 12 期留出集上的表现。

6. 找一个业务场景，列出使用云端 LLM 做预测时可能出现的幻觉、隐私和成本风险。

参考文献¶