Google 将 AlloyDB AI functions 推到 GA，同时引入了一种很实用的代理模型架构：先用 LLM 输出训练一个轻量本地模型，再把后续推理放在数据库内部执行。这个变化的重点不是“数据库也能聊 AI”，而是把一类高频、结构化、可近似的 LLM 判断，从外部 API 调用变成接近数据库速度的本地推理。
代理模型解决的不是所有 LLM 问题
传统做法里，应用或数据库函数每处理一行数据，都可能触发一次外部 LLM 调用。这个链路有几个明显成本：网络延迟、API 限流、token 费用、批处理吞吐受限，以及数据出库带来的治理压力。
AlloyDB 的代理模型思路更像“蒸馏”而不是“替代大模型”。系统先收集 LLM 对样本数据的输出，再训练一个更小的本地模型，让它在数据库内部完成后续推理。适合它的任务通常有这些特征：
- 输入是表里的结构化字段或短文本字段。
- 输出是分类、布尔判断、打分、路由这类稳定格式。
- 业务能接受近似模型，而不是每次都需要完整生成式推理。
- 查询量大，外部 LLM 调用的延迟和费用已经成为瓶颈。
来源摘要中特别提到，智能批处理带来 2,400 倍吞吐提升，代理模型预览中可达到每秒 100,000 行。但这里要读细：这些 benchmark 数字只适用于内部测试里的 ai.if，不能直接外推到所有 SQL、所有模型和所有业务数据。
为什么“数据库内推理”会改变系统设计
如果 LLM 调用发生在应用层，开发者往往需要设计队列、重试、缓存、并发控制和落库逻辑。推理进入数据库后，数据路径变短了：过滤、聚合、推理、写回可以在同一个查询或存储过程中完成。
这对几类场景很有吸引力：
- 欺诈、风控、审核等需要批量扫描历史数据的任务。
- 客服工单、销售线索、商品内容的自动分类。
- ETL 或 ELT 流水线中的智能标签生成。
- 原本用 LLM 做简单
if/else判断，但线上吞吐被外部调用拖慢的查询。
不过边界也很清楚。代理模型不是万能缓存。它依赖训练样本质量，也会继承 LLM 输出中的偏差。如果业务语义频繁变化，或者每次输入都需要复杂上下文推理，本地轻量模型可能很快过期。
可以这样实践：先用影子评估判断是否值得代理化
下面这个示例不是 AlloyDB 官方语法，而是一个可直接运行的本地评估脚手架。它模拟一个常见流程：用“昂贵 LLM 标注结果”作为训练标签，训练轻量模型，再批量处理数据库中的待分类文本。你可以把 SQLite 换成 PostgreSQL/AlloyDB，把 expensive_llm_label 换成真实 LLM 调用或历史标注表。
运行前需要安装依赖：
python -m pip install scikit-learn pandas
保存为 proxy_model_eval.py 后运行：
import sqlite3
import time
import pandas as pd
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import Pipeline
DB = ':memory:'
samples = [
('refund requested after damaged delivery', 1),
('invoice question from enterprise customer', 0),
('angry customer asks for chargeback', 1),
('how to change billing email', 0),
('package lost and wants refund immediately', 1),
('request for product documentation', 0),
]
# 假设 label=1 表示需要升级处理；真实系统里可来自 LLM 输出或人工审核。
conn = sqlite3.connect(DB)
conn.execute('create table tickets(id integer primary key, text varchar, label integer)')
conn.executemany('insert into tickets(text, label) values (?, ?)', samples)
train_df = pd.read_sql_query('select text, label from tickets', conn)
model = Pipeline([
('tfidf', TfidfVectorizer(ngram_range=(1, 2))),
('clf', LogisticRegression(max_iter=1000)),
])
model.fit(train_df['text'], train_df['label'])
# 模拟批量新数据。实际落地时，这批数据可以来自 AlloyDB 表扫描。
new_rows = pd.DataFrame({
'id': range(1, 10001),
'text': [
'customer wants refund for missing package' if i % 3 == 0
else 'customer asks how to update account settings'
for i in range(10000)
],
})
start = time.perf_counter()
new_rows['proxy_label'] = model.predict(new_rows['text'])
elapsed = time.perf_counter() - start
print(new_rows.head())
print(f'rows={len(new_rows)} elapsed={elapsed:.4f}s rows_per_second={len(new_rows)/elapsed:,.0f}')
这个脚手架的价值不是复现 AlloyDB 的内部性能数字，而是帮你回答两个上线前问题：
- 代理模型在你的数据上和原始 LLM 输出差多少？
- 当推理变成本地批处理后，吞吐、成本和延迟是否足以抵消模型维护成本？
在真实 AlloyDB 方案里，可以把评估流程拆成三张表：样本表、LLM 输出表、代理模型预测表。然后用 SQL 对齐准确率、召回率和分歧样本：
-- 假设 proxy_predictions 和 llm_labels 已经由各自流程写入。
-- 这段 SQL 用来找出代理模型与 LLM 输出不一致的样本，便于人工复核。
select
p.id,
p.predicted_label,
l.llm_label,
s.text
from proxy_predictions p
join llm_labels l on l.id = p.id
join source_samples s on s.id = p.id
where p.predicted_label <> l.llm_label
limit 100;
落地时看三条线：准确率、吞吐和治理
采用代理模型前，不要只盯着“每秒多少行”。更稳妥的检查清单是：
- 建一套离线评估集，覆盖高频样本和高风险边界样本。
- 保留原始 LLM 输出或人工标注，用来定期校准代理模型。
- 对低置信度样本回退到外部 LLM 或人工队列。
- 把 benchmark 限定在具体函数、具体表结构、具体并发条件下，不要把
ai.if的内部测试数字当成全局承诺。 - 监控数据漂移。业务文本、用户行为、欺诈模式变化后，代理模型需要重新训练。
AlloyDB 这次的方向很明确：不是让数据库替代所有 LLM，而是让数据库吃掉那些高频、重复、可学习的智能判断。对工程团队来说，最现实的切入点是先挑一个昂贵的 LLM 布尔判断或分类任务，用影子流量评估代理模型，再决定是否把它放进主查询路径。