火山 PostgreSQL Serverless × 飞书妙搭：把 AI 装进数据库，一句话唤醒数据智能

火山引擎Agent社区 2026-08-18 0 阅读8分钟

当你想用 AI 辅助分析业务的数据时，如何选取模型、使用模型并非最大困境，但是如何读取数据、搬运数据、进行模型分析和存储，会成为运维和管理数据的大麻烦。火山云数据库 PostgreSQL Serverless 版（简称：火山 PG Severless ） 把 AI Function（文本向量化、智能问答、语义检索、模型管控） 以函数形式装进数据库，业务可以像写 SQL 一样对数据进行加工；结合飞书妙搭 AI 原生 Agent 式平台能力，“帮我用 AI 分析一下表里的数据”的诉求可以从天级缩短至分钟级。

让业务数据会思考：火山 PostgreSQL Serverless 版 × 飞书妙搭

从存储引擎到智能引擎：数据库内的 AI 闭环

业务里最有价值的信息，往往藏在原始的数据里：履历、评论、工单、知识库都不是简单字段能描述清楚的。想要挖掘底层数据对业务的真正含义，引入 AI 的分析能力成为业务的刚需，然而想用大模型来分析底层数据，往往需要拼装 ETL + 外部模型网关 + 向量库存储 + 权限中台多个配置 —— 链路长、协同成本高、治理分散。把语义能力放到数据库里，本质上是把这四件事收敛到一次 SQL。

AI Function：由 rds_ai 插件提供的 6 项库内能力

AI Function 是火山云数据库 PostgreSQL Serverless 版 提供的一组语义处理函数，由 rds_ai 插件统一提供；配合原生 pgvector，可以覆盖从向量化 → 召回 → 重排 → 生成式问答的完整链路。

除了上述函数，rds_ai 还负责模型、API Key 和调用链路的统一治理：谁在调、调了什么、成本多少，都能在数据库一键式查询、按权限管控。

Serverless 让 AI 负载“用多少给多少”

需要 AI 来做分析的大部分业务场景，往往是典型的脉冲式负载：招聘季需要批量解析简历、大促期间快速分析评论、舆情波动时集中做风险识别；短期的高频负载后，业务又回到轻量状态。火山云数据库 PostgreSQL Serverless 版提供让数据库资源跟随业务弹性伸缩的能力 —— 高峰时自动提升算力，低峰时自动释放空闲资源。

AI Function 为业务解决“能不能在数据库内直接分析数据”，Serverless 则提供“如何用更低的资源来分析数据”。两者相合，才让“把 AI 放进数据库”这条路径实现真正的可持续。

传统链路 vs 库内 AI 闭环：由四段拼装收敛为一条 SQL 内的智能链路

下面我们就用两个真实业务场景，来讲述为什么要把 AI 放进 PostgreSQL、它在真实业务里怎么才能被用起来。

场景一：一句话找人才——从字段筛选到经验理解

飞书妙搭中的人才智能搜索：一句话表达复合诉求

HR 可以直接输入 “有带团队经验的 B 端产品负责人” 。这句话背后包含着产品方向、行业经验、管理能力、项目阶段四层语义，任何一层语义用字段筛选都难以完整表达。AI Function 能够把这类自然语言条件直接放到数据库侧处理：

• ai_embed 把履历、项目经历和搜索语句转成向量；
• ai_retrieve 相似召回，避免“语义相关但关键词不一致”的候选人被漏掉；
• ai_rank 对候选人做精细重排，把最贴合“带团队 + B 端 + 产品”的排前面；
• ai_query 把候选人的关键经历改写成人话推荐理由，例如“带过 8 人团队、从 0 到 1 做过企业软件、负责过高并发系统治理”。

整条链路的开发起点不是数据库表设计，而是一轮 Agent 对话：业务人员把目标讲清楚，飞书妙搭把目标翻译成应用结构、查询逻辑与 AI Function 调用。

接下来，我们来演示如何进行人才搜索：

1. Step 1：用户输入：“帮我把这些简历存起来。”

飞书妙搭的动作：梳理人才数据、筛选字段和部门权限

火山 PG Serverless 提供：底层数据的存储、查询与权限配置

INSERT INTO talents (name, dept, resume) 
VALUES ('王五', '研发部', '后端技术负责人；带 6 人研发团队；主导支付网关高并发改造与稳定性治理。'),

2. Step 2：用户输入“这些履历内容都参与匹配。”

飞书妙搭的动作：为履历建立并持续更新语义索引

火山 PG Serverless 提供：ai_embed 生成向量，pgvector 召回候选人

UPDATE public.talents
SET embedding = rds_ai.ai_embed(resume)::vector(1024);

