Evaluation-Driven LLM Production Workflows with Morgan Stanley and Grab Case Studies

openai · Tech · year n/a · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: applied LLM evaluation for production customer deployments

OpenAI needed to show how production LLM customers can move from vague prototype judgments to reliable eval loops that guide retrieval, prompting, fine-tuning, and cross-team model improvement.

Constraints:

• Many customers start with little evaluation infrastructure.
• Prototype evals must be small enough for human scrutiny but concrete enough to drive improvements.
• Retrieval quality, final-answer quality, and model/fine-tuning choices need different metrics.
• Vision systems require domain-specific data and labels, not generic model impressions.
• Eval processes must fit CI/CD and communication between customer teams and model providers.

Architecture

The OpenAI talk presents evaluation-driven workflows through Morgan Stanley and Grab. Morgan Stanley began with about five concrete prototype eval examples for an internal RAG chat app, used limited rollout and thumbs-down sampling to identify document recall as the bottleneck, then improved vector-database retrieval and nightly CI/CD-style testing. Grab used a more mature vision evaluation framework to identify road-sign and lane-count weaknesses, communicate gaps to OpenAI, and co-develop vision fine-tuning improvements.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  prototype-eval-examples["Prototype eval examples"] --> limited-rollout-feedback["Limited rollout feedback"]
  limited-rollout-feedback --> focused-metric-workstream["Focused metric workstream"]
  focused-metric-workstream --> iteration-loop["Iteration loop"]
  iteration-loop --> ci-cd-eval-gate["CI CD eval gate"]
  ci-cd-eval-gate --> production-deployment["Production deployment"]

Components

Data flow

Customers start with written-down prototype examples, run limited rollouts, collect user feedback and failure cases, turn those into retrieval or model-specific evals, iterate on prompts, retrieval, embeddings, and fine-tuning, and integrate trusted cases into CI/CD so core use cases stay protected as the system changes.

Why this architecture

The talk argues that evals should begin small and concrete because early human-readable examples reveal bottlenecks faster than large low-quality spreadsheets. As systems mature, the evals become shared infrastructure for CI/CD, retrieval tuning, model comparison, fine-tuning, and communication between customers and OpenAI.

Models used: OpenAI eval product · OpenAI fine-tuning · Morgan Stanley RAG chat · Vector database retrieval · Embeddings · Grab vision fine-tuning · Autograder

Scale

• Morgan Stanley's first useful eval set was about five examples.
  “honestly this is like a handful. It's like five.”transcript, stated
• Morgan Stanley's relevant-document access metric moved from 20% to 80%.
  “moved up from 20 to 80%.”transcript, stated
• Morgan Stanley reached 98% adoption as a success signal.
  “something that was useful to these folks at you know 98% adoption was ultimately the the the sign of success”transcript, stated
• Grab saw impact from literally a hundred vision fine-tuning examples before scaling up.
  “they were seeing an impact uh with with literally a hundred um different examples.”transcript, stated

Alternatives considered (roads not taken)

Start with a large exhaustive eval spreadsheet.

Rejected because: The talk says early evals should start with a few compelling concrete examples rather than a 12-dimensional spreadsheet.

Stay at vibes-only evaluation.

Rejected because: Vibes can help early prototyping only if they are written down and tracked.

Fine-tune before trying a new base model.

Rejected because: The speaker recommends first evaluating whether the model works without fine-tuning.

Patterns

eval-driven-development (production LLM workflow)

The talk centers evals as the starting point for retrieval tuning, prompt iteration, model selection, and fine-tuning.

rag-retrieval (Morgan Stanley document search)

Morgan Stanley tuned vector database retrieval and embeddings to improve document recall for its internal chat application.

human-in-the-loop-gate (eval labeling)

Small eval sets remained human-labeled and human-reviewed during early Morgan Stanley iteration.

fine-tuning-adaptation (Grab vision)

Grab used trusted vision evals to guide OpenAI vision fine-tuning for road signs and lane counts.

Tradeoffs

Start with a small written eval set.

Chose Five concrete examples over Sourcing a hundred broad examples immediately.

Rationale: A high-quality handful gave clearer signal than a large repetitive first pass.

Focus Morgan Stanley work on retrieval recall first.

Chose Vector database and embedding/retrieval tuning over Trying to improve all application stages at once.

Rationale: User feedback and early failures showed recall was the dominant bottleneck.

Use evals to tune vision-token tradeoffs.

Chose Vision fine-tuning parameters informed by evals over Blindly increasing image tokenization or fine-tuning specificity.

Rationale: More tokens and specificity can improve representation but increase cost and overtraining risk.

Gotchas (what bit them)

Large early eval sets can be low-value repetition.

Root cause: Teams may generate many similar or uninsightful cases before clarifying what truly matters.

Resolution: Start with a few concrete prototype examples and get them right.

Thumbs-down feedback is not a final eval.

Root cause: User feedback is noisy and mainly useful for finding patterns to sample.

Resolution: Use feedback to identify bottlenecks such as retrieval, then build focused metrics.

Vision models struggled with local road-sign and lane-count cases.

Root cause: General model data skewed toward North American signs and lacked enough domain-specific examples.

Resolution: Grab used evals to collect hard examples and guide vision fine-tuning.

Evaluation

The workflow starts with written prototype evals, limited rollout feedback, human-labeled examples, focused metrics such as document recall, CI/CD integration, model/prompt comparison tools, and domain-specific vision evals for Grab.

Metrics: Document recall · Final answer summarization quality · User thumbs-up/down sampling · CI/CD core use-case pass · Lane count accuracy · Sign localization · Vision fine-tuning improvement

Outcomes

• Morgan Stanley improved relevant document access from 20% to 80%.
• Morgan Stanley reached 98% adoption as a success signal for the internal tool.
• Grab used trusted vision evals to co-develop OpenAI vision fine-tuning and improve lane-count and sign-recognition metrics.
• The talk positions evals as the shared language for customer teams and model-provider teams.

The case gives concrete progression: about five initial Morgan Stanley evals, a 20% to 80% recall improvement, 98% adoption, and Grab seeing impact with roughly 100 vision examples.