SQL直接调用AI：数据库行业的范式革命来了

数据库行业正在经历一场静悄悄的革命。

长期以来，我们被迫在两个割裂的世界中工作：数据工程师在SQL和数据仓库中挖掘洞察，AI工程师在大模型中寻求突破。想要让数据用上AI？准备好复杂的ETL流程、昂贵的API调用链路，以及让人头疼的数据一致性问题。

这种割裂，正在成为企业数字化转型的致命瓶颈。

Apache Doris 4.0 直接向这个行业痛点开火：将LLM作为原生函数内置到SQL引擎中。 不再需要复杂的工程链路，不再需要数据导入导出，一条SQL语句就能完成从数据查询到AI分析的全流程。

这不是渐进式改进，这是范式颠覆

场景一：简历匹配的智能化

-- 一条SQL解决语义匹配问题
SELECT c.name, j.title
FROM candidate_profiles AS c
JOIN job_requirements AS j
WHERE LLM_FILTER(CONCAT('候选人是否匹配工作要求?',
    '要求: ', j.jd_text, ' 候选人: ', c.self_intro))
  AND j.job_id = 102;

传统方案需要什么？ 构建向量数据库、训练匹配模型、设计复杂的评分算法。现在？一个WHERE条件搞定。

场景二：保险理赔的智能审核

-- 同时完成过滤和分类
SELECT 
    c.claim_id,
    llm_classify(c.incident_description, ['交通事故', '人身意外', '财产损失']) AS category
FROM claims AS c 
WHERE LLM_FILTER(CONCAT('该情形是否支持保险赔偿：', c.incident_description));

结果： 酒驾等明显不符合理赔条件的申请被自动过滤，有效申请被精准分类。这种精度和效率，是传统规则引擎无法企及的。

实现路径：三步解锁AI能力

第一步：注册AI资源

CREATE RESOURCE 'ai_service'
PROPERTIES (
    'type'='llm',
    'llm.provider_type'='deepseek',
    'llm.endpoint'='https://api.deepseek.com/chat/completions',
    'llm.model_name' = 'deepseek-chat',
    'llm.api_key' = 'your_api_key'
);

第二步：设置默认资源

SET default_llm_resource = 'ai_service';

第三步：直接在SQL中调用无需额外配置，所有LLM函数立即可用。

架构设计：为企业级应用而生

资源化管理是关键突破

传统的AI集成方案最大的问题是什么？ 每个模型都需要单独适配，API差异让集成变成噩梦，密钥管理混乱不堪。

这套架构将所有LLM服务抽象为统一的"资源"概念。 无论是OpenAI、DeepSeek、Claude还是本地部署的模型，都被标准化管理。每个资源封装了厂商信息、模型类型、认证密钥等关键配置，实现了多模型环境的无缝切换。

多厂商兼容的技术实现

更关键的是底层适配能力。 不同厂商的API格式千差万别，但系统为每种服务都实现了专门的请求构造、鉴权机制和响应解析逻辑。用户只需声明使用哪个厂商，系统自动选择对应的适配器完成调用。

这种设计让企业可以灵活选择最适合的模型服务，避免厂商锁定，同时大幅降低集成和切换成本。

函数生态：覆盖企业AI应用的80%场景

• LLM_GENERATE: 文本生成
• LLM_SUMMARIZE: 智能摘要
• LLM_CLASSIFY: 内容分类
• LLM_SENTIMENT: 情感分析
• LLM_EXTRACT: 信息抽取
• LLM_TRANSLATE: 多语言翻译

每个函数都经过生产环境验证，直接面向企业级应用场景设计。

这意味着什么？

对CTO来说：技术栈大幅简化，维护成本显著降低，AI能力的ROI终于可以量化。

对业务团队来说：数据分析师可以直接构建AI应用，不再依赖算法团队的排期。

对行业来说：数据库不再只是存储和查询工具，而是智能决策的核心引擎。

当SQL具备了AI的认知能力，数据分析从"被动查询"跃升为"主动洞察"。这不是功能升级，这是数据库进化的分水岭时刻。

数据库的边界，正在被重新定义。