Aloudata Agent 36 问，深度解惑！

感谢各位数据从业者对 Aloudata Agent 首秀直播的深度参与！

36 问涵盖核心功能解读、应用实践及技术细节答疑

Q1.明细语义层包含哪些关键信息？

逻辑模型（DWD 层明细事实表与维表的关联关系）、指标元数据信息（包括指标名称、计算口径、管理属性等相关信息）、维度元数据信息（维度、维度值等相关信息）和指标血缘关系。

Q2.那么多的指标与信息大模型是如何匹配到的？指标准确性如何保障？如何去规避大模型幻觉的问题？

Aloudata Agent 的方案中，我们采用 NL2MQL2SQL 的方式，充分发挥大模型 + 明细级指标语义层的优势。将指标语义层作为企业知识库提供给大模型，大模型基于最全、最丰富的企业知识库进行用户意图的识别，提升意图识别的精准度（即用户问的是什么指标和维度）；根据用户的意图，由指标语义引擎执行 MQL->SQL 的自动翻译，指标语义引擎自动将指标查询要素的结构与SQL Query的结构对齐，规避大模型幻觉、生成 SQL 不准确的问题。

Q3.如何做到用户的指标查询需求翻译成查询语义层的请求参数呢？MQL 到 SQL 的映射是具体如何生成？

当用户提出问题时，Agent 首先判断用户意图，例如区分是查询指标口径、获取数据还是生成综合分析报告。随后，通过向量检索、ES 文本检索以及 KV 关联指标检索等多路召回技术高效检索指标语义层沉淀的指标元数据信息、维度元数据信息、指标血缘关系和逻辑模型关联关系，确保指标与维度的精准召回。

MQL 包含具体的指标、维度、筛选条件信息等，指标语义层对指标进行了要素化组装定义，基于指标语义引擎能力，将指标查询要素的结构与 SQL Query 的结构对齐，实现 MQL->SQL 的自动生成，确保 SQL 翻译的 100% 准确，并通过物化加速与智能路由技术执行查询。

Q4.大模型自己本身具备一定的知识，有时候会抽风似的不看上下文，仅凭自身的知识强行生成错误的 SQL。这个问题如何解决？

一方面我们不是让大模型自动生成 SQL，我们采用 NL2MQL2SQL 的方式，由大模型理解用户的意图再翻译成 MQL （即用户问的是什么指标和维度），由 NoETL 指标平台的指标语义引擎来翻译 SQL，规避大模型生成 SQL 不准确的问题；另一方面，产品层设计了“引用追问”功能，由用户指定是否要引用上下文进行追问。如果“引用”，大模型会结合上下文，如果不“引用”则会忽略上下文。

Q5.Agent 生成的 MQL 会包含哪些信息？

MQL（Metrics Query Language）的本质是对指标平台语义层进行指标查询的 API。包括用户问题涉及的基础度量（基础指标）、时间限定、业务限定（静态或动态维度筛选）、衍生方式（如排名、占比、同环比等）。

Q6.可以给一个具体的 MQL 的样例吗？

MQL 包含基础度量、维度和筛选条件、统计周期、衍生方式四种要素。例如，下面是针对问题：4月一级渠道的童装销售金额及年同比的 MQL

Q7.可以同一个问题里问两个指标吗？这两个指标来自于不同的表和数据源？

可以的，支持来自多源跨表的指标计算。

Q8.一次性查询多个指标，是生成多个 MQL 查询，单独查询展示？可以一次性查询多个指标，放在一个表格里展示吗？

生成单个指标还是多个指标，依赖于多个指标的分析维度是不是一致、来源数据模型是不是一致，如果分析维度一致、数据来源一致，则生成单个 MQL ，否则生成多个 MQL。如果是单个 MQL，则放在一个表格中展示。

Q9.用户输入的意图较为模糊，直接判断用户要的是某个指标进行查询，准确度怎么样？

Aloudata Agent 会对开放式问题进行启发推荐，收窄意图。

Q10.实现比较好的智能分析 Agent 的效果要有哪些前提？比如数据归集完整清晰、知识库完备？业务域数据治理定义、口径、指标标准等？

好数据才能驱动真智能。我们认为实现好的问数效果，前提是要有一个明细级的指标语义知识库。第一项准备工作是高质量的 DWD 层明细模型；第二项准备工作是在 NoETL 指标平台基于明细数据进行逻辑建模并将原子指标和维度进行标准化的定义和管理：一方面明细数据可以确保完整的数据覆盖度，不会因为对数据的多层加工造成信息损失，保障从汇总数据下钻查看明细；

另一方面，基于标准的原子指标和维度才能保证“一次定义、处处使用”，保障数据查询结果的准确性。

同时，基于明细级的指标语义知识库，不需要投入大量精力为大模型准备大量语料，前期投入工作量小， Aloudata Agent 不依赖提前定义指数级的派生指标，基于指标语义层丰富的函数能力，支持用户在灵活问数的时候快速衍生派生指标，基于原子指标和维度进行灵活组合，降低了智能分析 Agent 的前期投入，提升了问数场景的覆盖率。

