AlloyDB接入TypeSafe AI Jev模型：用批处理把 50 条语义查询压进一次HTTP调用
Google AI Developers博客作者Gleb Otochkin展示了在AlloyDB for PostgreSQL中通过模型端点管理注册TypeSafe AI的Jev模型，并用数组批处理让 50 条布尔语义过滤在约 180 毫秒内完成；对比之下，同一模型非批处理约 5600 毫秒，默认模型非批处理约 19500 毫秒。
AI解读：这条新闻的核心不是AlloyDB又多接了一个大模型，而是它开始接一种不生成文字的模型。TypeSafe AI的Jev只返回布尔值、类别或分数，专门做高速逻辑判断。作者在AlloyDB里用原生ai.if和ai.analyze_sentiment调它，做商品是否适合雨天、评论情绪是正是负这类事。
对做实时语义过滤的人有用。以前要把数据搬去ETL或生成embedding，现在可以留在SQL查询里，边查边判断。文章给出的 30 千商品样例库上，50 条问题打包成一次HTTP往返，执行时间约 180 毫秒。
限制也清楚：必须开四个数据库参数，主实例要有出站公网IP，API key要放进Google Secret Manager，还要写PL/pgSQL转换函数把ai.* 的调用翻译成Jev的JSON格式。这套验证是作者在自家样例数据集上跑的，不是Google或TypeSafe AI的官方基准。
最值得记住的数字是批处理带来的差距：同一Jev模型，非批处理约 5600 毫秒，批处理约 180 毫秒；换成默认模型且不批处理则约 19500 毫秒。这是作者单次测试环境下的实测，不是跨环境承诺。
Google AI Developers博客作者Gleb Otochkin发布了一篇实操文章，介绍如何在AlloyDB for PostgreSQL中通过模型端点管理接入TypeSafe AI的Jev模型，并用PostgreSQL数组批处理把 50 条语义布尔查询合并成一次HTTP请求。
文章称，在 3 万条商品的样例电商数据集上，Jev模型配合批处理的查询执行时间稳定在约 180 毫秒；同一模型非批处理约 5600 毫秒，AlloyDB默认模型非批处理约 19500 毫秒。
Jev面向的是返回布尔值、类别或分数的结构化判断，而非生成对话文本。文章使用AlloyDB原生的ai.if和ai.analyze_sentiment函数调用该模型，并给出商品适雨性判断、评论情绪分类两个示例。
Jev在AlloyDB中的注册与转换层
文章给出完整接入步骤：先在AlloyDB集群开启四个数据库参数——google_ml_integration.enable_model_support、enable_ai_query_engine、enable_ai_function_acceleration、enable_cost_optimized_ai_functions，并确认主实例具有出站公网IP，否则访问Typesafe AI端点会超时。随后在typesafe.ai注册并生成API key，存入Google Cloud Secret Manager。
由于AlloyDB标准ai.* 函数的输入输出格式与TypeSafe AI的System One API不同，作者编写了四个PL/pgSQL转换函数。输入转换根据generation_config里是否带enum数组，分别构造Jev的choice或noul问题类型；输出转换把choice结果直接返回，把noul的概率分数按 0.50 阈值转成true或false。批处理版本则对应处理数组输入输出，相关函数收录在其同事Paul Ramsey的codelab中。
绑定操作通过google_ml.create_model完成，model_provider设为custom，model_type为llm，model_request_url指向https://api.typesafe.ai/v1/systemone，认证方式为secret_manager。
- 开启参数：enable_model_support、enable_ai_query_engine、enable_ai_function_acceleration、enable_cost_optimized_ai_functions
- 主实例需要出站公网IP，否则调用Typesafe AI端点会超时
- API key存入Google Cloud Secret Manager，并在create_model中指定为model_auth_id
- 输入转换按enum有无选择choice或noul，输出转换把noul概率以 0.50 为界转布尔
实测数据与批处理执行计划
文章先做单条测试：用ai.if判断“North Face Waterproof Gore-Tex Hiking Jacket（249 美元）”是否适合雨天户外，返回true；再用ai.analyze_sentiment判断一条关于缝线开裂和拉链卡住的评论，返回negative，两者均在毫秒级返回。
吞吐测试使用row_number() 窗口函数把 50 行商品划为一个batch_id，再用array_agg聚合商品名，调用ai.if一次传入 50 条prompt，最后用unnest展开结果。EXPLAIN ANALYZE显示GroupAggregate阶段把 50 条评估合并成一次网络载荷，耗时约 351 毫秒，整条查询实际执行时间约 369 毫秒。文章正文另称执行时间稳定在约 180 毫秒，并称批处理比非批处理快 30 倍以上。
文章称同样的数组批处理方法也适用于ai.analyze_sentiment，把多条用户评论作为参数一次性传入。作者总结时把提速归因于Jev返回结构化逻辑原语而非逐token生成文本，以及PostgreSQL优化器在调用模型前先聚合数据。
这些数字来自作者本人在样例数据集上的测试，文章未提供可复现的硬件配置、并发条件或多次运行的统计分布。
- 单条ai.if和ai.analyze_sentiment均毫秒级返回
- 50 条批处理查询在EXPLAIN ANALYZE中约 351 毫秒，整体实际约 369 毫秒
- 文章另称执行时间稳定在约 180 毫秒，非批处理Jev约 5600 毫秒，默认模型非批处理约 19500 毫秒
- 提速归因：Jev返回结构化原语而非逐token文本，加上数据库先聚合再调用模型