AI数据工程师在应用中如何"返璞归真"

“知识库 + Prompt Engineering（PE）+ Function Calling + Few-shot 示例这四件套拼在一起，就能召唤出一个能答会算的 AI 小助手。”

• 比如对话：“焕新补贴季活动中品牌表现如何？”
• 你发现取数工具还没cover到xx指标，“焕新补贴季”是个啥语义没ready……此刻，像极了产品经理在周五下班前发来的“小改动”需求，表面温和，实则致命。

我们意识到：Agent 不是乐高，它更像一辆自动驾驶汽车，光有方向盘（Prompt）远远不够，还得有高精地图（上下文）、传感器融合（工具链）和实时决策系统（推理闭环）

早期普遍采用“原始文档切片 → 向量索引 → 重排序检索”的知识注入方式，虽能快速跑通端到端流程，但存在缺陷：

• 幻觉：模型基于不完整或错误上下文生成看似合理但事实不符的回答；

• 语义断裂：“优惠券叠加规则”被切成三片，每片单独看都合理，合起来逻辑崩坏，像极了if-else 嵌套超过三层的代码。切片粒度过细导致上下文逻辑割裂，影响推理连贯性；

• 召回缺失：关键信息因切分策略或嵌入偏差未能有效召回，造成答案遗漏。

沉淀于ODPS、Hologres、数据湖等引擎中的元数据（如表字段、血缘关系、业务口径、指标定义），本质上是面向机器而非人类语言的符号系统。若直接用于RAG或工具调用，常导致模型“看得见数据，读不懂含义”。

我们不是缺数据，是缺“能让 AI 看懂的数据说明书”。

尽管PE被视为Agent开发的“第一生产力”，其效能却严重依赖工程师经验，实践中呈现两极分化：

• 高阶实践：通过结构化配置文件（如agent_skills.md、tool_xxx.md）管理子Agent职责、工具接口规约、示例模板，实现提示词的模块化、版本化与可复用；

• 初级实践：将所有逻辑硬编码在单一Prompt中，导致迭代时需多链路同步修改，维护成本陡增且一致性难以保障。

为了防幻觉、保稳定，一些Agent加了“安全带”：前置意图识别、输入过滤、结果校验、CoT 强引导……甚至限制用户提问自由度。效果是稳了，但 Agent 也变得“死板”了——像极了客服机器人：“亲，您的问题已记录，请稍后联系人工.....”

简化链路虽能短期控险，却牺牲了 Agent 最宝贵的泛化能力与探索精神。真正的智能，应该在可控与开放之间走钢丝。——By AI

上述问题共同指向一个核心认知转变：以Agent应用为中心的开发范式正在经历双向演进。

不再仅依赖提示词，而是构建高质量、结构化、可追溯的上下文语料体系，涵盖：

• 业务术语库：标准化黑话、缩写、指标别名等等如“尖货”“焕新补贴”“分层GMV”等黑话的官方解释

• 数据语义图谱：融合元数据、血缘、口径、使用场景，形成可推理的知识网络；

合规约束规则：明确哪些事能做、哪些红线不能碰，让 Agent 真正“懂边界”。

需建立覆盖以下环节的系统化能力：

• 数据合成与微调（SFT/RLHF）：让模型学会“正确提问”和“正确取数”；

• 工具集成标准化：统一接口协议，避免每个 Agent 自己造轮子；

• 效果评估体系：不仅看“能不能答”，更要看“答得准不准”“业务价值高不高”，并建立幻觉检测、任务完成率、指标关联等量化指标。

Agent 的终极目标，不是“会说话的工具”，而是“懂业务、守规则、能扛事的数字员工”。

基于上述认知，我们将重心转向以 Context-Aware 知识库体系建设。目标是：为大模型注入高信噪比、结构化、可推理的领域知识，使其在复杂中具备精准理解、可靠推理与高效生成的能力，降低系统性“幻觉”，提升AI决策的可解释性。

4.1.1 构建元数据知识体系：从“What”到“How & When”

不再满足于“这个字段叫什么”，而是回答：

• 怎么算？（例如：“商家公域到手价 = 基础价 - 可叠加优惠 + 排他规则校验”）
• 在哪用？（适用于活动全周期分析，不适用于单品粒度）
• 别乱用！（警示：此字段不含退款剔除，慎用于最终结算）

字段级语义富化成为标配，每个字段附带：

• 计算逻辑
• 值域特征（枚举/范围）
• 典型场景
• 常见误用反例

更进一步，引入正反例对比学习：

