Data agent 项目

原创于 2026-10-27 10:57:00 发布 · 99 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

本文围绕Data Agent项目，详解语义层核心建模机制：基于YAML的五段式结构（元信息、properties、measures、relationships、defaults+governance），时间字段time_property与sql_on_expr的语义对齐能力，上下文通过namespace.yml/glossary.json/business_context.yml三级注入，评测依托1300+行规范与semantic-lint打分，权限通过维度映射与可达性校验实现。

项目简介：
　业务侧临时取数长期依赖数据团队，需求转译链路长、指标口径分散。部门自研Data-Agent，让 LLM 仅承担自然语言到结构化意图的翻译，SQL 由语义引擎确定性生成，接入 Web、飞书、MCP、API 四条渠道，使运营、分析师、高管以自然语言直接取数，并从根源规避 LLM 直写 SQL 导致的口径漂移与幻觉字段风险，平台语义准确率达92%。

技术栈：Claude Code + Python + LangGraph + LLM + Hologres + Elasticsearch + React + Docker 
职责与成果：
1、独立搭建语义模型：独立搭建售后 + 线索领域语义模型，覆盖 30 张表、500+ 个度量，交付 40+ class 本体论语义模型；完成售后 + 线索域数仓 → Hologres 同步与查询授权，为自然语言问数提供统一语义底座。

2、重构 Business Rules 规则集：针对规则冗余导致 LLM 混淆的问题，优化 YAML 规范，压缩最短可验证指令、将可检索内容下沉至索引层，字符量缩减 85%，降低 LLM 混淆概率，提升意图识别与语义解析稳定性。

3、参与共建评测体系：负责本域评测问题供给与标准答案构建，形成评测数据飞轮闭环，结合 Pipeline 归因分类 + 线上链路回溯两套机制定位问题，修复 6 类核心问题，经过10+轮迭代，销售+线索实体语义准确率从50%提升至94% 。                                                                                                                                                                                      

4、参与平台上下文工程：参与系统提示词、附件源、会话尾注、注入节点四层并行注入架构的设计与实现，并参与同义词 → 描述 → 术语表 → 领域上下文的知识分层规范建设，提升 LLM 对业务语义的理解一致性。

5、审计权限风险与漏洞修复：针对语义层越权风险进行代码审计，验证 9 条攻击路径，发现并推动修复 fail-open、审计日志死代码 2 个高危漏洞；完成汽车 NS 实体级权限声明与命名空间维度映射配置，保障平台权限安全。

6、上线运营与持续维护：基于上线后主动巡查机制，通过管理控制台看板监控语义准确率与异常，定位并修复模型语义问题，保障平台稳定运行与持续迭代。

在这里插入图片描述

面试相关问题：
现在假如在面试，面试官有以下问题：你帮我回答一下： 1 本体论相关介绍，2 yaml 构造和结构 3 上下文怎么注入的 3 评测怎么做的 5 权限怎么实现

1 面试回答

1.1本体论相关介绍

在这里插入图片描述

1.2yaml 构造和结构

口述版
一个 Class 一个 YAML 文件，分五块：头部元信息、properties、measures、relationships、defaults，最后还有一个可选的 governance。构建顺序是：先用数仓表 DDL 生成 properties 骨架；再和业务方对齐口径，写 measures；然后按外键声明关系；最后补同义词和描述，用评测题集驱动迭代。

下面是从你域里的 clue_pipeline.yml 精简出来的：

class: CluePipeline              # LLM 选的是实体名，不是表名
permission: [x_org_id]           # 行级权限维度
synonym: {zh: [线索明细, 线索漏斗]}
description:                     # 给 LLM 的选表规则
  zh: 一行一条线索…统计汇总指标禁止用本表，必须用 ClueOrgStaffMinute…
table: adsfssfdseline_rt # 物理映射
primary_key: clue_id
properties:
  level:
    type: string
    dim_source: true             # 维度值同步到检索层，供枚举值匹配
    enum_values: [{value: A, name: {zh: 高意向}}, ...]
measures:
  clue_drive_cnt:
    synonym: {zh: [已试驾线索数, 试驾转化线索数]}
    agg: count_distinct
    expression: clue_id
    condition: "${drive_cnt} > 0"  # 条件度量，口径固化
    time_property: ymd             # 用户说"上个月"，自动落到这个时间字段
relationships:
  category:
    to: DimCategory
    type: many_to_one
    foreign_key: first_item_id
    target_key: car_item_id        # 先去重再 JOIN，防止翻倍
    sql_on_expr: ${source}.first_item_id::TEXT = ${target}.car_item_id::TEXT

被追问时

description 写的是「查询规则」，不是普通注释，比如「①本表用于… ②禁止用于…」。这是写给 LLM 的路由提示。

time_property 解决时间口径：比如锁单量对应 lock_tm，小订对应 sm_tm。用户说「上个月」，时间条件会自动落到这个度量对应的时间字段上。

sql_on_expr 处理特殊 JOIN：类型不一致要加 ::TEXT 转换；还有多键 JOIN，比如 staff_id + org_id + 岗位域一起关联。

NS 级还有三个配置文件：
namespace.yml：数据库连接、权限维度映射、business_rules。
glossary.json：术语表。
business_context.yml：领域上下文。
质量保障：后端启动时 loader 会做校验，包括度量引用、关系字段引用、权限声明是否齐全、权限维度是否可达；另外有一份 1300+ 行的建模规范，还有 semantic-lint 打分。