主题
数据建模
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
138 道问题
本页为第 51–100 题，共 138 题。
A · 专业解题与实现8
- 离线评估持续提升，线上却出现特定用户群退化。你会检查哪些数据泄漏、切片覆盖和部署差异？
- 工作台里有数百个对象，用户会按客户、状态、负责人或时间查找。现有导航按组织架构分组，用户常找不到目标。你会如何重新设计分类，并验证查找效果？
- 用户可在手机离线修改资料，同时也可能在网页端编辑；设备恢复联网后必须同步，且不能静默覆盖有价值的更改。你会如何设计版本、冲突检测、合并和用户确认机制？
- AI 助手会从多个业务系统检索文档，而用户在不同系统中拥有不同权限。你会如何确保检索、缓存、摘要和引用都遵循原文权限，并处理权限撤销？
- 一次业务规则修正要求重算多个服务产生的历史记录，但部分消费者已经发送通知或执行外部动作。你会如何列出影响范围，决定哪些历史数据需要重新处理，并防止重复触发外部操作？
- 一个模型开始返回结构化 JSON，移动端、服务端和分析任务按不同节奏升级；新字段可能缺省或改变枚举值。你会如何定义输出接口约定、校验失败处理和版本兼容？
- 新模型的总体任务成功率持平，但不同语言、设备和使用经验的用户表现差异扩大。你会如何划分评估群体、控制样本量风险并决定是否继续扩量？
- 团队需要保留真实用户对话来复现模型错误，但日志包含个人信息和敏感业务内容。你会如何设计最小采集、脱敏、访问授权和保留期限，同时保留足够的调试价值？
当前目标在这里暂无匹配题。 ·
B · 业务理解与领域建模41
- 不同业务线都使用“有效客户”指标，但有的按付费、有的按活跃、有的按续约可能性定义。你会如何判断哪些定义应该统一，哪些应该保留为不同概念？
- 推荐和风控团队都需要“近30天消费”特征，但一个以自然日为窗口、另一个以精确小时滚动，且退款处理不同。你会如何判断能否共享特征定义？
- 训练数据里某个风险值大多完整，线上服务却常用默认值代替，模型效果也随之波动。你会怎样查明问题来自数据采集、计算时间、缺失处理还是实现差异？
- 多个模型、运营规则和报表共用一个核心特征，但上游业务定义已经变化，部分消费者暂时无法迁移。你会如何管理新旧定义、所有权和迁移顺序？
- 业务将一项服务的商业规则从免费试用改为满足条件后返还费用，但历史订单仍按旧条款签订。你会如何演进模型和流程，确保新旧交易都能被正确解释？
- 供应商 API 将过去单一的“已交付”状态拆为“已发出”和“已签收”，但历史数据没有区分依据。你会如何更新领域模型、对外接口约定和相关报表？
- 多个团队对“已完成”“待验收”和“暂停”的定义不同，汇总数据因此失真。你会如何设计共同状态模型和转换规则？
- 一个用户可以属于多个组织，并在不同组织中扮演不同角色。你会如何建模身份、成员关系和权限，避免把账号与业务角色混为一谈？
- 客户在账期中途升级、降档或暂停订阅，销售和财务对收入确认规则不一致。你会怎样明确规则并处理历史账单？
- 业务报表同时混用订单、订单行和支付尝试，指标在不同页面对不上。你会如何确定事实粒度并验证聚合定义？
- 数据库已删除客户记录，但变更数据捕获（CDC）管道和下游汇总视图仍保留旧值。你会如何追踪删除事件、更新相关视图并验证清理完成？
- 两个模型调用同名特征却得到不同值，原因涉及默认值和缺失数据处理。你会如何建立接口约定与兼容验证？ 追问：如果关键特征的刷新延迟超过实时决策窗口，你会怎样决定使用陈旧值、回退值还是拒绝决策？
- 一个订单会经历已创建、待确认、处理中、部分完成、取消和退款等状态，多个页面和服务对“完成”理解不同。你会如何建模状态、事件和合法迁移，避免各端自行解释？
- 用户在一个计费周期中途升级套餐，随后申请退款；合同规定按剩余服务时间计算，但促销折扣和税费也参与结算。你会如何拆解规则并设计可追溯的金额计算？
- 用户在周一点击活动链接，周二完成购买，但购买事件因客户端离线到周五才上传。你会如何定义事件发生时间、上传时间、判断渠道贡献的时间范围和历史补算规则，让结果可以解释？
- 一个数据库字段已被新字段取代，但仍有报表、导出和外部集成在读取旧字段；直接删除会造成静默错误。你会如何规划兼容迁移、消费方确认和最终删除？
- 企业客户用一个合同开通多个部门，员工可能跨部门使用，管理员也可能代多个账号操作。你会如何区分组织、合同账号、个人身份、成员关系和授权范围？
- 同一产品功能会按客户合同配置、按实验分组调整，还受地区规则限制；分析团队需要解释某次用户体验对应的配置组合。你会如何建模配置对象、适用范围、生效时间和决策来源？
- 管理仪表盘展示的总转化率无法解释是哪类客户、哪个流程环节造成变化；团队希望按渠道、套餐和地区下钻，但不同维度数据粒度不同。你会如何定义事实粒度和可汇总规则？
- 一个跨团队目标拆成多个项目，项目中又产生常规任务、风险事项和事故；复盘时很难还原某个结果由哪些决策和工作推动。你会如何建模目标、项目、工作项、事件和证据之间的关系？
- 业务人员可以提前编辑规则，审核通过后定时发布；旧版本仍被部分用户和异步任务引用。你会如何建模草稿、审核、发布、生效时间及版本回退？
- 一次订单收入分给平台、服务商和渠道方，数周后部分退款；其中一方已经结算且当前余额不足。你会如何表达分账规则、退款责任、追偿和对账状态？
- 业务报表需要统计每次状态变更的耗时，运营页面只需显示对象当前状态；团队把两者放进同一张宽表后，更新覆盖了历史。你会如何拆分事实、快照和当前状态模型？
- CRM、计费和产品日志分别使用客户编号、合同编号和匿名设备标识，业务分析需要还原同一客户的完整生命周期。你会如何设计身份映射及其置信度、时间有效性和纠错能力？
- 多个团队共同维护客户资料，发生数据错误时没人确认哪个系统是事实源；不同系统也会互相回写。你会如何划分字段所有权、权威来源、同步方向和争议处理？
- 设备上报累计计数，但更换设备或修正数据时计数会重置；数据平台还可能补录历史事件。你会如何定义增量、重置标记、负差值和重算边界？
- 全球用户的日活特征按自然日统计，但产品、数据仓库和模型服务分别使用用户时区、UTC 和服务器时区；月末附近结果经常不一致。你会如何定义时间边界和版本定义？
- 计费算法从按自然月调整为按服务日计算，新规则只适用于新合同；旧合同跨越发布日，客服仍需解释历史账单。你会如何版本化规则、合同适用范围和账单快照？
- 业务分类会新增、合并或改名。历史报表既要按当时定义复现，也要按当前规则比较。你会怎样保存原始分类、映射版本和报表定义？
- 事件生产方准备把字段从字符串改为结构化对象，但一部分消费者部署周期较长，另一些会把未知字段丢弃后再写回。你会如何安排双写、版本协商、迁移和终止旧格式？
- 历史事件中的客户归属字段被发现写错，需要批量修正并重新计算下游指标；同一事件还可能触发通知和合作方回调。你会如何区分数据重算与重新触发外部操作，并避免重复影响？
- 会计人员使用一个登录身份管理多家法人主体，每家主体有独立合同、账单和审批人；某些集团报表又允许跨主体汇总。你会如何建模用户身份、主体成员、资源归属和跨主体权限？
- 多个用户针对同一故障提交工单，有些可以合并处理，但各自有不同合同期限、沟通记录和补偿资格。你会如何建模主问题、关联工单、个体承诺和关闭条件？
- 不同渠道销售的套餐显示名称相同，但合同包含的功能、额度和续费条件不同；用户升级时可能从一个渠道切换到另一个。你会如何区分展示目录、可售方案、合同版本和实际权益？
- 客户可以用积分抵扣部分金额，再使用现金优惠券；积分可能由平台或合作方承担，取消时还要恢复部分积分。你会如何拆分支付、折扣、积分负债和退款规则？
- 企业按活跃座席付费，但部分员工轮班共用账号，另一些人拥有账号却从未登录；合同对“活跃”没有清晰定义。你会如何确定计费实体、“活跃”的定义和争议证据？
- 订单有多层子项、运费和税费，退款可能只针对某些子项；现有报表把订单头与明细直接关联后总金额翻倍。你会如何建模粒度和汇总定义？
- 销售团队按区域层级汇总业绩，年中区域拆分后，过去报表需要保持原样，未来报表则按新层级计算。你会如何表示组织版本、生效时间和汇总归属？
- 部分交易明细需要按政策保留多年以支持审计，但产品分析团队希望继续用于用户分群和功能实验。你会如何建模用途授权、保留期限和访问视图？
- 用户的交易先进入行为特征窗口，数天后因退款或风控撤销；下游模型和报表已经消费该特征。你会如何定义撤销事件、窗口重算和影响传播？
- 新用户缺少行为历史，特征管道将缺失值统一填成全体均值，模型因此对“没有观察”与“表现普通”给出相同判断。你会如何表达冷启动状态和可用证据边界？
当前目标在这里暂无匹配题。 ·
D · 交付执行与持续运营1
当前目标在这里暂无匹配题。 ·