EN
AI Engineer World's Fair

把研究原型搬进生产的三件套:交接文档、仓库结构、栈式拆分评审

Research to Reality: Bringing Frontier ML Research to Production - Vaidas Razgaitis, Higharc · Vaidas Razgaitis

15 min
AI 产品AI 编程

全片 15 分钟·真正值得盯屏约 4 分钟·3 个必看点

橙色 = 推荐必看的 4 分钟其余读导览就够
逐段导览 · 8 段
  1. 0:01 1:35

    为什么这家公司什么 AI 都用上了

    自我介绍后直接抛出业务背景:Higharc 做的家装建筑产品既要理解图纸又要做空间推理,于是把计算机视觉、推理型 agent、自训 transformer 和扩散模型几乎全塞了进去,其中一条是把扫描的手绘平面图解析成内部数据模型。

    他的方法论来自一个同时跑四类模型的真实产品,不是通用的敏捷说教。

    这段配了技术栈和产品场景的示意,扫两眼建立背景即可,细节后面都会重讲。▶ 跳到 0:01
    讲者 · Vaidas Razgaitis
  2. 1:35 3:55

    真正的瓶颈是双向的技能缺口

    把研究落不了地归因于两边都缺对方的本事:工程师写得出生产级代码却不懂视觉模型和自训 LLM 的方法论,研究员追得上最新论文却没做过要长期维护的 API。

    交接失败是组织与流程问题,不是某一方能力不行,所以别指望靠招人解决。

    全程是口头论证,画面基本停在一页标题上,边做别的事听着就行。▶ 跳到 1:35
    讲者 · Vaidas Razgaitis
  3. 3:55 7:04

    研究原型分类文档:交接的第一道闸

    提出三个抓手(让研究可被读懂、让代码库好承接、让原型能被拆解),并展开第一个:每个原型必须交出一份文档,本质是技术设计文档加 ML 定制——先写领域上下文与数据表示,再写业务目标,随后是跨仓库类型契约、持久层现状和系统架构。

    文档的合格线是「一个跨行业新来的工程师能看懂」,而持久层那一节正是软件工程师切入项目的最佳入口。

    是逐节念文档模板的口头讲解,屏幕上没有超出讲述内容的信息;建议边听边把章节名抄下来当自家模板。▶ 跳到 3:55
    讲者 · Vaidas Razgaitis
  4. 7:04 8:50

    独立的 Python 单体仓库与网关

    ML 代码从核心产品里剥出来,单独放一个 Python mono repo,内部是彼此完全解耦的微服务,研究员与服务大致一对一。所有服务共处一个 Docker 桥接网络,外部请求统一由网关把守,客户端永远不直连服务。

    一人一服务加统一网关,让研究员可以随便改内部实现而不惊动产品端。

    整段围着一张拓扑图讲,看图能一次记住服务、网关、Web 客户端三者的调用方向,比顺着话往下听快得多。▶ 跳到 7:04
    讲者 · Vaidas Razgaitis
  5. 8:50 11:00

    单个服务怎么分层,仓库底下共用什么

    拆开一个微服务的内部:业务逻辑在 services 层(调外部基础模型或在流水线里拉自家权重),外面依次包 controllers 和路由,最终暴露成独立的 FastAPI 应用,根目录放构建元数据和 Dockerfile。接着并排展示三个线上服务的目录,形状高度一致,共用同一套 CI、跑在 Modal GPU 上的 notebook 和命令行工具。

    结构统一加上写清楚的接口说明,让 AI 助手也能在仓库里自主导航,等于给研究员配了加速器。

    屏幕上是目录树和分层结构,逐层看比逐句听高效;三个服务并排那一屏值得停下来对照几秒。▶ 跳到 8:50
    讲者 · Vaidas Razgaitis
  6. 11:00 13:10

    把拆解当设计题,用栈式 PR 评审

    第三个抓手:原型验证通过后,先想清楚沿哪些轴切分这个大单体、依赖图长什么样,再用 Graphite 的 stacked diffs 落成一摞 PR——开发者在栈顶继续推进,同时按切片把下层 PR 精准派给组织里对应的领域专家。

    文档里理清的分层与类型契约会直接决定切分方案,写文档的收益在这一步才兑现。

    有依赖图和 PR 栈的示意,看图理解切分方式最快;配套的评审分派规则则要留神听。▶ 跳到 11:00
    讲者 · Vaidas Razgaitis
  7. 13:10 14:08

    三个抓手串起来的完整链路

    回收前面三条线,说明从原型文档到仓库结构再到拆解评审是一条连续链路,任何一环缺失都会让下一环的成本陡增。

    三个抓手是串联关系,只上其中一个基本等于没上。

    纯口头收束,没有新画面,听着就够。▶ 跳到 13:10
    讲者 · Vaidas Razgaitis
  8. 14:08 14:56

    自查信号:哪一环坏了怎么看出来

    给出三条可自查的症状——新人加入研究项目却不知道该盯哪里,说明文档那一环该重做;新代码没有明确的落脚点、找不到可照抄的样板、总在和旧抽象较劲,说明代码库已经撑不住了;到了拆解阶段说不清该请谁来评审,问题其实出在更上游的协调方式或仓库结构。

    这三条症状是全片最好带走的东西,回去就能对着自家团队打分。

    结语式的口头清单,画面上没有额外信息,建议边听边记下这三条。▶ 跳到 14:08
    讲者 · Vaidas Razgaitis