企业官网建设流程全解析

1. 项目概述：当文本分类遇上云原生向量数据库

最近在做一个内容审核相关的项目，需要快速对海量用户生成的短文本（比如评论、帖子标题）进行多标签分类。传统的方案要么是写一堆复杂的规则引擎，维护起来头大；要么是调用外部AI服务，延迟和成本都让人有点心疼。正好团队在用的Hologres最近上线了AI Function功能，号称能直接用SQL调用内置的模型做推理，这让我来了兴趣。毕竟，对于数据开发和分析师来说，SQL是看家本领，如果能用几句SELECT就把文本分类给做了，那开发和迭代效率岂不是直接起飞？

Hologres本身是阿里云推出的一款实时交互式分析引擎，和PostgreSQL高度兼容，最近其向量计算能力特别火。而这个AI Function，简单理解，就是它把一些常见的AI模型（比如文本向量化、文本生成、分类等）做成了内置的SQL函数。你不需要关心模型怎么部署、服务怎么拉起，只需要像调用SUM()或COUNT()一样，在查询语句里写上这个函数，它就能返回推理结果。这次实战的核心，就是利用hg_ai_text_embedding和hg_ai_complete这类函数，完成一个端到端的文本分类流水线，并且会深入到提示词（Prompt）工程和KV-Cache调优这些直接影响效果和成本的细节。

听起来很美好，但真用起来会发现，从“能用”到“好用”之间有道鸿沟。比如，怎么设计Prompt才能让大语言模型（LLM）准确理解你的分类体系？直接让模型输出“科技”、“体育”这类标签，它会不会胡言乱语？更实际的问题是，当你要对成千上万条文本进行批量分类时，推理速度慢、成本高怎么办？这就是KV-Cache调优要解决的问题。我会把这次从零开始摸索，包括踩过的坑、总结的技巧，通过具体的SQL示例完整地走一遍。目标很明确：让你看完之后，能直接在你的Hologres环境里复现一个高效的文本分类方案。

2. 核心思路：为什么选择SQL+AI Function方案？

在深入代码之前，我们得先盘清楚，为什么这个方案值得一试。面对文本分类任务，我们通常有几种选择：1）使用传统的机器学习库（如scikit-learn）自训练模型；2）调用云厂商提供的现成NLP API；3）自行部署开源模型（如BERT）提供HTTP服务；4）使用Hologres AI Function。

第一种方案灵活但门槛高，需要特征工程、训练、评估、部署一整套流程，周期长。第二种方案最简单，但按调用次数计费，对于海量数据，成本是线性增长的，且数据需要出到公网，有安全和延迟顾虑。第三种方案折中，但涉及资源管理、服务运维、负载均衡等，对很多数据团队来说是额外的负担。

而Hologres AI Function方案的核心优势在于“原位计算”和“开箱即用”。所谓原位计算，就是数据和计算都在Hologres内部完成。你的文本数据本来就存在Hologres表里，现在直接在同一引擎内进行模型推理，避免了数据在不同系统间迁移带来的网络开销、序列化反序列化成本，这是性能上的先天优势。开箱即用，意味着你无需成为MLOps专家，省去了模型部署、服务监控、扩缩容等一系列繁琐工作，Hologres已经帮你把模型以函数的形式准备好了。

具体到文本分类，我们主要会用到两个核心函数：

1. hg_ai_text_embedding: 将文本转换为高维向量。这是很多AI任务的基础，也可以用于基于向量相似度的分类（例如，计算文本向量与各类别代表向量之间的余弦相似度）。
2. hg_ai_complete: 直接与大语言模型（如通义千问、ChatGLM等）对话，通过设计Prompt，让模型根据你的指令输出分类结果。这是本次实战的重点。

选择hg_ai_complete进行文本分类，本质上是利用了LLM强大的指令理解和零样本/少样本学习能力。你不需要提供训练数据，只需要用自然语言清晰地告诉模型分类规则，它就能给出判断。这对于分类规则复杂、类别经常变动的场景（如舆情情感细分、投诉工单归类）尤其友好。

那么，整个流程的蓝图就清晰了：我们将数据存储在Hologres的普通表里，通过SQL调用AI Function，将模型推理结果直接写入另一张结果表，或者与原始表关联查询。全程无需切换工具，一条SQL链路贯穿数据存储、处理和产出，极大地简化了架构。

3. 环境准备与数据基础

