语义赋能：打造企业级 Agent 核心基础设施

ENTERPRISE AGENT SEMANTIC LAYER

构建企业级智能体系统的核心基础设施——实现业务语义与技术实现的桥梁

核心章节	架构图	完整实例
7	15+	3

---

第 1 章 概述

1.1 什么是企业 Agent 语义层

企业 Agent 语义层（Enterprise Agent Semantic Layer）是位于企业 Agent 系统与底层数据源、业务系统之间的抽象层，它通过统一的语义模型将复杂的业务逻辑、数据关系和操作流程转化为 Agent 可理解和执行的结构化表示。

💡 核心定义

语义层是企业 Agent 的"翻译官"和"知识库"，它将业务语言转换为技术语言，将技术结果解释为业务洞察。

1.2 为什么需要语义层

在企业环境中，Agent 系统面临以下挑战：

• 数据孤岛： 企业数据分散在 ERP、CRM、HRM 等多个系统中，格式不一
• 语义鸿沟： 业务人员使用"客户"、“订单"等业务术语，而系统使用"tbl_cust”、"ord_mst"等技术表名
• 逻辑复杂： 业务规则（如折扣计算、审批流程）分散在各个系统中
• 上下文缺失： Agent 缺乏对企业特定业务场景的理解

图 1-1：语义层在企业 Agent 架构中的位置

1.3 语义层的核心价值

价值维度	描述	具体收益
统一语义	建立企业级统一业务术语表	减少 80% 的语义歧义
降低门槛	业务人员可直接与 Agent 交互	无需 SQL/编程技能
提升效率	自动化数据查询与分析	查询响应时间缩短 60%
保证一致性	统一业务规则执行	避免数据解读差异

---

第 2 章 核心概念

2.1 语义模型（Semantic Model）

语义模型是语义层的核心，它以结构化的方式描述企业中的业务实体、属性和关系。

📌 实例：零售企业语义模型

• 实体： 客户（Customer）、商品（Product）、订单（Order）、门店（Store）
• 属性： 客户。会员等级、商品。类别、订单。金额、门店。区域
• 关系： 客户"下单"订单、订单"包含"商品、门店"服务"客户
• 度量： 销售额 = SUM(订单。金额)、客单价 = 销售额 / 客户数

图 2-1：语义模型 ER 图示例

2.2 业务术语表（Business Glossary）

业务术语表是企业统一的业务词汇定义，确保不同角色对同一概念的理解一致。

图 2-2：业务术语表示例

业务术语	定义	计算公式	数据源	负责人
销售额	订单净销售额，扣除折扣和退货	SUM(订单金额) - SUM(折扣) - SUM(退货)	ERP 销售模块	销售总监
活跃客户	过去 90 天内有购买记录的客户	COUNT(DISTINCT 客户ID)	CRM 系统	客户运营
客单价	平均每笔订单的金额	销售额 / 订单数	ERP + CRM	数据分析
毛利率	(销售收入 - 成本) / 销售收入	(SUM(amount) - SUM(cost)) / SUM(amount)	ORDER + PRODUCT_COST	财务总监

2.3 语义上下文（Semantic Context）

语义上下文是 Agent 理解业务场景的关键信息，包括：

• 时间上下文： 财年定义、促销周期、季节性因素
• 组织上下文： 部门层级、汇报关系、权限范围
• 业务上下文： 当前促销策略、库存策略、定价策略

示例： 当用户问"上个月销售额如何？"时，语义层需要理解：

• "上个月"是指自然月还是财务月？
• "销售额"是指订单金额还是实际收款？
• 是否包含退货订单？
• 是否包含折扣？

---

第 3 章 架构设计

3.1 整体架构

图 3-1：企业 Agent 语义层完整架构

3.2 核心组件详解

3.2.1 语义解析器（Semantic Parser）

将自然语言查询转换为语义模型的中间表示（Intermediate Representation, IR）。

# 示例：自然语言到 IR 的转换
# 用户输入："查看北京地区高价值客户上个月的订单"

class SemanticIR:
    def __init__(self):
        self.entities = []      # 涉及的实体
        self.filters = []       # 过滤条件
        self.metrics = []       # 度量指标
        self.dimensions = []    # 维度字段
        self.time_range = None  # 时间范围

