AI 对话日志的数仓模型怎么设计？
面试怎么回答
我会把 AI 对话数仓拆成 Session、Turn、Model Call、Retrieval 和 Tool Call 五类事实。Session/Turn 记录体验与任务结果，Model Call 记录 Token、延迟和成本，检索与工具事实负责解释链路。通过 session_id、turn_id、trace_id 关联，并建设模型、Prompt、知识库和实验版本维度。重试、迟到和反馈采用稳定业务键更新，避免把多次调用重复算成多次问答。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
同一段对话，在接口日志里是一条请求，在产品视角里是一个 Session，在 Agent 链路里又包含多次模型调用和工具调用。
如果事实粒度没先定清楚，Token、延迟、成功率和用户数很快就会被重复计算。
AI 对话数仓不能只建一张宽表，应按 Session、Turn、Model Call、Retrieval 和 Tool Call 拆分事实粒度，再用统一 ID 串联。
第一类：会话与轮次事实
Session 表示一段业务会话，记录用户、应用、渠道、开始结束时间和最终状态；Turn 表示一次用户输入及对应的系统响应，记录问题类型、回答状态、反馈和端到端耗时。
用户发一条消息可能触发多次模型调用，因此 Turn 不能直接等同于模型请求。活跃用户、会话完成率和追问率通常在 Session 或 Turn 粒度计算。
第二类：模型调用事实
每次模型 API 请求一行，记录 model_call_id、turn_id、模型与 Prompt 版本、输入输出 Token、缓存 Token、首 Token 延迟、总延迟、完成原因、重试和成本。
如果一次 Turn 重试三次，调用次数是 3，但产品回答数仍可能是 1。成本按 Model Call 汇总，体验按 Turn 汇总，两种口径不能混在一起。
第三类：检索与工具事实
Retrieval Fact 记录 Query、索引版本、过滤条件摘要、候选数量、TopK、重排和引用结果；Tool Call Fact 记录工具、参数摘要、调用状态、耗时、重试和副作用 ID。
这些子事实与 Turn、Trace 相连，才能解释回答为什么慢、为什么没有引用、是否因为工具失败而降级。
维度和敏感字段怎么处理？
公共维度包括用户、租户、应用、模型、Prompt、知识库、工具、时间和实验版本。Prompt 与模型都必须版本化，否则历史指标无法解释。
原始问题和回答不适合无边界进入分析宽表。可以保存受控明细引用、脱敏文本、分类标签和长度特征，并通过权限与审计控制访问。Metric 层尽量使用稳定 ID 和派生属性。
迟到、重试和流式更新
流式日志会乱序：模型完成事件、成本回写、用户反馈可能在不同时间到达。事实表需要稳定业务键和 Upsert 规则，同时保留事件时间、处理时间和最终状态。
不要简单按 request_id 去重全部事件。一次请求的 Started、Completed、Failed 是状态变化，应按事件类型和版本重建过程。
一个典型反例
团队把每次模型调用都当成“一次问答”。引入自动重试和 Tool Call 后，问答量、失败率和用户平均 Token 同时上升，看起来业务增长，实际只是调用链变长。
修复的关键是重新定义事实粒度，让产品行为、模型资源和工具执行分别统计，再通过 Turn 和 Trace 关联。