在此基础上，指标平台要有较强的语义建模能力、复杂指标定义能力、快速衍生能力和高性能查询加速能力。以上三方面要素共同保障了数据覆盖的完备度、指标口径的一致性，做到数据查询的准确性、分析的灵活性与时效性三者之间的最佳平衡。从数据治理的视角看，在指标平台基于明细模型进行基础度量和维度的标准化定义与管理，这个指标定义与沉淀的过程本身也是数据治理的过程。

Q11.能分别聊一下做明细宽表和搭建指标定义模型的优缺点么？

物理宽表经过了一些加工处理，一方面存在信息的损失，比如不支持查看明细，另一方面，宽表间容易出现指标定义和维度的冗余，因此在分析的灵活性和口径的一致性方面存在局限；而基于明细数据的逻辑建模不存在上述问题，技术难点在于查询性能的保障。物理宽表用空间换时间，预计算开销比较大；逻辑建模结合 NoETL 的物化加速机制可以提高物理表的复用度，根据查询行为优化物化任务，是一种按需物化的思路，同时也降低了人工 ETL 任务运维和治理的负担。

Q12.知识库具体怎么设计的都维护哪些内容？

知识库一方面包含明细级指标语义层，包括指标元数据、维度元数据、指标血缘关系和模型关联关系另一方面，知识库也可以沉淀企业黑话、常规术语和分析思路。

Q13.MQL 对于子查询如何实现呢，比如碰到环比、同比数据，需要使用 with、case when 以及更多的子查询场景？

Aloudata CAN 指标平台内置的函数体系包含上述计算逻辑，API 支持该类查询调用。

Q14.如果数仓里面除了日度指标还有聚合指标，如近 30 天 XX 均价。如果问 3 月份 XX 均价。语义层怎么判断，还是说剔除这类指标？

Aloudata CAN 指标平台支持多次聚合类指标定义和查询，虽然只提前定义了比如客单价的指标，用户问的时候，可以基于多次聚合类语义定义能力，快速衍生出“近 30 天日均客单价”的指标，大大降低指标语义的前期准备工作。

Q15.指标口径比较复杂，需要多张事实明细表关联后处理，这类场景怎么解决？

Aloudata CAN 支持跨多表（含多事实表和多维度表）的逻辑建模和指标定义，对关联的表的数量没有任何限制。针对大数据量、高复用度的指标查询，可以配置物化加速方案提升查询性能。

Q16.指标和维度的关联关系怎么维护？

首先是维护好 DWD 层明细数据；其次是在指标平台做好逻辑模型的维护，确保表之间的关联关系准确；再次是做好原子指标和维度的规范定义与管理；在此基础上还要持续维护派生指标口径；Aloudata CAN 指标平台支持自定义指标管理属性、审批流程和历史版本，确保指标定义/更新即治理。

Q17.指标定义和梳理谁来完成？用户是否需要熟悉业务数据，或者数据结构，或者是数据逻辑？

用户两种角色：数据人员和终端业务用户。数据人员负责数仓 DWD 层模型维护、指标平台数据集的接入与逻辑建模、基础度量和维度的定义与管理；终端用户基于自身的需求，拖拽指标与维度进行快速分析，或通过 Chat BI 进行自然语言分析，无需理解数据结构。

Q18.派生指标会放到问数的数据集里面吗？

派生指标的元数据会包含在语义层知识库中；Aloudata Agent 也支持未定义的派生指标在查询时动态生成。

Q19.问数派生指标是什么场景会触发调用，而且派生指标模型可能很难理解，怎么保证筛选准确？

如果大模型对接的指标语义层中没有提前定义派生指标，则用户问数的时候都会检索原子指标，根据用户问题基于原子指标+指标要素（统计周期、业务限定、衍生方式）快速生成派生指标。如果大模型对接的指标语义层中包含派生指标和原子指标，则根据用户问题做意图识别，根据向量数据库和分词检索等能力检索出来最匹配用户意图的指标，可能是原子指标也可能是派生指标，用户可以看到检索的过程和结果。如果用户的问法比较模糊，检索的指标和想要看到的指标不一致，可以再进行调整干预。

Q20.对于没有 SQL 基础的用户，他怎么知道查出来的指标是否是自己想要的？

Aloudata Agent 将整个分析过程透明化，用户可以看到大模型检索出来的指标、维度、统计周期、筛选条件是什么，基于检索的指标和维度最终返回查询结果的整个过程都是业务化、透明化的，不需要懂 SQL；极少情况下，查询出来的指标不是自己想要的，用户也可以去调整指标、维度、筛选条件等，做到了用户可调整可干预。

Q21.如果需要做多角色权限的控制，那么在设计数据库和知识库的时候，应该提前做哪些数据分区的准备吗？

可以在指标平台进行数据行列权限的配置，执行查询 SQL 的时候会自动进行权限校验。

Q22.怎么区分问题的复杂度？