# 解析结果
ir = SemanticIR()
ir.entities = ["Customer", "Order"]
ir.filters = [
    {"field": "Customer.city", "operator": "=", "value": "北京"},
    {"field": "Customer.member_level", "operator": "IN", "value": ["Gold", "Platinum"]}
]
ir.time_range = {"field": "Order.order_date", "range": "last_month"}

3.2.2 查询构建器（Query Builder）

将语义 IR 转换为具体数据源的查询语句（SQL、API 调用等）。

# 示例：IR 到 SQL 的转换
class QueryBuilder:
    def build_sql(self, ir):
        sql = "SELECT"
        
        # 构建 SELECT 子句
        select_fields = self._build_select(ir.dimensions, ir.metrics)
        
        # 构建 FROM 子句（处理实体关联）
        from_clause = self._build_joins(ir.entities)
        
        # 构建 WHERE 子句
        where_clause = self._build_where(ir.filters, ir.time_range)
        
        return f"{select_fields} {from_clause} {where_clause}"

# 生成的 SQL
"""
SELECT 
    c.customer_id,
    c.name,
    o.order_id,
    o.amount,
    o.order_date
FROM customer c
INNER JOIN orders o ON c.customer_id = o.customer_id
WHERE c.city = '北京'
  AND c.member_level IN ('Gold', 'Platinum')
  AND o.order_date >= DATE_SUB(CURDATE(), INTERVAL 1 MONTH)
"""

3.2.3 规则引擎（Rule Engine）

执行业务规则计算，如折扣逻辑、审批流程等。

图 3-2：规则引擎执行流程

3.3 语义缓存层

为提升性能，语义层通常包含多级缓存：

• 查询缓存： 缓存频繁查询的结果
• 语义缓存： 缓存已解析的语义 IR，避免重复解析
• 聚合缓存： 缓存预计算的聚合指标（如日销售额）

图 3-3：多级缓存架构

---

第 4 章 关键技术

4.1 语义建模技术

4.1.1 本体论（Ontology）

使用形式化的方式描述领域知识，包括类、属性、关系和公理。

# 示例：使用 OWL 定义零售领域本体
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix retail: <http://example.org/retail#> .

# 定义类
retail:Customer rdf:type rdfs:Class .
retail:Order rdf:type rdfs:Class .

# 定义对象属性
retail:places rdf:type rdf:Property ;
    rdfs:domain retail:Customer ;
    rdfs:range retail:Order .

# 定义数据属性
retail:customerName rdf:type rdf:Property ;
    rdfs:domain retail:Customer ;
    rdfs:range xsd:string .

# 定义约束
retail:HighValueCustomer rdfs:subClassOf retail:Customer ;
    owl:equivalentClass [
        a owl:Restriction ;
        owl:onProperty retail:totalSpent ;
        owl:minValue "10000"^^xsd:decimal
    ] .

4.1.2 知识图谱（Knowledge Graph）

以图结构存储实体、属性和关系，支持语义推理。

图 4-1：企业知识图谱示例

4.2 自然语言理解（NLU）

4.2.1 意图识别

使用机器学习模型识别用户查询的意图类型。

# 示例：使用 BERT 进行意图分类
from transformers import BertTokenizer, BertForSequenceClassification

# 预定义意图类别
INTENT_CLASSES = [
    "QUERY_DATA",      # 数据查询
    "CALCULATE_METRIC", # 指标计算
    "COMPARE",          # 对比分析
    "TREND_ANALYSIS",   # 趋势分析
    "ROOT_CAUSE"        # 根因分析
]

# 加载模型
tokenizer = BertTokenizer.from_pretrained("bert-base-chinese")
model = BertForSequenceClassification.from_pretrained(
    "bert-base-chinese", 
    num_labels=len(INTENT_CLASSES)
)

# 意图预测
def predict_intent(query):
    inputs = tokenizer(query, return_tensors="pt", padding=True, truncation=True)
    outputs = model(**inputs)
    predicted_class = outputs.logits.argmax().item()
    return INTENT_CLASSES[predicted_class]

# 示例
query = "上个月北京地区的销售额是多少？"
intent = predict_intent(query)  # 输出：QUERY_DATA

4.2.2 实体抽取

从查询中识别和提取业务实体、时间表达式、度量等。

