{
  "video": {
    "id": "OXMMN-XbxwA",
    "title": "Research to Reality: Bringing Frontier ML Research to Production - Vaidas Razgaitis, Higharc",
    "duration": 897,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": "Online"
  },
  "analysis": {
    "video_id": "OXMMN-XbxwA",
    "title": "Research to Reality: Bringing Frontier ML Research to Production - Vaidas Razgaitis, Higharc",
    "one_liner": "Higharc's labs team treats shipping ML research as a systems-and-process problem with three levers: a mandatory 'research prototype taxonomy' handoff doc, a Python mono repo of one-microservice-per-researcher FastAPI services behind a gateway, and stacked-PR decomposition in Graphite for asynchronous expert review.",
    "summary": "Vaidas Razgaitis, a senior research engineer on Higharc's labs team, describes the baton pass between ML researchers (fluent in papers, not production APIs) and platform/backend engineers (fluent in production, not computer vision or LLM training). He argues the fix is process and structure, not talent: every prototype ships with a written research prototype taxonomy document (a technical design doc with ML-specific twists), lands in a mono repo of cleanly isolated, fully decoupled microservices, and is decomposed into stacked PRs reviewed asynchronously by subject-matter experts. He closes with diagnostic questions for each of the three levers so teams can tell which one is failing.",
    "key_points": [
      "Higharc's product spans computer vision (scanning hand-sketched floor plans into their internal data model), reasoning agents for agentic user experiences, custom transformers, and diffusion models for image gen — because home building and spatial reasoning are multidisciplinary.",
      "The core problem is a two-sided knowledge gap: software/platform/infra engineers know production-grade code but not CV or LLM-training methodology; ML researchers track the latest papers but have typically never owned production-grade APIs.",
      "Lever 1 — the 'research prototype taxonomy' (RPT) document, required of all research prototypes and written in Notion. Inspired by The Pragmatic Engineer's writing on technical design docs / RFCs. Six parts: domain context (party diagrams, circulation graphs, embedding / latent-space representations), business goal, type safety (the type contract between the core product repo and the ML repo and how types stay in sync), persistence layer, system architecture (workflow? chained workflows? external LLM calls?), and the merge/decomposition plan.",
      "Researchers are deliberately told not to sink time into the persistence layer — just document how far they got, which becomes the natural first entry point for software-engineering help.",
      "Lever 2 — a Python ML mono repo, separate from the core product repo, of cleanly isolated and fully decoupled microservices, roughly one microservice per researcher (e.g. 'data-driven entity prediction' is their custom transformer model). Three microservices are in production.",
      "Architecture: clients call a gateway that guards requests and routes to the right microservice, all on one Docker bridge network. Each microservice is a standalone layered app — API layer, business logic, data layer — with services making external foundation-model LLM calls or pulling their own model weights in CI/CD, wrapped in controllers, then API routers exposed via FastAPI. Each root has metadata, build instructions, a Dockerfile, dependencies and poetry or uv lock files.",
      "Supporting layer: GitHub Actions for build/deploy, automated test suites, linting, formatting and type checks; Jupyter notebooks running on Modal for GPU compute; a CLI — all framed as tooling to help ML engineers bundle up microservices.",
      "Lever 3 — decomposition is treated as a design problem: study which axes to slice a monolithic prototype on and what the dependency graph looks like, then use Graphite stacked diffs so a researcher can keep working up the stack while a domain specialist reviews a lower PR, and tap specific subject-matter experts per slice.",
      "Repos carry cleanly documented specs specifically so coding agents can navigate them and accelerate ML researchers."
    ],
    "takeaways": [
      "Require a written handoff doc from every research prototype before engineers join — and add ML-specific sections to your standard TDD template: domain data representations, the cross-repo type contract, and how far the persistence layer got.",
      "Write the domain-context section for a hypothetical engineer just hired from JP Morgan: spell out the jargon and data representations they need before touching the project.",
      "Keep ML work in its own Python mono repo of decoupled microservices behind a gateway, with a repeatable skeleton (API / business logic / data, controllers, FastAPI routers, Dockerfile, lock file) so a new prototype has an obvious bucket to land in.",
      "Plan the PR decomposition as part of the design, and use stacked diffs (Graphite) so review is asynchronous and each slice goes to the right subject-matter expert.",
      "Diagnose which lever is broken: unclear where new staff should focus → legibility; fighting old abstractions every time research arrives → you've outgrown the codebase; can't estimate delivery dates or name the right reviewers → decomposition, pointing upstream to handoff or repo problems."
    ],
    "topics": [
      "ml-research",
      "productionization",
      "monorepo",
      "microservices",
      "code-review",
      "engineering-process",
      "technical-design-docs",
      "team-velocity"
    ],
    "tools": [
      "Higharc",
      "Notion",
      "FastAPI",
      "Docker",
      "Poetry",
      "uv",
      "GitHub Actions",
      "Modal",
      "Jupyter",
      "Graphite",
      "The Pragmatic Engineer",
      "Python"
    ],
    "quotes": [
      {
        "text": "We look at this basically as a systems and process problem.",
        "at": "02:23",
        "url": "https://www.youtube.com/watch?v=OXMMN-XbxwA&t=143s"
      },
      {
        "text": "I like to say kind of picture a software engineer who we just hired from JP Morgan. What are the kind of specific lingos and data representations that they might need to know before jumping into this project.",
        "at": "05:00",
        "url": "https://www.youtube.com/watch?v=OXMMN-XbxwA&t=300s"
      },
      {
        "text": "It's basically a mono repo of cleanly isolated and fully decoupled microservices... and it's pretty much a one-to-one researcher to microservice ratio.",
        "at": "07:10",
        "url": "https://www.youtube.com/watch?v=OXMMN-XbxwA&t=430s"
      },
      {
        "text": "We really like Graphite because it allows for asynchronous review, right? I could be working on a PR all the way up here while a domain specialist is still reviewing a different PR.",
        "at": "11:42",
        "url": "https://www.youtube.com/watch?v=OXMMN-XbxwA&t=702s"
      }
    ],
    "words": 2672
  },
  "summary_url": "/#OXMMN-XbxwA",
  "transcript": {
    "html": "/transcripts/OXMMN-XbxwA.html",
    "txt": "/transcripts/OXMMN-XbxwA.txt",
    "vtt": "/transcripts/OXMMN-XbxwA.vtt"
  }
}