可以从几个方面来区分问题的复杂度：问题的类型：简单问数、复杂的指标归因、综合分析报告等；单一问题还是多问题：用户的一个对话中是只有单个问题，还是包含多轮对话；问题中指标计算逻辑的复杂度：比如，只是简单的求和，还是有多层加工逻辑（如先求和再求平均再做排名之类）。

Q23.指标结果是通过明细表和维度表关联聚合先计算出来的吗？

我们支持两种方式：一种是实时计算，用户问数的时候，根据涉及的指标和维度实时计算；另一种是预计算，基于 NoETL 指标语义层的物化加速能力，将常规的指标和维度的计算结果落表存储。指标平台本身是一种按需物化（结合数据量与复用度）、ETL 任务自动化（无需人工调度与运维）的机制。

Q24.用过程中，这个指标数据存储在哪里。是回传到连接的库还是会缓存在 Aloudata 里？

没有创建物化方案的时候，指标数据不存储，Aloudata CAN 只存储指标元数据信息，查询时连源表实时计算；创建了物化方案后，在指标平台会生成物理表，存储在对应的 MPP 计算引擎中。

Q25.归因是模型的总结，还是你们有 COT 的分析思路？

归因使用的是指标平台的功能；大模型从对话中识别归因的意图，结合语义知识库召回正确的指标和维度，再通过 MQL 调用指标平台执行查询和归因。

Q26.Aloudata Agent 是集语义理解和知识问答于一体吗，还是先小模型理解语义，然后再调用大模型回答？

集意图理解和数据查询与分析的问答于一体；多 Agents 架构，根据不同的子任务调用不同的 Agent、模型和工具来执行。

Q27.ReAct 的架构是通过大模型来进行复杂问题拆分，还是通过业务逻辑代码进行复杂问题 ReAct 的？

Aloudata Agent 充分利用大模型的推理能力，通过 COT 和 React 来进行任务规划与拆解，不需要提前通过 Prompt 来维护复杂问题的拆分思路。

Q28.基于 ReAct 架构如何解决上下文长度超限的问题？

我们通过 Tools 和 ReAct 拆分子任务进行了特殊处理，尽可能规避 Tokens 过长的限制。

Q29.请问 toB 的场景下，我看都是按单个模型查询的，如果不先选择模型而是通用提问会不会查不出来或者性能不好？

Aloudata Agent 本身是多 Agent 协同机制，会根据意图解析调用不同的 Agent 和大模型执行各类子任务。

Q30.业务看到的数据都是从最细粒度生成，那怎么保证查询性能？

Aloudata CAN 指标平台内置物化加速策略，针对大数据量、高复用性的指标和维度可以配置物化加速方案；系统根据加速配置自动生成预计算表与任务，无需人工干预；业务在问数的时候，系统会自动进行查询路由改写，自动匹配到最优的物化表；对于用户来说不用再关心底下的表和字段，只需从业务视角关注从哪些指标和维度角度看数。

Q31.如果生成的查询会造成全表扫描，可能把数据库拖死，有拦截机制吗？

一方面，我们会做 SQL 优化，比如模型关联键的筛选下推、同层 AGG 的合并、智能日期查询筛选、基于 RBO 规则的 SQL 优化；另一方面，我们提供按需物化加速能力，可以先根据明细数据进行汇总预计算，查询请求会自动路由到预汇总的物化表来执行。

Q32.Agent 要落地于企业的话，那企业内是否一定要至少有一个 OLAP 数据库呢？

保障灵活动态的数据查询需要有性能较好的查询引擎。

Q33.物化底层用的 Doris 吗？

目前支持 Apache Doris、SelectDB、StarRocks 和 Databricks 四种引擎；物化加速机制不依赖引擎自身的物化视图功能，是 Aloudata 自研的物化加速策略引擎。

Q34.产品底层是基于哪个大模型？

我们基于场景和大模型的特性，考虑到 ROI，采用了模型组合。在指标检索场景，我们使用的是 Qwen 2.5 72B 模型，开销比较小；如果是复杂问题，我们使用的是 DeepSeek V3 模型，基于推理模型自动进行任务拆解。当然在客户场景中，我们可以开放对接更多模型，综合考虑成本和性能的平衡调用不同模型处理不同任务。

Q35.提问的时候，可以指定指标或业务分类吗？只针对某个特定的业务领域来提问和回答？

可以的。

Q36.对业务来说，和传统的 BI 有什么区别呢？Aloudata Agent 未来可以直接替代传统的 BI 系统吗？

降低了数据分析的专业性门槛和数据呈现的复杂性；比传统 BI 工具的数据覆盖度广，并确保了指标口径的一致性。短期来看，智能问数和 BI 报表是一种互补的关系。对于固定看板场景，看报表会比反复问数更方便；对于没有现成报表支持的分析需求，使用 AI 问数会更加方便。长期来看，AI 问数方案也会持续探索将固定看板和灵活分析相结合（如，将问数生成的结果固定为报表），提供更加高效和丰富的用户体验。