图 4-2：命名实体识别流程

4.3 查询优化技术

4.3.1 语义优化

基于业务语义进行查询重写和优化。

优化示例：

• 谓词下推： 将过滤条件尽可能下推到数据源
• 物化视图重写： 使用预计算的聚合表替代原始表查询
• 冗余连接消除： 基于外键约束消除不必要的 JOIN

4.3.2 查询路由

根据查询特征选择最优的数据源和执行路径。

图 4-3：智能查询路由

---

第 5 章 实例解析

5.1 实例背景：某零售企业销售分析场景

企业背景： 某全国性连锁零售企业，拥有 200+ 门店，年销售额 50 亿元，使用 SAP ERP、Salesforce CRM、自研数据仓库。

业务痛点：

• 业务人员需要 IT 部门协助提取数据，平均等待时间 3 天
• 不同部门对"销售额"等指标定义不一致
• 无法快速回答高层的临时数据询问

5.2 语义层设计方案

5.2.1 语义模型设计

图 5-1：零售企业核心语义模型

5.2.2 业务术语定义

# 业务术语配置（YAML 格式）
business_terms:
  销售额:
    definition: "订单净销售额，扣除折扣和退货"
    formula: "SUM(FACT_SALES.net_amount)"
    filters:
      - "FACT_SALES.order_status != 'CANCELLED'"
    data_sources:
      - "SAP_SD.VBRK"
      - "DWH.FACT_SALES"
    
  毛利率:
    definition: "(销售额 - 成本) / 销售额"
    formula: "(SUM(net_amount) - SUM(cost_amount)) / SUM(net_amount)"
    
  活跃客户:
    definition: "过去 90 天内有购买记录的客户"
    formula: "COUNT(DISTINCT customer_key)"
    time_window: "90 days"
    
  客单价:
    definition: "销售额 / 订单数"
    formula: "SUM(net_amount) / COUNT(DISTINCT order_id)"

5.3 完整查询流程演示

场景 1：简单数据查询

📌 用户查询： “查看北京地区上个月的销售额”

步骤 1：语义解析

# 解析后的语义 IR
{
  "intent": "QUERY_DATA",
  "entities": ["FACT_SALES", "DIM_STORE"],
  "metrics": [
    {"name": "销售额", "formula": "SUM(net_amount)"}
  ],
  "filters": [
    {"field": "DIM_STORE.city", "operator": "=", "value": "北京"},
    {"field": "FACT_SALES.order_date", "operator": ">=", "value": "2024-03-01"},
    {"field": "FACT_SALES.order_date", "operator": "<", "value": "2024-04-01"}
  ]
}

步骤 2：查询构建

-- 生成的 SQL
SELECT 
    SUM(fs.net_amount) AS sales_amount
FROM fact_sales fs
INNER JOIN dim_store ds ON fs.store_key = ds.store_key
WHERE ds.city = '北京'
  AND fs.order_date >= '2024-03-01'
  AND fs.order_date < '2024-04-01'
  AND fs.order_status != 'CANCELLED'

步骤 3：结果转换

# 返回结果
{
  "query": "查看北京地区上个月的销售额",
  "result": {
    "sales_amount": 12580000,
    "formatted": "北京地区上月销售额为 1,258 万元"
  }
}

场景 2：多维度分析

📌 用户查询： “按商品类别和会员等级分析近 30 天的销售情况”

-- 生成的 SQL
SELECT 
    p.category,
    c.member_level,
    SUM(fs.net_amount) AS sales_amount,
    COUNT(DISTINCT fs.order_id) AS order_count,
    AVG(fs.net_amount) AS avg_order_value
FROM
    fact_sales fs
INNER JOIN dim_product p ON fs.product_key = p.product_key
INNER JOIN dim_customer c ON fs.customer_key = c.customer_key
WHERE
    fs.order_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
    AND fs.order_status != 'CANCELLED'
GROUP BY
    p.category, c.member_level
ORDER BY
    sales_amount DESC

场景 3：复杂业务规则计算

📌 用户查询： “计算 Q1 季度的毛利率，考虑促销折扣和退货”

