AIFactory 智能数据工厂平台

AIFactory 智能数据工厂平台 · 面试深度追问 & 口述回答

聚焦你核心负责的语料集服务 + AI 标注服务，结合简历与博客真实细节。
回答风格：口语化、结构化（我做了什么 → 为什么 → 效果/思考），突出个人贡献与工程判断。

一、项目整体与个人贡献

1. 请简单介绍一下 AIFactory 项目，你主要负责哪些部分？

口述回答：

AIFactory 是华为云的 AI 训练数据管理平台，支撑样本采集、标注、测试、评估的完整数据闭环，日处理语料规模达到百万级。

我核心负责两大块：

第一是语料集服务，从创建、上传、更新、标注、基线版本到模板管理，全生命周期我都主导开发。语料支持图片、文档、音频、视频等多种模态，元文件存在 S3，数据库只存地址。

第二是AI 自动标注服务，基于 Kafka 消息驱动，对接华为内部大模型，实现了图文提取、音频提取、摘要获取、卡证提取等能力，标注结果回填到数据库。

另外也参与了微服务基础设施搭建、SSO 集成，以及后续的流水线编排和任务管理部分。

2. 这个项目里你觉得最有挑战、也最能体现你价值的是哪一块？

口述回答：

最有挑战的是大文件批量导入 + 海量标注数据写入这块。

用户经常一次导入几千甚至上万条语料，文件很大，直接处理很容易把服务器卡死或者 OOM。同时一个语料对应的标注数据可能有几十条，1 万条语料最终可能要写几十万行数据。

我主导解决了两个核心问题：
一是和前端配合做分片上传，避免接口长时间等待和内存暴涨；
二是把批量写入改成可控的循环分批，并后续优化成真正的 JDBC BATCH 模式。

这两块直接把系统从“容易挂”变成了“稳定可支撑生产导入”，是我个人贡献比较大的地方。

二、分表与性能优化

3. 语料表数据量很大，你们是怎么做分表的？查询性能怎么优化的？

口述回答：

语料表数据量非常大，我们做了两层分表：

一开始默认按语料类型分表（图片、文档、音频、视频等），避免单表过大。
后面业务发展后，又按语料集 ID 做了水平分表，进一步把压力打散。

在这个基础上，我重点做了 SQL 优化和索引调整，尤其是分页查询和多条件过滤。最终把查询响应时间从大概 3 秒降到了 200ms 左右，性能提升大约 15 倍。

这个优化是上线后真实验证过的，对用户体验提升比较明显。

4. 分表后跨表查询或者统计怎么处理？有没有遇到麻烦？

口述回答：

分表后最常见的麻烦是跨语料集或者全局统计。

我们主要做了几件事：

业务上尽量把查询限制在单个语料集或单类型内，减少跨表；
必要的全局统计用定时任务预聚合，或者走专门的汇总表；
结合 ShardingSphere 的分片策略，对能路由的查询尽量精准路由。

整体原则是：能路由就路由，必须聚合就异步预计算，避免在线实时跨大量分表。

三、大文件批量上传（高频深挖点）

5. 大文件批量上传是怎么实现的？为什么之前会卡死或 OOM？

口述回答：

早期直接上传有两个明显问题：

第一，接口要等完整文件全部接收完才会进入业务处理，大文件等待时间很长，属于无效等待，服务器资源被占着。
第二，用户一次导入几千到上万条语料时，内存很容易被打满，直接 OOM 或者卡死。

我们改成了分片上传：和前端约定每次上传大小，比如 50MB。一个 1GB 的文件就拆成大概 20 次请求。
只有最后一次请求拿到所有分片后，才去做合并、上传 S3、文件处理和数据整合。

这样每次请求都能快速返回，不会卡死，还能做上传进度条，用户体验也好很多。内存占用也稳定控制在比较低的水平。

6. 分片上传里，如果中间某个分片失败了怎么办？最后合并失败怎么保证数据一致性？

口述回答：

分片上传我们做了基本的重试和状态管理。

中间分片失败可以单独重传，不需要从头开始。
最后合并阶段如果失败，会记录失败状态，并清理已上传的临时分片，避免脏数据残留。

业务上语料状态会标记为失败或待重试，支持用户重新发起。整体保证了“要么完整成功，要么可感知失败并可重试”，不会出现半成功的状态。

四、AI 标注与批量写入（核心技术点）

7. AI 标注流水线是怎么设计的？Kafka 在里面起什么作用？

口述回答：

AI 标注用 Kafka 做消息驱动，实现语料和模型服务的解耦。

语料上传或触发标注后，生产者往 Kafka 发消息；
不同的消费者根据语料类型去调用对应的华为内部大模型（图文提取、音频提取、摘要、卡证提取等）；
模型生成标注结果后，再回填到标注数据库。

这样做的好处是：模型处理能力可以独立扩展，失败可以重试，多模态语料也能并发处理，不会互相阻塞。

8. 一个语料会产生很多标注记录，批量写入时怎么避免 OOM 和卡顿？

口述回答：

这是实际踩过的坑。一个语料可能对应几十条标注记录，用户一次导入 1 万条语料，最终要写的可能是几十万行。如果直接一次 saveBatch 或者大事务，很容易内存暴涨或者把数据库打挂。