理论说得再多，不如动手跑一条SQL。首先，你需要一个开通了AI Function功能的Hologres实例。目前这个功能可能在特定地域或版本中提供，建议先在阿里云控制台查看或咨询一下。确保你的账号有相应的权限。

接下来，我们准备一下测试数据。假设我们有一个user_comments表，存储了用户的评论信息，现在需要对这些评论进行情感倾向（正面/负面/中性）和主题（产品功能、售后服务、价格、其他）的双重分类。

-- 创建测试表 CREATE TABLE IF NOT EXISTS user_comments ( comment_id BIGINT PRIMARY KEY, user_id BIGINT, comment_text TEXT, created_time TIMESTAMP ); -- 插入一些示例数据 INSERT INTO user_comments VALUES (1, 1001, '这款手机的拍照功能太强了，夜景模式简直无敌，就是电池有点不够用。', '2023-10-01 10:00:00'), (2, 1002, '客服响应太慢了，等了半天都没人理，体验很差。', '2023-10-01 11:00:00'), (3, 1003, '价格有点高，不过材质和做工确实对得起这个价位，可以考虑。', '2023-10-01 12:00:00'), (4, 1004, '系统更新后比以前流畅多了，赞一个！', '2023-10-01 13:00:00'), (5, 1005, '快递包装破损，里面的商品也有轻微划痕，心情不好。', '2023-10-01 14:00:00');

数据准备好了，只是一个简单的文本字段。接下来，最关键的一步来了：如何设计给AI的“指令”，也就是Prompt。

4. 提示词设计：让AI准确理解你的分类意图

直接对模型说“给这个文本分类”，它大概率会懵。Prompt设计是决定分类准确率的“方向盘”。我们的目标是将模糊的分类需求，转化为LLM能精确执行的清晰指令。设计Prompt时，我总结了一个“CRISP”原则：

• C (Clear): 清晰。明确任务是什么。
• R (Role): 角色。给模型赋予一个角色，比如“你是一个专业的文本分析助手”。
• I (Instruction): 指令。具体要做什么，步骤是什么。
• S (Structure): 结构化输出。规定好输出的格式，最好是JSON、XML或固定的关键词，便于后续程序化解析。
• P (Positive/Negative Examples): 正负例。提供少量例子，进行少样本学习（Few-Shot Learning），效果提升显著。

让我们基于这个原则，为我们的双分类任务设计Prompt。假设我们要求模型以JSON格式输出情感（sentiment）和主题（topic）。

初版Prompt（效果一般）：

请分析以下用户评论的情感倾向和主要讨论主题。 评论：{comment_text}

这个Prompt太模糊了。“情感倾向”具体指什么？三分类还是五分类？“主题”的范围是什么？模型可能会自由发挥，输出“情感是积极的，主题是手机”这种不规范的答案，无法解析。

优化版Prompt（遵循CRISP原则）：

你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析： 1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。 2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。 输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"} 现在，请分析以下评论： 评论：{comment_text}

这个Prompt的改进点在于：

1. 角色明确：“电商平台的产品评论分析专家”，让模型进入专业场景。
2. 指令分步：用“1. 2.”列出了具体步骤，逻辑清晰。
3. 选项封闭：情感和主题都给出了明确的封闭选项，限制了模型的输出空间，避免了胡言乱语。
4. 输出结构化：强制要求JSON格式，并给出了示例，极大方便了后续用SQL的JSON函数（如json_extract_path_text）直接提取字段。
5. 少样本示例：虽然这里没有在Prompt里写例子，但我们可以通过后续的hg_ai_complete函数参数，以“系统消息”或“上下文消息”的方式提供少量示例，效果更好。

在Hologres中，我们将这个优化后的Prompt模板作为字符串，在SQL中动态拼接评论内容。

注意：实际使用中，如果分类类别很多，可以把类别列表单独定义为一个变量或从配置表中读取，避免Prompt过长。同时，对于“其他”类，可以追加指令：“如果无法归入上述任何主题，则选择其他，并在JSON中增加一个reason字段简要说明原因。”这样能收集到模型不确定的案例，用于后续优化类别体系。

5. 核心实战：用一条SQL完成文本分类

有了精心设计的Prompt，我们就可以祭出hg_ai_complete函数了。这个函数的基本调用形式如下：