# 业务规则配置
gross_margin_calculation:
  numerator: "net_sales - total_cost"
  denominator: "net_sales"
  
  net_sales_definition:
    - "SUM(gross_amount)"
    - "- SUM(promotion_discount)"
    - "- SUM(return_amount)"
  
  cost_definition:
    - "SUM(quantity * unit_cost)"
    - "+ SUM(return_quantity * unit_cost)"
  
  special_rules:
    - "exclude_clearance_items: true"
    - "include_rebate: false"

5.4 实施效果

指标	实施前	实施后	提升
数据查询平均耗时	3 天	5 分钟	99.8%
业务人员自助分析比例	15%	78%	+420%
指标定义一致性	62%	98%	+58%
IT 部门数据需求工单	450 件/月	98 件/月	-78%

---

第 6 章 最佳实践

6.1 语义层设计原则

✨ 原则 1：业务驱动

• 从业务场景出发，而非技术实现
• 邀请业务专家参与语义模型设计
• 定期评审和更新业务术语表

✨ 原则 2：分层抽象

• 物理层：原始数据源映射
• 逻辑层：业务实体和关系
• 视图层：面向特定角色的预定义视图

✨ 原则 3：可扩展性

• 模块化设计，支持增量扩展
• 版本控制语义模型变更
• 向后兼容的 API 设计

6.2 治理与管理

6.2.1 变更管理流程

图 6-1：语义模型变更管理流程

6.2.2 质量监控指标

指标类别	具体指标	目标值	监控频率
准确性	查询结果准确率	> 99.5%	每日
性能	P95 查询响应时间	< 5 秒	实时
覆盖率	核心业务场景覆盖率	100%	每月
可用性	系统可用性	> 99.9%	实时

6.3 安全与权限

6.3.1 行级权限控制

# 基于角色的数据访问控制
row_level_security:
  rules:
    - role: "区域经理"
      filter: "DIM_STORE.region = ${user.region}"
    
    - role: "门店店长"
      filter: "DIM_STORE.store_id = ${user.store_id}"
    
    - role: "总部分析师"
      filter: "1=1"  # 全量数据
    
    - role: "供应商"
      filter: "DIM_PRODUCT.brand = ${user.brand}"

6.3.2 敏感数据脱敏

# 数据脱敏规则
data_masking:
  fields:
    - field: "DIM_CUSTOMER.phone"
      rule: "REPLACE(phone, SUBSTRING(phone, 4, 4), '****')"
      roles: ["客服", "销售"]
    
    - field: "DIM_CUSTOMER.id_card"
      rule: "CONCAT(LEFT(id_card, 6), '********', RIGHT(id_card, 4))"
      roles: ["所有角色"]
    
    - field: "FACT_SALES.amount"
      rule: "CASE WHEN role != 'MANAGER' THEN NULL ELSE amount END"
      roles: ["非管理层"]

---

第 7 章 挑战与趋势

7.1 当前挑战

7.1.1 技术挑战

• 语义歧义处理： 同一业务术语在不同场景下含义不同（如"收入"可能指订单金额、收款金额或确认收入）
• 复杂查询支持： 多跳推理、递归查询等复杂场景的语义解析
• 实时性要求： 秒级响应与大数据量之间的矛盾
• 多模态数据： 结构化数据与非结构化数据（文本、图像）的语义融合

7.1.2 组织挑战

• 跨部门协作： 业务部门、IT 部门、数据团队的协同成本高
• 知识传承： 业务专家经验的形式化沉淀困难
• 变更阻力： 既有工作流程和系统集成的改造阻力

7.2 发展趋势

7.2.1 技术趋势

趋势 1：LLM 增强的语义理解

🚀 应用方向

• 使用大语言模型提升自然语言理解准确率
• 自动发现潜在的语义关系和業務规则
• 智能查询建议和自我修正

趋势 2：语义层即服务（Semantic Layer as a Service）

☁️ 特点

• 云原生架构，弹性扩展
• 低代码/无代码的语义建模工具
• 预置行业语义模型模板

趋势 3：主动式语义推荐

💡 能力

• 基于用户行为自动推荐相关指标和维度
• 异常检测和根因分析的自动化
• 预测性分析建议

图 7-1：下一代智能语义层架构

7.2.2 应用场景扩展

