第9讲：AI 列：模型驱动派生数据学习笔记
发布于
来源：《第九讲 AI 列：模型驱动派生数据的自动维护》，视频约 16 分 40 秒。按课程中的五项赛题要求整理；示例用于理解语义，具体 SQL 完整语法与评测细则以最终题面为准。
1. AI 列解决什么问题
AI 数据处理已经涉及许多常见业务：识别评论语言，判断情感，提取标签，生成摘要，或者把文本转成向量进行检索。传统方式是“查出数据 → 调用模型 → 写回结果”，后续还需要应用自己处理失败重试、数据变化和索引更新。
AI 列把这套维护过程交给数据库。源数据是用户写入的内容，AI 列是模型根据源数据生成的派生结果。 例如一张评论表可以包含：
| 列 | 含义 | 谁负责维护 |
|---|---|---|
content | 评论原文 | 用户或业务应用 |
language | 语言分类，如 Chinese、English | 模型生成，数据库维护 |
tags | 质量、价格、易用性等标签 | 模型生成，数据库维护 |
summary | 评论摘要 | 模型生成，数据库维护 |
emb | 原文对应的向量 | Embedding 模型生成，数据库维护 |
这些列名是说明用的例子。假如 content 从中文改成英文，旧的语言标签、摘要和向量就可能不再适用，数据库必须识别依赖关系，使旧结果失效，再生成对应新原文的结果。
“一等数据”意味着 AI 结果能够参与查询、事务和索引，并在更新、删除、失败和重启后仍有明确的行为。它与普通计算结果的区别在于：模型调用可能慢、失败、乱序返回，还会产生费用。
这里要分清两个层面：模型负责生成内容，数据库负责可靠维护生成过程。数据库保证结果属于正确的数据版本、符合类型且按事务规则发布，并不等于保证模型的分类或摘要永远正确。
2. 基础用法：用 SQL 管理模型、列和重试
课程要求从模型注册到 AI 列维护都通过 SQL 表达，包括模型定义、DDL、DML 和重试四部分。DDL 管理表结构，DML 管理表里的行数据。
2.1 模型定义：逻辑名称与服务端点
可以把逻辑模型理解为数据库里给模型起的名字，服务端点则是实际发请求的位置。AI 列引用逻辑模型，数据库根据绑定信息确定 URL、服务商、认证信息和实际请求使用的模型名。
讲解提到 CREATE AI MODEL，并要求先覆盖两类模型：
- Embedding：把文本变成向量，用于语义检索。
- Completion：按提示生成文本或结构化内容，用于语言分类、摘要、标签等。
注册模型是让数据库知道“调用哪个服务、如何调用、预期得到什么结果”。
2.2 表结构：声明 AI 列及其依赖
需要支持创建表时定义 AI 列，也支持在已有表上增加、查看和删除 AI 列。查看能力还用于了解生成进度。
以 language 依赖 content 为例，定义不仅要说明列的类型，还要说明它调用哪个模型、引用哪些源列。数据库需要保存这种依赖关系，才能判断一次更新是否需要重新生成结果。
如果只修改与生成表达式无关的列，例如人工备注，就不应把它当作 content 变化来无谓重算。讲者还特别提到主键变化：结果需要归属于更新后的行，不能继续按旧主键回填。
2.3 行数据变化：什么时候生成，什么时候失效
| 操作 | 课程要求 | 直观例子 |
|---|---|---|
| 插入依赖数据 | 产生生成任务，完成后回填 AI 列 | 插入评论后自动识别语言 |
| 修改依赖列 | 旧结果失效，按新内容重新生成 | 原文换成英文后，旧中文标签不能继续代表它 |
| 修改无关列 | 区分依赖关系，避免无关更新触发模型计算 | 修改备注不应重算文本向量 |
| 删除行 | 迟到结果不能写回已删除的行 | 请求还在执行时删除评论，返回后不能把行“复活” |
| 主键变化 | 维护结果与更新后行的归属关系 | 主键从 1 改为 2，回填不能继续写到旧标识 |
“立即失效”需要放在事务语义下理解：与源数据变化一起维护，并遵守事务可见性，不能让未提交的修改破坏其他事务可见的已提交结果。
2.4 重试与刷新
讲解要求支持用 SQL 选择任意行重新生成，也支持只重试失败行。前者可用于模型升级后刷新结果，后者用于处理请求失败。讲解中提到了 RETRY AI COLUMN、RETRY FAILED AI COLUMN 及通过 WHERE 选择行的形式。
重试的是特定行、特定生成任务。若源数据已经变化，重新执行时必须结合当前有效版本判断，不能把一次重试当成向表里直接写入旧答案的许可。
3. 异步语义：尚未生成的结果如何查询
异步意味着写入源数据与拿到 AI 结果不是同一个时刻。原文可能已经提交，但模型仍在运行，也可能调用失败或结果已经过期。查询必须明确区分这些情况与可用结果。
| 查询方式 | 对未完成、失败或过期结果的处理 | 可以怎样理解 |
|---|---|---|
| 宽松模式（课件 OFF） | 按NULL 查询 | 允许读到源数据，但当前没有可用 AI 值 |
| 严格检查（课件 ON） | 引用列存在非 READY 行时立即报错 | 本次查询要求 AI 结果已经准备好 |
严格检查不是一直等待模型完成；课件给出的行为是报错。 宽松模式下的 NULL 也不能直接理解为模型判断“没有标签”，因为它可能来自尚未完成或失败，需要结合生成状态判断。
另一个要求是同一行的一组 AI 列整体发布。例如 language 和 summary 属于同一组，前者已完成、后者仍未完成时，不能先把半组新结果暴露给业务。组内结果准备好并通过校验后，才一起变为可见。
4. 事务与版本：网络返回成功还不等于数据生效
课程把模型调用抽象成可恢复的事务处理过程。外部 HTTP 调用可能重复，但最终可见结果必须满足 ACID，即原子性、一致性、隔离性和持久性。
| 属性 | 在 AI 列中的要求 |
|---|---|
| 原子性 | 源数据变化、旧结果失效、新任务建立保持一致；同组结果整体发布 |
| 一致性 | 只有类型合法、属于有效最新版本的结果才能可见并进入索引 |
| 隔离性 | 并发更新服从事务隔离；旧请求晚返回也不能覆盖新版本 |
| 持久性 | 已提交任务、状态和结果在服务重启后能够恢复 |
4.1 回滚：撤销源数据修改，也不能留下它的 AI 结果
课件的例子是：原文和语言结果原本都是中文，在事务中把原文更新成英文，随后执行 ROLLBACK。
回滚后，无论立刻查还是稍后查，结果都应仍对应中文。即使某个外部请求已经发出、稍后返回英文分类，也不能把这个被撤销的版本写回。
要点是：回滚保证的是数据库状态不被这次修改污染；已经发出的网络请求不一定能撤销，产生的调用费用也不一定能收回。
4.2 乱序返回：按源数据版本判断新旧
假设同一行先是中文版本 v1，随后改成英文版本 v2；两次模型请求分别为 R1、R2。
| 时间顺序 | 发生的事情 | 应有处理 |
|---|---|---|
| 1 | v1 中文发起 R1 | R1 与 v1 关联 |
| 2 | 原文更新到 v2，发起 R2 | v1 结果失效，新任务对应 v2 |
| 3 | R2 先返回 English | 若版本和类型校验通过，可以发布 v2 结果 |
| 4 | R1 后返回 Chinese | 已过期，必须丢弃，不能覆盖 English |
数据库要比较的是“这个答案对应哪一版源数据”，而不是“哪个 HTTP 请求最后回来”。这也是异步结果最容易出现的一类错误。
4.3 并发更新：行锁与提交顺序仍然有效
课件中，A 把同一行更新成英文但尚未提交；B 尝试把它更新成法文并被阻塞。A 提交后，B 才继续并提交。最终结果应该对应法文。
这个例子有两条顺序：数据库中的更新需要遵守事务隔离与提交顺序；外部请求的返回顺序则可能不同。后者不能推翻前者。A 的英文请求即使最后回来，也不能把已经生效的法文版本覆盖掉。
4.4 崩溃恢复：HTTP 200 不代表回填事务已经提交
课件把一次 AI 列生成过程分成 T1 和 T2 两个阶段。为便于理解，可以将 T1 看成源数据变化与任务建立的提交阶段，将 T2 看成结果校验、写回和发布的提交阶段；这是对课件流程的解释，不是指定必须采用的代码结构。
T1 提交 → 模型返回 HTTP 200 → T2 尚未提交 → 进程退出 → 重启恢复。
此时任务已经被接受，但 AI 结果还没有完成数据库提交。因此：
- 重启前未提交的结果对用户不可见。
- 已持久化的任务要重新进入执行，不能因为服务重启就丢失。
- 新的结果写入事务提交后，才发布结果；课件示例中，宽松查询的可见状态由
NULL变为English。
模型调用允许重复，与数据库结果只能正确发布并不矛盾。 题目关注的是恢复后没有漏任务、脏结果或旧版本覆盖，不能把“请求收到响应”直接当作“任务已完成”。
5. 费用优化：利用共享前缀，减少无效调用
课程把总费用拆为未命中缓存的输入、命中缓存的输入以及输出 Token 的费用。相同输入前缀命中模型服务缓存时，输入费用可能更低。
课件给出的例子是：任务 101、103、104 使用相同上下文，任务 102 使用另一份上下文。优化可以分三步：
- 识别共享上下文：通过内容指纹等方式找到使用同一份材料的请求。
- 把共享内容放在前面：如“System 指令与输出格式 → 产品手册 A → 当前问题”，让不同问题保留相同的前缀。
- 同前缀任务连续执行：例如按 101 → 103 → 104 → 102 调度，增加缓存复用机会；课件同时指出，等待超限必须轮转，不能让其他任务一直排不到。
讲者还提到减少重复请求。可以结合任务调度避免明显无效的调用，但优化不能破坏重试和恢复保证：少发请求不能以漏掉有效任务为代价。
课程说明评测会通过网关模拟断网、延迟、阻塞等情况，并按调用产生的费用进行评估，费用低得分高。
6. 索引一致性：查询不能绕过结果有效性检查
AI 列进入索引后，除了直接查表，还可以通过索引检索。如果表里的旧值已失效，但索引仍能找到它，用户就会看到互相矛盾的结果。因此，旧索引项立即失效，新结果校验完成后才重新参与查询。这指受影响的数据项，不是停用整个索引。
| 索引 | 典型 AI 列 | 课件强调的要求 |
|---|---|---|
| B-Tree | 语言、分类、评分 | 全表扫描与索引查询结果一致 |
| JSON 多值索引 | 标签、结构化提取 | 非法 JSON 不能进入索引 |
| 全文索引 | 摘要、长文本 | 失败或过期结果不能被搜索到 |
| VSAG HNSW 向量索引 | 文本向量 | 与 AI 列有效结果的发布和失效同步维护 |
例如，原文从“手机续航很好”改为“鞋子尺码偏小”后，旧向量已经不能代表新原文。即使旧向量还很容易被“手机续航”搜索命中，也不能把它当成当前有效结果返回；新向量生成、校验并发布后，才参与对应检索。这个例子用于理解课件的索引一致性要求。
把全讲连起来，一次 AI 列更新涉及的过程是：依赖数据变化 → 旧结果与旧索引项失效 → 建立可恢复任务 → 调用模型 → 检查类型和版本 → 同组结果提交发布 → 索引参与查询。 每一步都需要遵守事务可见性，失败后还要能够重试或恢复。
对照赛题学习时，可以用四个问题检查自己的理解：源数据改了旧答案是否立即失效；旧请求晚回来是否会覆盖新答案；服务重启是否会丢任务；走索引与直接查表是否保持一致。这些是根据课程整理的自查问题，不是官方测试用例清单。