当你想用 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_retrieveai_rag例如“过去 7 天关于安全问题的负面评论主要在哪些渠道”—— 检索、聚合、生成答案全部在库内完成回答附带原始评论溯源可点、可查、可核对不再是黑盒结论。接下来我们来演示如何进行评论洞察1. Step 1用户输入“先把各平台评论整理进来。”飞书妙搭的动作解析业务诉求AI 生成表结构 SQL统一字段并去重火山 PG Serverless 提供快速拉起数据库服务存储原始评论INSERT INTO public.customer_comments (content) VALUES ([评论IDA-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_embedpgvector聚合相似问题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 直接在库里跑”是什么样。
当你想用 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_retrieveai_rag例如“过去 7 天关于安全问题的负面评论主要在哪些渠道”—— 检索、聚合、生成答案全部在库内完成回答附带原始评论溯源可点、可查、可核对不再是黑盒结论。接下来我们来演示如何进行评论洞察1. Step 1用户输入“先把各平台评论整理进来。”飞书妙搭的动作解析业务诉求AI 生成表结构 SQL统一字段并去重火山 PG Serverless 提供快速拉起数据库服务存储原始评论INSERT INTO public.customer_comments (content) VALUES ([评论IDA-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_embedpgvector聚合相似问题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 直接在库里跑”是什么样。