3. Step 3：用户输入“我想搜索找一下相关人才。”

飞书妙搭的动作：生成搜索框，组合语义搜索和条件筛选

火山 PG Serverless 提供：ai_rank 优化排序，ai_query 生成匹配理由

SELECT chunk AS resume
FROM rds_ai.ai_retrieve(
    question => '有带团队经验的 B 端产品负责人',
    source_schema => 'public',
    source_table => 'talents',
    chunk_col => 'resume',
    vector_col => 'embedding'
);

4. Step 4：用户输入“用真实招聘需求先试一版。”

飞书妙搭的动作：基于生产快照拉起测试链路，验证结果与权限

火山 PG Serverless 提供：生产 / 测试数据分支隔离，互不干扰

场景二：评论自动洞察 —— 从人工抽样到持续预警

消费者评论洞察：情感、主题、严重度、来源渠道一屏可看

用户评论进入数据库之后，运营常见的做法是人工抽样打标 —— 但人工的模式，只能覆盖 5% 的评论，长尾问题看不到，等 BI 报表出来时舆情已经发酵。使用 AI Function 的 ai_query 函数，可以直接在库内完成有效性判断、情感识别、主题分类、严重度打分、摘要生成，把“某某手机充电时严重发热到烫到手指”这样一句评论，识别为“安全与伤害”主题、高严重度问题，自动进入风险看板与跟进任务。

ai_embed 与 pgvector 还会顺手做一件“表面简单但价值极高”的事 —— 把表述不同、指向同一问题的投诉聚成一类，让运营看到的是“200 条同类反馈”而非 200 条零散记录。

面向管理层的追问，可以直接交给 ai_retrieve + ai_rag：例如 “过去 7 天关于安全问题的负面评论主要在哪些渠道？” —— 检索、聚合、生成答案全部在库内完成，回答附带原始评论溯源，可点、可查、可核对，不再是黑盒结论。

接下来，我们来演示如何进行评论洞察：

1. Step 1：用户输入：“先把各平台评论整理进来。”

飞书妙搭的动作：解析业务诉求，AI 生成表结构 SQL，统一字段并去重

火山 PG Serverless 提供：快速拉起数据库服务，存储原始评论

INSERT INTO public.customer_comments (content) VALUES
('[评论ID=A-1001][渠道=电商平台A] 某某手机充电时严重发热，拿起来烫到了手指。')；

2. Step 2：用户输入：“帮我判断情感、主题和风险。”

飞书妙搭的动作：先用少量评论预览打标结果

火山 PG Serverless 提供：ai_query 生成标签、严重度和摘要

SELECT review,rds_ai.ai_query(
       '为下述评论进行分类，分成正向、负向、中立这三类', review) AS label
FROM reviews;

3. Step 3：用户输入：“把类似的问题聚成一类。”

飞书妙搭的动作：创建批量、增量和失败重试任务

火山 PG Serverless 提供：ai_embed + pgvector 聚合相似问题

UPDATE public.customer_comments
SET embedding = rds_ai.ai_embed(content)::vector(2048);

4. Step 4：用户输入：“随时问我最近的高风险问题。”

飞书妙搭的动作：把问答框放进看板与跟进列表

火山 PG Serverless 提供：ai_retrieve 召回相关评论，ai_rag 给出可溯源答案

SELECT rds_ai.ai_rag(
    question => '哪些渠道出现了手机充电发热或烫手问题？请总结风险，并引用评论ID。',
    source_schema => 'public',
    source_table => 'customer_comments',
    chunk_col => 'content',
    vector_col => 'embedding'
) AS answer;

从“能干活的数据库”到“能思考的数据底座”

把上面两个场景抽象出来，会发现一件事：数据库从“保存业务数据”的存储层，被升级成了“处理业务语义”的执行层。 应用侧不再需要为每一次语义分析拼装外部链路 —— 需求可以从一句 Agent 对话开始，页面、查询、自动化、权限、看板由飞书妙搭逐步搭建，底层的数据智能由火山云数据库 PostgreSQL Serverless 版全权负责。

从业务的角度来看，价值主要有三点：

• 更短的交付路径 —— 应用开发从天/月级压缩到分钟/小时级；
• 更清晰的治理边界 —— 模型、密钥、调用、权限集中在数据库层可查可控；
• 更强的能力复用 —— AI 就像 SQL 一样，可以被不同业务反复调用。

感兴趣的同学可以上手试：直接使用飞书妙搭平台，与 Agent 聊一段自己的业务——找一个候选人、看一批用户评论、答一个业务问题都行。最快十几分钟，就能看到“AI 直接在库里跑”是什么样。