领域	当前应用	未来扩展
金融服务	风控报告、监管报送	实时欺诈检测、智能投顾
医疗健康	病历分析、资源调度	辅助诊断、个性化治疗
智能制造	生产监控、质量分析	预测性维护、供应链优化
零售电商	销售分析、库存管理	动态定价、精准营销

---

第 8 章 AI 构建语义层实战

8.1 为什么用 AI 构建语义层

传统语义层构建面临诸多挑战：需要大量人工梳理业务逻辑、维护成本高、更新滞后。AI 技术的引入可以显著提升效率：

• 自动化建模： AI 自动分析数据库结构，生成语义模型初稿
• 智能映射： LLM 理解业务术语，自动建立与技术字段的映射
• 持续学习： 从用户查询中学习，不断优化语义理解
• 降低门槛： 业务人员可通过自然语言定义指标和规则

📊 效率对比

任务	传统方式	AI 辅助	提升
语义模型初稿	2-4 周	1-2 天	10-20 倍
业务术语映射	1-2 周	2-4 小时	20-35 倍
指标定义	30 分钟/个	5 分钟/个	6 倍

8.2 AI 构建语义层的核心技术

8.2.1 数据库结构分析

使用 AI 分析数据库元数据，自动识别实体、属性和关系。

# 使用 LLM 分析数据库 Schema
import openai

def analyze_database_schema(schema_info):
    """使用 AI 分析数据库结构，生成语义模型"""
    prompt = f"""
你是一个语义建模专家。请分析以下数据库 Schema，识别：
1. 业务实体（Entity）
2. 实体属性（Attribute）
3. 实体关系（Relationship）
4. 潜在的业务指标（Metric）

数据库 Schema:
{schema_info}

请按 JSON 格式输出语义模型。
"""
    
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )
    
    return json.loads(response.choices[0].message.content)

# 示例输入
schema = """
Tables:
- customers(customer_id, name, email, city, created_at)
- orders(order_id, customer_id, order_date, total_amount, status)
- order_items(item_id, order_id, product_id, quantity, price)
- products(product_id, name, category, brand, cost_price)
"""

semantic_model = analyze_database_schema(schema)

8.2.2 业务术语自动映射

利用 LLM 的语义理解能力，自动建立业务术语与技术字段的映射关系。

图 8-1：AI 术语映射流程

# 使用 Embedding 模型计算语义相似度
from openai import OpenAI

client = OpenAI()

def calculate_semantic_similarity(term, field_name):
    """计算业务术语与数据库字段的语义相似度"""
    # 获取 Embedding
    term_embedding = client.embeddings.create(
        model="text-embedding-ada-002",
        input=term
    ).data[0].embedding
    
    field_embedding = client.embeddings.create(
        model="text-embedding-ada-002",
        input=field_name
    ).data[0].embedding
    
    # 计算余弦相似度
    similarity = cosine_similarity(term_embedding, field_embedding)
    return similarity

# 自动映射
def auto_map_terms(business_terms, db_fields):
    """自动建立业务术语与数据库字段的映射"""
    mappings = []
    for term in business_terms:
        best_match = None
        best_score = 0
        for field in db_fields:
            score = calculate_semantic_similarity(term, field)
            if score > best_score:
                best_score = score
                best_match = field
        if best_score > 0.7:  # 阈值
            mappings.append({
                "term": term,
                "field": best_match,
                "confidence": best_score
            })
    return mappings

8.3 AI 构建语义层的完整流程

图 8-2：AI 构建语义层完整流程

8.4 实战案例：AI 构建零售语义层

8.4.1 步骤 1：连接数据源

# 配置数据源连接
data_sources = {
    "erp": {
        "type": "mysql",
        "host": "erp-db.company.com",
        "database": "sap_sd",
        "tables": ["VBRK", "VBAP", "KNA1"]
    },
    "crm": {
        "type": "postgresql",
        "host": "crm-db.company.com",
        "database": "salesforce",
        "tables": ["Account", "Opportunity", "Contact"]
    }
}

8.4.2 步骤 2：AI 生成语义模型

# 调用 AI 生成语义模型
prompt = """
基于以下数据库表结构，生成完整的语义模型：

ERP 系统 - 销售发票表 (VBRK):
- VBELN: 发票编号
- ERDAT: 过账日期
- NETWR: 净额（本币）
- KUNRG: 客户编号

ERP 系统 - 客户表 (KNA1):
- KUNNR: 客户编号
- NAME1: 客户名称
- ORT01: 城市
- KTOKD: 客户账户组

请识别：
1. 核心业务实体
2. 实体间关系
3. 关键业务指标
"""