我们先用了循环批量写入：每次控制写入数量，比如 1000 条，循环多次完成。这样把单次内存和事务大小都控制住了。

后来进一步优化成真正的 JDBC BATCH 模式，配合 rewriteBatchedStatements=true，减少网络往返，速度更稳。同时也考虑过用 Kafka 消费者侧做批量积累后再落库，或者对特别大的任务用 LOAD DATA 这类方案。

核心思路就是：控制单次写入粒度 + 真正批量 + 支持失败重试和幂等。

9. 循环批量写入还有没有更好的方式？你当时为什么选这个方案？

口述回答：

循环批量是当时最快能落地、风险最低的方案，改动小，立刻解决了 OOM 问题。

更好的方向其实有几个：

用 MyBatis 的 ExecutorType.BATCH + 定期 flushStatements 和 clearCache，比普通循环 saveBatch 更接近真正的 JDBC 批量。
直接用 JdbcTemplate.batchUpdate，绕过部分 ORM 开销，配合 MySQL 的 rewriteBatchedStatements。
架构上把落库做成异步：标注结果先写 Kafka 或队列，由专门的落库 Worker 做可控批量写入。
对超大批量离线导入，可以考虑先落文件再用 LOAD DATA INFILE，速度会快很多。

我们优先选了循环分批，是因为业务要快速止血，同时要保证幂等和可重试。后续有空间的话，可以往真正 BATCH 或异步落库演进。

10. 任务重跑时怎么保证数据不重复、保持一致性？

口述回答：

任务重跑时最容易出重复数据。

我们用 LinkedHashMap 按 corpusId + indicatorId 做去重，只保留最新记录。
同时采用批处理写入，减少数据库 I/O。
另外支持基线版本构建，重跑后的结果可以和基线对比，形成可追溯的闭环。

这样既避免了重复，也保证了重跑结果的可对比性。

五、架构与扩展性

11. 语料流水线支持 DAG 编排，这个是怎么实现的？状态怎么管理？

口述回答：

我们支持可视化配置语料处理流水线，节点包括生成、过滤、转换、标注等，整体是 DAG 结构。

后端把配置解析成可执行的 Pipeline Job，支持发起、暂停、终止、挂起等全状态管理。
每个节点执行完通过事件驱动触发下游，失败时可以根据配置决定中断还是继续。

这样业务同学可以自己搭复杂流程，不用每次都找开发改代码，扩展性更好。

12. 任务管理和指标计算是怎么做的？为什么用策略模式？

口述回答：

任务管理覆盖评测任务创建、状态同步、结果回写。

指标计算这块用了策略模式，支持准确率、召回率等多种指标。通过配置化表达式动态计算，新增指标类型时不用改核心流程代码。

PDF 报告生成用 CompletableFuture + 线程池 做成异步，系统吞吐量提升了大约 3 倍。

策略模式主要是为了把“计算逻辑”和“任务流程”解耦，方便后续扩展。

六、综合与思考类问题

13. 如果让你重新设计语料导入和标注落库，你会怎么优化？

口述回答：

如果重新设计，我会重点做三件事：

导入侧：分片上传保留，但合并和业务处理做成更明确的异步任务，状态机更清晰，失败可精确重试到某个分片或某个阶段。
落库侧：标注结果通过 Kafka 批量消费后，用真正的 JDBC BATCH 或专门的落库服务写入，并做幂等（唯一键 + INSERT IGNORE / ON DUPLICATE KEY）。
可观测性：每个语料和每个标注任务都有完整链路追踪，失败原因可快速定位，方便运维和用户自助重试。

整体还是强调异步化、可控批量、幂等和可观测。

14. 这个项目里你个人成长最大的是什么？

口述回答：

最大的成长是真正理解了“大数据量 + 高并发写入”在生产环境的坑。

以前更多是业务 CRUD，这个项目让我完整经历了分表、大文件处理、消息驱动、批量写入优化、数据一致性这些真实问题。
从“先让功能跑起来”到“让系统在百万级规模下稳定跑”，这个过程对工程判断力提升很大。

15. 面试官追问：你们分片上传的分片大小是怎么定的？有没有压测？

口述回答：

分片大小我们主要参考了常见实践和实际文件分布，最终定在几十 MB 量级（比如 50MB）。

太小会导致请求次数过多、合并开销大；太大又会回到内存和超时的问题。
上线前做了不同大小的对比测试，结合服务器内存、网络和用户上传习惯，选了一个平衡点。后续也可以根据监控动态调整。

使用建议

优先熟练这 5 个高频点：项目介绍、分表、大文件分片上传、Kafka 标注、批量写入与优化。
回答时主动带出“踩过的坑 + 为什么这么选 + 后续可优化方向”，显得有深度。
数字（3 秒→200ms、15 倍、吞吐量 3 倍等）可以讲，但语气用“大约”“提升比较明显”，避免被精确追问。
如果面试官继续深挖 DAG、策略模式、CompletableFuture，再展开简历里的内容即可。

祝面试顺利！有具体某道题想再打磨，或者想加上代码示例，随时说。