SELECT hg_ai_complete( 'qwen-max', -- 模型名称，例如 qwen-max, qwen-plus, chatglm3-6b等 CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"}\n\n', '现在，请分析以下评论：\n评论：', c.comment_text), '{}'::jsonb -- 可选参数，可用于设置temperature, max_tokens等 ) as ai_response, c.* FROM user_comments c;

执行这段SQL，ai_response字段就会得到模型返回的完整文本，例如：{"sentiment": "正面", "topic": "产品功能"}。

但我们的目标是把结果结构化存储，方便后续分析。这就需要用到PostgreSQL/Hologres强大的JSON处理能力：

-- 创建结果表 CREATE TABLE IF NOT EXISTS comment_analysis ( comment_id BIGINT PRIMARY KEY, original_text TEXT, sentiment VARCHAR(10), topic VARCHAR(20), ai_raw_response TEXT, analysis_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 执行分类并将结果结构化插入 INSERT INTO comment_analysis (comment_id, original_text, sentiment, topic, ai_raw_response) SELECT c.comment_id, c.comment_text, json_extract_path_text( hg_ai_complete( 'qwen-max', CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"}\n\n', '现在，请分析以下评论：\n评论：', c.comment_text), '{"temperature": 0.1, "max_tokens": 500}'::jsonb -- 控制生成参数 ), 'sentiment' ) as sentiment, json_extract_path_text( hg_ai_complete( 'qwen-max', CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"}\n\n', '现在，请分析以下评论：\n评论：', c.comment_text), '{"temperature": 0.1, "max_tokens": 500}'::jsonb ), 'topic' ) as topic, hg_ai_complete( 'qwen-max', CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"}\n\n', '现在，请分析以下评论：\n评论：', c.comment_text), '{"temperature": 0.1, "max_tokens": 500}'::jsonb ) as ai_raw_response FROM user_comments c; -- 查询结果 SELECT * FROM comment_analysis;

这里有个严重的性能问题！细看上面的SQL，我们对同一条评论c.comment_text调用了三次hg_ai_complete函数，这意味着同一段文本会被发送到AI模型推理三次，产生了三倍的成本和耗时。这在生产环境是不可接受的。

正确的做法是只调用一次模型，然后解析其输出。但json_extract_path_text需要在一个已经包含了完整JSON的列上操作。我们可以通过子查询或者CTE（公共表表达式）来优化：

-- 方法一：使用子查询 INSERT INTO comment_analysis (comment_id, original_text, sentiment, topic, ai_raw_response) SELECT sub.comment_id, sub.original_text, json_extract_path_text(sub.ai_raw_response, 'sentiment') as sentiment, json_extract_path_text(sub.ai_raw_response, 'topic') as topic, sub.ai_raw_response FROM ( SELECT c.comment_id, c.comment_text as original_text, hg_ai_complete( 'qwen-max', CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"}\n\n', '现在，请分析以下评论：\n评论：', c.comment_text), '{"temperature": 0.1, "max_tokens": 500}'::jsonb ) as ai_raw_response FROM user_comments c ) sub; -- 方法二：使用CTE (WITH子句)，更清晰 WITH classified_comments AS ( SELECT c.comment_id, c.comment_text as original_text, hg_ai_complete( 'qwen-max', CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象，包含两个键：`sentiment`和`topic`。例如：{"sentiment": "正面", "topic": "产品功能"}\n\n', '现在，请分析以下评论：\n评论：', c.comment_text), '{"temperature": 0.1, "max_tokens": 500}'::jsonb ) as ai_raw_response FROM user_comments c ) INSERT INTO comment_analysis (comment_id, original_text, sentiment, topic, ai_raw_response) SELECT comment_id, original_text, json_extract_path_text(ai_raw_response, 'sentiment'), json_extract_path_text(ai_raw_response, 'topic'), ai_raw_response FROM classified_comments;

这样，每条评论只调用一次AI函数，获取完整的JSON响应，然后在应用层（这里就是SQL本身）进行字段提取，效率最高。这就是“全程SQL搞定”的精髓：用SQL处理数据，也用SQL处理AI返回的复杂结构。

6. 性能瓶颈与KV-Cache调优实战

当处理几条、几十条数据时，上面的方法很完美。但设想一下，如果你要对一张百万行评论表进行全量分类，直接SELECT ... FROM huge_table调用AI函数，会遇到两个核心问题：速度慢和成本高。速度慢是因为LLM的推理是计算密集型操作，串行处理百万数据不可行。成本高则是因为大多数AI服务按Token消耗量计费。

这时，就需要引入两个重要的优化策略：批量处理和KV-Cache调优。

1. 批量处理 (Batching)Hologres的AI Function通常支持在单次调用中传入一个文本数组，模型会并行处理这些输入。这比逐条调用效率高得多，因为减少了网络往返开销和模型本身的上下文准备开销。

-- 假设我们每次处理100条评论 WITH batch_data AS ( SELECT array_agg(comment_id) as id_array, array_agg(comment_text) as text_array FROM user_comments -- 可以加WHERE条件进行分批，例如 WHERE comment_id BETWEEN 1 AND 100 GROUP BY (comment_id - 1) / 100 -- 每100条一个批次 ), batch_result AS ( SELECT b.id_array, b.text_array, hg_ai_complete( 'qwen-max', CONCAT('你是一个电商平台的产品评论分析专家。请严格遵循以下步骤对用户评论进行分析：\n', '1. 判断评论的情感倾向：仅限["正面", "负面", "中性"]三个选项。\n', '2. 判断评论讨论的核心主题：仅限["产品功能", "售后服务", "价格", "其他"]四个选项。\n\n', '输出要求：必须且只能输出一个JSON对象数组，每个对象包含`sentiment`和`topic`键。\n\n', '现在，请分析以下评论列表：\n', (SELECT string_agg('评论' || (idx+1) || ': ' || text_array[idx+1], '\n') FROM generate_subscripts(b.text_array, 1) as idx) ), '{"temperature": 0.1, "max_tokens": 2000}'::jsonb -- 增加max_tokens以适应更长输出 ) as batch_raw_response FROM batch_data b ) -- 后续需要复杂的JSON解析来将batch结果拆分成单条记录，这里略去...

注意，批量处理时，Prompt需要调整，要求模型返回一个JSON数组，并且输入部分要清晰地列出所有评论。同时，max_tokens参数需要调大以容纳更长的输出。解析批量结果会比单条复杂，需要用到json_array_elements等函数将数组拆分为行。

2. KV-Cache调优 (关键中的关键)这是本次实战的进阶重点。LLM在生成每个Token时，都需要基于之前所有Token的Key和Value向量进行计算和缓存，这个缓存就是KV-Cache。对于分类任务，我们通常只需要模型输出一个简短的标签（如“正面”），但模型仍然会为整个输入Prompt（可能很长）和生成过程维护KV-Cache，这造成了巨大的内存和计算浪费。

hg_ai_complete函数允许通过参数控制KV-Cache的行为，核心参数是max_input_tokens和max_output_tokens。但更关键的是理解**“输入”和“输出”在计费和缓存中的角色**。

• max_input_tokens: 限制模型“看”到的输入文本的最大长度。超过部分会被截断。合理设置此值可以显著降低计算和存储成本。对于分类任务，我们的Prompt是固定的，加上变长的用户评论。你需要估算一个绝大多数评论长度都不会超过的值。例如，如果99%的评论在200字以内，加上Prompt模板约150字，总输入Token约350个（中文字符大约1.5个字符对应1个Token）。那么设置max_input_tokens: 400就是一个安全且节约的选择。
• max_output_tokens: 限制模型生成文本的最大长度。对于分类任务，我们期望的输出非常短（一个JSON字符串），所以这个值可以设得很小，比如50或100。设置过大会浪费资源。

-- 优化后的单条调用，显式控制Token长度 SELECT hg_ai_complete( 'qwen-max', CONCAT('[精简后的Prompt]', c.comment_text), '{ "temperature": 0.1, "max_tokens": 50, -- 输出很短，50足够 "max_input_tokens": 400 -- 根据Prompt+评论平均长度设定 }'::jsonb ) as ai_response FROM user_comments c;

实操心得：KV-Cache调优的本质是做“资源预算”。你需要像管理数据库连接池一样管理模型的输入输出窗口。通过监控AI函数调用的实际Token消耗（部分模型或平台会返回usage字段），不断调整max_input_tokens和max_output_tokens，找到在保证效果前提下的最小必要值。对于分类任务，将max_output_tokens设小是效果最明显的优化手段之一。

7. 错误处理与稳定性保障

在生产环境中运行，我们不能假设每次AI调用都成功。网络波动、模型服务暂时不可用、输入格式意外、输出不符合预期等情况都可能发生。SQL虽然强大，但错误处理能力相对较弱。我们需要在架构上考虑稳定性。

1. 重试机制与幂等性可以在应用层（调用SQL的脚本或任务）实现重试逻辑。更“SQL思维”的做法是利用Hologres的存储过程或定时任务，在失败后重新运行。关键是保证操作的幂等性，即同一批数据重复处理不会导致重复或错误的结果。我们的INSERT INTO ... SELECT语句如果基于主键comment_id，并且结果表有主键约束，重复插入就会失败，这需要我们在逻辑中处理（例如使用ON CONFLICT (comment_id) DO UPDATE ...）。

2. 输出格式校验与兜底策略即使Prompt要求输出JSON，模型偶尔也可能输出非JSON内容（如附加解释）。我们需要在SQL中增加校验。

WITH raw_analysis AS ( SELECT comment_id, comment_text, hg_ai_complete(...) as raw_response FROM user_comments ), parsed_analysis AS ( SELECT comment_id, comment_text, raw_response, -- 尝试解析JSON，如果失败则返回NULL CASE WHEN raw_response ~ '^\{.*\}$' THEN json_parse(raw_response) ELSE NULL END as response_json FROM raw_analysis ) SELECT comment_id, comment_text, COALESCE(json_extract_path_text(response_json, 'sentiment'), 'ERROR') as sentiment, COALESCE(json_extract_path_text(response_json, 'topic'), 'ERROR') as topic, raw_response FROM parsed_analysis;

这里使用了正则表达式^\{.*\}$简单判断响应是否被大括号包围（即JSON对象），然后尝试解析。解析失败或字段缺失时，使用COALESCE函数提供默认值‘ERROR’，便于后续筛选和人工复核。

3. 限流与分批对于海量数据，不要试图用一个巨型SQL语句处理所有数据。务必采用分批策略，如之前示例的GROUP BY (comment_id - 1) / 100。这不仅能避免单次查询超时或内存溢出，也便于控制对AI服务的请求速率，避免触发限流。可以在存储过程中使用循环，或者用调度工具（如Airflow）编排多个分批次SQL任务。

8. 效果评估与方案对比

方案上线后，如何评估其效果？我们至少需要关注三个维度：准确率、性能和成本。

1. 准确率评估由于是零样本/少样本分类，没有标注好的测试集，我们可以采用抽样评估。

• 人工抽检：定期从结果表中随机抽取一批数据，人工判断分类是否正确，计算准确率。可以在结果表中增加一个review_status字段标记是否已复核。
• 一致性检查：如果历史上有基于规则或简单模型的分类结果，可以将AI分类结果与之对比，分析差异点。AI往往能发现规则覆盖不到的复杂案例。
• A/B测试：对于新产生的数据，可以同时用旧方案和新方案（AI）进行分类，对比一段时间内的结果差异，观察AI是否带来了正向提升（如更细的粒度、更少的“其他”类）。

2. 性能与成本监控

• 性能：记录每条SQL或每个批次的处理耗时。关注hg_ai_complete函数的执行时间。如果使用分批，计算总体吞吐量（条/秒）。
• 成本：关注AI服务的Token消耗。虽然Hologres AI Function的具体计费方式需参考官方文档，但通过控制max_input_tokens和max_output_tokens，我们已经是在进行成本管控。可以尝试估算：总成本 ≈ (平均输入Token数 + 平均输出Token数) * 数据条数 * 单价。优化Prompt、精简输入输出能直接降低成本。

3. 与替代方案对比

• vs. 自建模型服务：省去了运维、部署、资源预留的成本和精力，起步快，适合快速验证和迭代。但在极端定制化、对延迟有极致要求、或需要完全控制模型版本的情况下，自建服务更灵活。
• vs. 外部API：数据不出内网，延迟更低（尤其是Hologres与AI服务同地域时），批量处理效率可能更高（取决于API的并发限制）。成本结构可能不同，需要根据实际调用量详细测算。
• vs. 传统规则引擎：AI方案的准确率和覆盖率上限更高，能处理复杂、模糊的语义。规则引擎维护成本高，但确定性100%，对于简单、明确的分类，规则可能更快更便宜。

我个人在实际项目中的体会是，对于中等数据量（日增数万至百万级）、分类逻辑复杂且可能变化的场景，Hologres AI Function提供的SQL原生AI能力是一个“甜点”方案。它极大地降低了算法能力的数据应用门槛，让数据分析师也能快速构建智能分类管道。最大的挑战和乐趣，其实在于如何通过精巧的Prompt设计和资源调优，用最低的成本获得最稳定的效果。这个过程本身，就是对数据和AI理解的一次深度实践。