response = call_llm_api(prompt)
semantic_model = json.loads(response)

# AI 生成的模型示例
{
  "entities": [
    {
      "name": "Customer",
      "source_table": "KNA1",
      "attributes": [
        {"name": "customer_id", "source": "KUNNR"},
        {"name": "customer_name", "source": "NAME1"},
        {"name": "city", "source": "ORT01"}
      ]
    },
    {
      "name": "SalesInvoice",
      "source_table": "VBRK",
      "attributes": [
        {"name": "invoice_id", "source": "VBELN"},
        {"name": "posting_date", "source": "ERDAT"},
        {"name": "net_amount", "source": "NETWR"}
      ]
    }
  ],
  "relationships": [
    {
      "from": "Customer.customer_id",
      "to": "SalesInvoice.customer_id",
      "type": "1:N"
    }
  ]
}

8.4.3 步骤 3：业务术语映射

# 业务术语自动映射
business_terms = [
    "销售额", "客户数", "订单量",
    "客单价", "毛利率", "活跃客户"
]

mappings = map_business_terms(business_terms, semantic_model)

# AI 映射结果
[
  {
    "term": "销售额",
    "mapped_fields": ["SalesInvoice.net_amount"],
    "aggregation": "SUM",
    "filters": ["status != 'CANCELLED'"],
    "confidence": 0.98
  },
  {
    "term": "客单价",
    "mapped_fields": [
      "SalesInvoice.net_amount",
      "SalesInvoice.invoice_id"
    ],
    "formula": "SUM(net_amount) / COUNT(DISTINCT invoice_id)",
    "confidence": 0.95
  }
]

8.4.4 步骤 4：持续优化

🔄 基于用户反馈的自我优化

系统记录用户查询和修正行为，自动调整语义模型：

# 用户反馈学习
def learn_from_feedback(query, correction):
    """从用户修正中学习，优化语义理解"""
    feedback_data = {
        "original_query": query,
        "ai_interpretation": ai_result,
        "user_correction": correction,
        "timestamp": datetime.now()
    }
    
    # 存储反馈到学习库
    feedback_db.insert(feedback_data)
    
    # 定期批量训练优化模型
    if should_retrain():
        retrain_semantic_model(feedback_db.get_all())

8.5 AI 构建工具推荐

工具类型	推荐工具	适用场景	特点
LLM API	GPT-4 / Claude / 文心一言	语义理解、文本生成	理解能力强，支持多语言
Embedding 模型	text-embedding-ada-002 / BGE	术语相似度匹配	计算语义相似度
知识图谱工具	Neo4j / Nebula Graph	存储语义关系	图查询、关系推理
低代码平台	dbt + AI 插件	指标定义与管理	版本控制、协作方便

8.6 注意事项与最佳实践

⚠️ 注意事项：

• 人工审核必要： AI 生成的内容需要业务专家审核确认
• 数据安全： 避免将敏感 Schema 信息发送到公有云 LLM
• 版本管理： 语义模型变更需要版本控制和回滚机制
• 性能考量： 复杂 AI 生成的 SQL 可能需要优化

✅ 最佳实践

• 混合模式： AI 生成初稿 + 人工精调，平衡效率与质量
• 增量构建： 从核心业务开始，逐步扩展语义覆盖范围
• 反馈闭环： 建立用户反馈机制，持续优化 AI 模型
• 文档同步： AI 自动生成语义字典和使用文档

---

总结

企业 Agent 语义层是构建企业级智能体系统的核心基础设施，它通过统一的语义模型、业务术语表和规则引擎，实现了业务语义与技术实现的无缝对接。通过本文档的学习，您应该已经掌握了：

核心内容	说明
✅ 核心概念	语义模型、业务术语表、语义上下文的定义与设计方法
✅ 架构设计	语义解析器、查询构建器、规则引擎等核心组件的实现
✅ 关键技术	本体论、知识图谱、NLU、查询优化等技术应用
✅ AI 构建实战	利用 LLM 自动化构建语义层的完整流程与工具