Google 将 AlloyDB AI functions 推到 GA，并引入了一种值得关注的 proxy model 架构：先用 LLM 的输出训练一个轻量本地模型，再把后续推理放在数据库内部执行。它瞄准的不是“让数据库变成通用大模型”，而是把某些高频、结构稳定、可被近似学习的 LLM 判断，从外部 API 调用变成数据库速度的本地计算。
这件事重要，因为很多企业里的 LLM 成本和延迟并不来自单次对话，而来自批量数据处理：给几百万行工单分类、判断评论是否需要升级、给交易记录打风险标签。如果每一行都发一次外部 LLM 请求，吞吐、费用、限流、数据边界都会很快变成瓶颈。
proxy model 解决的不是所有 AI 问题
从摘要看，AlloyDB 的思路是用 LLM 先生成训练信号，再训练一个轻量本地模型承担后续查询。这个模式更像“蒸馏一个任务专用判断器”，而不是在数据库里塞进一个完整 LLM。
适合它的任务通常有几个特征：
- 输入结构相对稳定，例如一段评论、一个工单标题、一组结构化字段。
- 输出空间有限，例如分类、布尔判断、标签、优先级。
- 业务可以接受近似模型的误差，并能用抽样回归来监控质量。
- 查询量大到足以抵消训练、验证和治理成本。
不适合的场景也很明确：长文本生成、开放式推理、多轮对话、需要最新上下文的复杂判断。这些仍然更像 LLM API 或专门推理服务的工作。
为什么“在数据库里跑”会改变成本模型
外部 LLM 调用的成本不只是一笔 API 账单。真实系统里还会叠加网络往返、批处理编排、重试、限流、隐私审查、结果回写等环节。proxy model 把稳定任务移到数据库内部后，路径会短很多：数据不必离开查询环境，推理可以贴近 SQL 执行计划，结果也能直接参与过滤、聚合和更新。
摘要里提到 Smart batching 带来 2,400x 吞吐提升，preview 中 proxy model 可达到每秒 100,000 行。不过这里要特别小心：这些 benchmark 数字只适用于内部测试里的 ai.if，不能直接外推到所有函数、所有模型和所有业务表。工程上更稳妥的读法是：这个方向展示了数据库内批量推理的潜力，但上线前仍要用自己的数据、自己的查询形态测量。
可以这样实践：把 LLM 判断变成可替换的数据库函数
下面是一个可改造的 PostgreSQL/AlloyDB 风格示例。它不假设你的环境已经有 GA 函数的具体签名，而是演示一种落地方式：先把 AI 判断封装成 SQL 函数调用点，方便以后在“外部 LLM 批处理”和“数据库内 proxy model”之间切换。
运行前需要修改：
- 把
ai_if_proxy(...)替换成你环境中实际可用的 AlloyDB AI 函数或包装函数。 - 如果当前还没有 proxy model，可以先让该函数调用外部服务或返回规则结果，用同一张表验证数据流。
-- demo.sql
-- psql "$DATABASE_URL" -f demo.sql
CREATE TABLE IF NOT EXISTS support_ticket (
id BIGSERIAL PRIMARY KEY,
subject TEXT NOT NULL,
body TEXT NOT NULL,
customer_tier TEXT NOT NULL DEFAULT 'standard',
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
needs_escalation BOOLEAN
);
INSERT INTO support_ticket (subject, body, customer_tier) VALUES
('Payment failed twice', 'Enterprise customer cannot renew subscription after two attempts.', 'enterprise'),
('How to change avatar?', 'User asks where the profile picture setting is located.', 'standard'),
('Data export missing rows', 'Customer says exported compliance report is incomplete.', 'enterprise')
ON CONFLICT DO NOTHING;
-- 假设：ai_if_proxy 是你封装的数据库内 AI 判断函数。
-- 未来可以把函数实现从外部 LLM 调用替换为 AlloyDB proxy model 推理。
UPDATE support_ticket
SET needs_escalation = ai_if_proxy(
'Does this ticket require human escalation? Answer true or false.',
jsonb_build_object(
'subject', subject,
'body', body,
'customer_tier', customer_tier
)
)
WHERE needs_escalation IS NULL;
SELECT id, subject, customer_tier, needs_escalation
FROM support_ticket
ORDER BY id;
如果你还没有实际的 AI 函数，可以先用一个本地占位函数跑通流程。这个函数只是规则模拟，不代表 AlloyDB 的真实能力：
CREATE OR REPLACE FUNCTION ai_if_proxy(prompt TEXT, payload JSONB)
RETURNS BOOLEAN
LANGUAGE sql
IMMUTABLE
AS $$
SELECT
payload->>'customer_tier' = 'enterprise'
AND (
payload->>'body' ILIKE '%failed%'
OR payload->>'body' ILIKE '%missing%'
OR payload->>'body' ILIKE '%compliance%'
);
$$;
这个封装有一个实际好处：应用层不需要知道背后是 LLM API、规则函数，还是数据库内 proxy model。你可以用同样的 SQL 接口做 A/B 测试、回滚和质量评估。
上线前要测三件事
proxy model 的诱惑是吞吐和延迟，但生产系统不能只看速度。建议至少建立三类检查。
第一，质量回归。固定一批人工标注样本，比较 LLM 原始输出、proxy model 输出和人工标签。不要只看 overall accuracy，还要看高风险类别的 false negative。
第二，漂移监控。工单、评论、交易文本会变。每周或每月抽样，把 proxy model 的判断重新交给 LLM 或人工复核，观察分布是否偏移。
第三，边界策略。对于低置信度、高金额、高权限、高合规风险的记录，不要盲目交给轻量模型一次性决定。可以让 proxy model 做预筛，再把少量疑难样本送回 LLM 或人工队列。
采用建议
AlloyDB 的 proxy model 架构适合从“行级、批量、重复”的 AI 判断开始试点。不要一上来替换复杂生成任务；先挑一个输出明确、已有历史数据、能量化质量的场景，例如升级判断、评论分类、欺诈预筛或内容标签。
一个务实的上线清单是：
- 把 AI 调用封装成数据库函数或稳定 SQL 接口。
- 保留原始 LLM 样本和人工标签，作为回归集。
- 用自己的表规模和查询条件压测，不直接套用 benchmark 数字。
- 为高风险结果设计兜底路径。
- 记录每次模型训练、验证集、阈值和上线时间。
这类能力的价值不在于“数据库也能 AI”，而在于把昂贵、慢、难批量化的 LLM 判断，压缩成可查询、可批处理、可治理的数据基础设施的一部分。