正例：SELECT brand, score FROM brand_tone_score WHERE activity='...' AND score=6 ORDER BY score DESC, brand ASC LIMIT 5反例：...WHERE score='6分'（枚举值匹配失败）

让模型在“对与错”的边界上学会判断。

4.1.2 血缘关系的语义化扩展

显式建模字段间的业务因果链，比如：

• “优惠券ID → 影响 → 订单折扣金额”
• “活动商品标识 → 关联 → 尖货池”

并支持跨表语义推理：当用户问“尖货商品的支付金额”，系统能自动关联商品表、活动表、订单表，避免因表隔离导致逻辑断裂。

4.1.3 元数据治理：开发即治理，AI 辅助评审

• 元数据AI代理评审：当新增或修改元数据（如定义一个新的“价格口径”字段）时，让7*24小时的AI助手帮你审核

• 校验新定义是否与已有体系冲突
• 其计算口径是否严谨
• 并给出修订建议

4.1.4 数据保鲜：变更感知 + AI 自动填充

构建变更感知流程，监听 MaxCompute / Hologres 的 DDL/DML 变更，让AI帮你：

• 触发元数据同步流程
• 调用 LLM 基于上下文自动生成初步语义解释
• 待人工确认后入库

终于不用每次改个字段都要手动更新了——程序员的幸福感，有时候就这么简单。

4.1.5 模块化分析框架：把专家经验沉淀为“可加载插件”

将数科、运营专家分析经验进行知识下沉，形成可复用的分析模块，供不同Agent按需加载。

4.1.6 效果论证：准确率从 86% → 95%

提升的不仅是数字，更是同学对 AI 的信任度

面对 70% 的非结构化知识（文档、流程图、截图），继续探索RAG提升方案（Reason-Based RAG 架构）。

阶段1：层次化索引构建 —— 把文档变成 LLM 能“翻”的书

• 多模态理解：调用多模态模型自动解析图表、截图，生成结构化描述并回填原文；
• 结构化解析：基于Md等符号构建 ToC Tree，智能跳过代码块中的伪标题；
• 树形瘦身：合并低 Token 子树，避免碎片化；
• 智能摘要：长文本由 LLM 生成摘要，强制高亮关键词（活动名、Toolcode、角色职责），输出两份视图：

• search_tree（仅摘要）→ 用于召回
• full_tree（摘要+原文）→ 用于生成

阶段2：LLM 驱动的推理式召回 —— 让模型自己“翻目录找答案”

抛弃向量相似度，改由 LLM 扮演“文档专家”：

• 在search_tree中推理出最相关的N个节点；
• 支持跨章节关联、隐含语义匹配；
• 若信息不足，可生成“扩展计划”（向上/向下/横向导航），构建完整推理链；
• 多文档并发检索，仅 Top-K 进入生成阶段，控制成本。

这不是检索，这是“AI 主动阅读 + 推理”。

方案优势与效果验证

为什么前两种方案仍是“治标不治本”？

本体论：为AI构建业务世界的“公理系统”

本体驱动的AI Agent：从“问答机”到“数字员工”

• 精准理解：面对“焕新补贴季”这个短语，Agent能立刻识别出这是一个 Activity 类型的实例，并能关联到其包含的 Item、使用的 DiscountTool 等。
• 可靠推理：当被问及“尖货商品的支付金额”时，Agent能通过 Item -> is_featured_item (属性) 或 Item -> BelongsTo -> FeaturedPool (关系) 找到尖货，再通过 Item -> HasOrder -> Order (关系) 找到支付金额，整个过程基于预定义的逻辑链路，杜绝了臆测。
• 高效执行：当需要生成复杂查询时，Agent可以直接调用 QueryComparisonStatus 这样的Action，传入正确的 ComparisonPool 对象，即可获得格式化、合规的结果，无需再进行脆弱的Prompt工程。

效果验证与持续演进

我们在300+的评测集上对本体驱动的Agent进行了验证，结果如下：

如今，我们正将对数据模型的理解、对业务方法论的抽象——重新注入到AI应用的底层。不再仅仅是Prompt的调优者，更是数字&现实世界的建筑师。我们构建的不仅是知识库，更是一个能让AI自主学习、可靠推理、高效执行的数字孪生业务环境。

展望未来：与后训练、评测等技术的协调融合

这些经过验证的、高信噪比的结构化知识语料，天然具备更高的准确性与合规性，能进一步加速模型训练数据/评测数据的自动化合成，从而减少对复杂推理链路的依赖。

这，便是我们在AI浪潮中所追寻的“返璞归真”——回归到数据与知识的本源，以工程化的严谨，探索值得信赖的智能。