本文作者反思了轻量级Agent构建模式的局限性，强调构建高质量、结构化、可追溯的知识体系的重要性，探索AI数据工程的“返璞归真”之路。
原文标题：AI数据工程师在应用中如何"返璞归真"
原文作者：阿里云开发者
冷月清谈：
为了应对这些问题，文章提出了从“Prompt驱动”向“上下文工程”演进的范式跃迁，强调构建高质量、结构化、可追溯的上下文语料体系的重要性，包括构建业务术语库、数据语义图谱和合规约束规则。同时，还需要建立覆盖数据合成与微调、工具集成标准化以及效果评估体系的全链路闭环能力。文章重点介绍了MktAI知识体系建设的实践，包括结构化数据的语义层增强、RAG升级和本体构建，旨在为大模型注入高信噪比、结构化、可推理的领域知识，最终实现让AI“读懂”数字的目标。
作者认为，AI应用的繁荣需要重视知识工程的深厚土壤，构建能够让AI自主学习、可靠推理、高效执行的数字孪生业务环境。未来的发展方向是将这些经过验证的结构化知识语料与后训练、评测等技术相协调融合，以工程化的严谨探索值得信赖的智能。
怜星夜思：
2、文章中提到，早期采用“原始文档切片 → 向量索引 → 重排序检索”的知识注入方式存在一些问题，你认为在实际应用中，如何选择合适的文档切片策略？
3、文章最后提到了将结构化知识语料与后训练、评测等技术相协调融合是未来的发展方向，你认为如何有效地利用这些结构化知识来提升模型的性能和可靠性？
原文内容
阿里妹导读
本文反思了“知识库+Prompt工程+工具调用”这一轻量级Agent构建模式的局限性，指出其难以应对真实业务场景中的知识质量、语义理解与规模化维护挑战。（本文内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
一、引言：Agent热潮下的实践反思
“知识库 + Prompt Engineering（PE）+ Function Calling + Few-shot 示例这四件套拼在一起，就能召唤出一个能答会算的 AI 小助手。”
-
比如对话：“焕新补贴季活动中品牌表现如何？”
-
你发现取数工具还没cover到xx指标，“焕新补贴季”是个啥语义没ready……此刻，像极了产品经理在周五下班前发来的“小改动”需求，表面温和，实则致命。
我们意识到：Agent 不是乐高，它更像一辆自动驾驶汽车，光有方向盘（Prompt）远远不够，还得有高精地图（上下文）、传感器融合（工具链）和实时决策系统（推理闭环）
二、轻量级Agent构建模式的“甜蜜陷阱”
2.1 知识质量不可控：RAG 不是万能胶，乱贴会掉渣
早期普遍采用“原始文档切片 → 向量索引 → 重排序检索”的知识注入方式，虽能快速跑通端到端流程，但存在缺陷：
-
幻觉：模型基于不完整或错误上下文生成看似合理但事实不符的回答；
-
语义断裂：“优惠券叠加规则”被切成三片，每片单独看都合理，合起来逻辑崩坏，像极了if-else 嵌套超过三层的代码。切片粒度过细导致上下文逻辑割裂，影响推理连贯性；
-
召回缺失：关键信息因切分策略或嵌入偏差未能有效召回，造成答案遗漏。
2.2 元数据语义鸿沟：数据表看得见，但 AI 读不懂“黑话”
沉淀于ODPS、Hologres、数据湖等引擎中的元数据（如表字段、血缘关系、业务口径、指标定义），本质上是面向机器而非人类语言的符号系统。若直接用于RAG或工具调用，常导致模型“看得见数据，读不懂含义”。
我们不是缺数据，是缺“能让 AI 看懂的数据说明书”。
2.3 Prompt Engineering 的规模化瓶颈
尽管PE被视为Agent开发的“第一生产力”，其效能却严重依赖工程师经验，实践中呈现两极分化：
-
高阶实践：通过结构化配置文件（如agent_skills.md、tool_xxx.md）管理子Agent职责、工具接口规约、示例模板，实现提示词的模块化、版本化与可复用；
-
初级实践：将所有逻辑硬编码在单一Prompt中，导致迭代时需多链路同步修改，维护成本陡增且一致性难以保障。
2.4 Agent 链路过简：防御式设计 vs 开放性悖论
为了防幻觉、保稳定，一些Agent加了“安全带”：前置意图识别、输入过滤、结果校验、CoT 强引导……甚至限制用户提问自由度。效果是稳了，但 Agent 也变得“死板”了——像极了客服机器人：“亲，您的问题已记录，请稍后联系人工.....”
简化链路虽能短期控险，却牺牲了 Agent 最宝贵的泛化能力与探索精神。真正的智能，应该在可控与开放之间走钢丝。——By AI
三、范式跃迁：从Prompt-Centric走向Context-Aware
上述问题共同指向一个核心认知转变：以Agent应用为中心的开发范式正在经历双向演进。
3.1 向左延伸：从“Prompt驱动”到“上下文工程”
不再仅依赖提示词，而是构建高质量、结构化、可追溯的上下文语料体系，涵盖：
-
业务术语库：标准化黑话、缩写、指标别名等等如“尖货”“焕新补贴”“分层GMV”等黑话的官方解释
-
数据语义图谱：融合元数据、血缘、口径、使用场景，形成可推理的知识网络；
合规约束规则：明确哪些事能做、哪些红线不能碰，让 Agent 真正“懂边界”。
3.2 向右深化：从“搭积木组装”到“全链路闭环”
需建立覆盖以下环节的系统化能力：
-
数据合成与微调（SFT/RLHF）：让模型学会“正确提问”和“正确取数”；
-
工具集成标准化：统一接口协议，避免每个 Agent 自己造轮子；
-
效果评估体系：不仅看“能不能答”，更要看“答得准不准”“业务价值高不高”，并建立幻觉检测、任务完成率、指标关联等量化指标。
Agent 的终极目标，不是“会说话的工具”，而是“懂业务、守规则、能扛事的数字员工”。
四、MktAI知识体系建设：让 AI “读懂”数字
基于上述认知，我们将重心转向以 Context-Aware 知识库体系建设。目标是：为大模型注入高信噪比、结构化、可推理的领域知识，使其在复杂中具备精准理解、可靠推理与高效生成的能力，降低系统性“幻觉”，提升AI决策的可解释性。
4.1 结构化数据的语义层增强
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 的信任度
|
典型评测示例（含黑话，350+） |
准确率 |
|
统计2025年焕新补贴季活动中品牌调性分为6分的品牌名称及对应分值，按分值降序、品牌名顺序取Top5品牌 |
86%->95% |
|
统计2024年双旦活动期间各品牌的累计支付金额和支付订单数，按支付金额排序 |
|
|
统计2024年女王节抢先购现货活动期间尖货且为活动商品的支付金额总和、订单数，按金额排序，取Top5 |
|
|
统计2025年双十一期间每个商家分层的累计支付GMV和支付订单数，按GMV降序排列，取Top5分层 |
4.2 RAG 升级：从 Vector-Based 到 Reason-Based
面对 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 主动阅读 + 推理”。
方案优势与效果验证
|
维度 |
表现 |
|
人工好评率 |
98%（vs 传统Vector-Based RAG ≈30%） |
|
精准性 |
提升准确回答定义类、规则类问题，避免无关干扰 |
|
完整性 |
提升跨文档、跨段落复杂查询，构建完整推理链 |
|
鲁棒性 |
对长尾问题、表达差异大的Query具备更好召回能力 |
4.3 构建本体：从“猜谜”到“学理”的范式革命
为什么前两种方案仍是“治标不治本”？
本体论：为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进行了验证，结果如下：
|
评测场景 |
指标 |
当前最佳值（%） |
|
购后价格场景评测集 |
归因合理性 |
89% |
|
本体召回率 |
82% |
|
|
推理完整性 |
89% |
|
|
大促价格管控场景评测集 |
归因合理性 |
94% |
|
本体召回率 |
90% |
|
|
推理完整性 |
92% |
五、结语：返璞归真，回归AI数据工程的本质
如今，我们正将对数据模型的理解、对业务方法论的抽象——重新注入到AI应用的底层。不再仅仅是Prompt的调优者，更是数字&现实世界的建筑师。我们构建的不仅是知识库，更是一个能让AI自主学习、可靠推理、高效执行的数字孪生业务环境。
展望未来：与后训练、评测等技术的协调融合
这些经过验证的、高信噪比的结构化知识语料，天然具备更高的准确性与合规性，能进一步加速模型训练数据/评测数据的自动化合成，从而减少对复杂推理链路的依赖。
这，便是我们在AI浪潮中所追寻的“返璞归真”——回归到数据与知识的本源，以工程化的严谨，探索值得信赖的智能。