MLOps Platform for Airline Operations with LLM Integration
latam_airlines · Other · 2024 · 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: Airline operations and commercial personalization MLOps
LATAM Airlines needed to move machine-learning and LLM-enabled data products into production across many airline domains while preserving speed, environment isolation, security, monitoring, business ownership, and vendor flexibility.
Constraints:
- LATAM is a legacy airline rather than a native technology company, so change management and business-domain ownership are part of the production system.
- The airline operates across many domains, including maintenance, operations, finance, web, revenue management, recommendation, and fraud.
- Model development previously took three to four months before first production deployment.
- Safety-sensitive operational predictions, such as extra-fuel recommendations, require human dispatcher responsibility rather than automatic execution.
- The framework is integrated with GCP but must avoid exposing end users to vendor-specific service choices.
Architecture
LATAM built Cosmos, an in-house developer-centric MLOps framework that standardizes data, ML, GenAI, and visualization work across decentralized business chapters. Data sources are connected and transformed through Curator, LATAM's Dataform-like layer, then models train and predict through a custom implementation of Vertex AI Pipelines. Results are served through batch jobs, dashboards, real-time prediction APIs, web integrations, and chatbots, while monitoring checks data drift, data quality, and SRE concerns. Cosmos wraps GCP services behind custom interfaces, isolates development, integration, and production environments, and uses Cloud Build for production CI/CD. Staff ML engineers and analytics translators bridge centralized platform work into domain teams.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR Chapters["Business chapters"] --> Translator["Analytics translator"] Translator --> Staff["Staff ML engineers"] Staff --> MLOps["Central MLOps team"] MLOps --> Cosmos["Cosmos framework"] Cosmos --> Curator["Curator data transformation"] Curator --> BigQuery["BigQuery warehouse"] BigQuery --> Vertex["Vertex pipeline wrapper"] Vertex --> LLM["LLM feature scorer"] Vertex --> Serving["Serving surfaces"] LLM --> Serving Serving --> Monitoring["Monitoring and measurement"] Monitoring --> Backstage["Backstage catalog"] Backstage --> Chapters Cosmos --> CloudBuild["Cloud Build CI/CD"]
Components
| Component | Role | Interacts with |
|---|---|---|
Business chapters |
Decentralized domain teams that own business problems, domain data ecosystems, adoption, and feedback. | Analytics translator, Cosmos framework, Backstage catalog |
Analytics translator |
Bridge role that explains model behavior to non-technical users and carries feedback between business and technical teams. | Business chapters, Staff ML engineers |
Central MLOps team |
Maintains Cosmos, standardizes development practices, and defines wrappers, CI/CD, and platform features. | Cosmos framework, Staff ML engineers |
Staff ML engineers |
Bridge engineers who roll centralized platform features into domain teams and help ML engineers use the framework. | Central MLOps team, Analytics translator, Business chapters |
Cosmos framework |
In-house MLOps framework spanning DataOps, MLOps, GenAI, and DataViz with custom wrappers over cloud services. | Central MLOps team, Curator data transformation, Vertex pipeline wrapper, Serving surfaces, Cloud Build CI/CD |
Curator data transformation |
LATAM's implementation of Dataform for cleaning and transforming warehouse data. | Cosmos framework, BigQuery warehouse |
BigQuery warehouse |
Warehouse holding traffic, weather, operations, historical preference, parts usage, and other model inputs. | Curator data transformation, Vertex pipeline wrapper |
Vertex pipeline wrapper |
Custom wrapper around Vertex AI Pipelines and Kubeflow-style pipeline execution. | Cosmos framework, BigQuery warehouse, Serving surfaces |
LLM feature scorer |
LLM-backed feature generation that scores destinations on qualitative dimensions for recommendation models. | Vertex pipeline wrapper, Serving surfaces |
Serving surfaces |
Dispatcher page, dashboards, real-time prediction APIs, website backend integrations, and chatbots. | Vertex pipeline wrapper, Monitoring and measurement, Business chapters |
Monitoring and measurement |
Data drift, data quality, SRE practices, A/B testing, event tracking, and causal-inference impact measurement. | Serving surfaces, Backstage catalog |
Backstage catalog |
Centralized developer portal for surfacing information about data products across chapter environments. | Business chapters, Monitoring and measurement |
Cloud Build CI/CD |
Production deployment path that touches production exclusively through CI/CD. | Cosmos framework |
Data flow
Business chapters define data products and own adoption. New data sources flow into BigQuery and are transformed in Curator. Models train and predict through LATAM's Vertex AI Pipeline implementation, then outputs serve into dispatcher pages, dashboards, APIs, chatbots, or website integrations. Monitoring, Backstage cataloging, A/B testing, event tables, and causal-inference measurement feed visibility and impact assessment back to the domain teams and platform owners.
3 supporting quotes
Why this architecture
LATAM chose a hybrid architecture because centralized platform standards and decentralized domain ownership solve different parts of the problem. Cosmos gives developers fast, repeatable tools and production guardrails, while chapters keep domain knowledge, adoption, and feedback close to users. Wrappers around GCP services preserve vendor flexibility, isolated environments protect operations, and human override keeps safety-sensitive decisions accountable.
3 supporting quotes
Models used: traditional machine learning models · large language models · Vertex AI Pipelines · statistical forecasting models · recommendation models · chatbots · classification models · parsers
Scale
- LATAM operates around 350 aircraft across 150 destinations.“the largest airline in South America with around 350 aircraft 150 destination”transcript, stated
- LATAM has over 1,600 daily departures, roughly one departure every 51 seconds.“over 1600 daily departures if you do the math that's actually a departure every 51 seconds”transcript, stated
- LATAM has over 60,000 employees including externals.“latam is a huge company with over U 60,000 employees considering considering externals”transcript, stated
- Cosmos reduced first production deployment time from three to four months to less than one week.“four years ago a data scientist took three to four months between creation of a product and the first pass to production”transcript, stated“currently we can do it in less of a week including exploration”transcript, stated
- The extra-fuel model is deployed for flights in Colombia and Brazil and saves millions of dollars plus 4 kilotons of CO2 equivalent per year.“if you have flown with Lam in Colombia or Brazil you have experienced the recommendation from this model”transcript, stated“the impact on the company is in the millions of dollars and it it also help us to be more sustainable by Saving 4 kilotons”transcript, stated
- The parts forecasting use case maintains approximately 60,000 models.“then train and predict the model in this case we have approximately 60 60,000 models”transcript, stated
Alternatives considered (roads not taken)
Use GCP products directly as the user-facing platform
Rejected because: LATAM wrapped GCP services so end users depend on Cosmos abstractions and the platform can swap services transparently.
Centralize every model and domain environment under one team
Rejected because: The centralized team maintains the framework, but each business chapter keeps its own environment and domain ecosystem.
Let the extra-fuel model make the final operational decision
Rejected because: The model is only a suggestion; supervisors can overwrite predictions and dispatchers retain responsibility.
Use the LLM directly as the recommendation engine
Rejected because: LATAM used the LLM to create qualitative destination features, then trained a standard ML model with historical preferences and quantitative features.
Patterns
synthetic-data-generation (data)
LATAM uses an LLM to generate qualitative destination scores, then feeds those generated features into a traditional recommender model.
human-in-the-loop-gate (governance)
Safety-sensitive fuel recommendations remain suggestions, with supervisors able to override predictions and dispatchers retaining final responsibility.
observability-tracing (operations)
Cosmos includes data drift monitoring, data quality checks, SRE practices, Backstage cataloging, A/B tests, events, and a measurement team.
eval-driven-development (operations)
The web recommender is evaluated through A/B testing, website event tracking, and a causal-inference measurement team that quantifies impact.
safety-policy-enforcement (governance)
Environment isolation, CI/CD-only production access, and data sensitivity policies keep development work from leaking into production or exposing sensitive data.
Tradeoffs
Centralized platform with decentralized domain ownership.
Chose Central MLOps framework plus chapter-owned ecosystems over Fully centralized model ownership.
Rationale: A central team can standardize tools and CI/CD, while domain teams provide business context, user feedback, and adoption.
Wrap cloud services behind Cosmos.
Chose Custom wrappers around GCP services over Direct exposure of Vertex and other GCP services to developers.
Rationale: Wrappers preserve flexibility and let the MLOps team meet LATAM-specific CI/CD requirements.
Use LLMs for feature creation rather than final recommendation serving.
Chose LLM-generated qualitative destination scores plus a standard ML recommender over LLM-only recommendation decisions.
Rationale: Destination perception is qualitative, but the production recommender still needs historical preference and quantitative travel features.
Keep fuel optimization as decision support.
Chose Human-overridable recommendation page over Automatic dispatcher replacement.
Rationale: Fuel loading is safety-sensitive; the model can improve the decision while responsibility remains with dispatchers.
Gotchas (what bit them)
The hardest production delay may be organizational integration, not model training.
Root cause: Cosmos can produce a model quickly, but deployment into company systems depends on downstream team backlogs and integration work.
Resolution: Separate platform speed metrics from integration lead time, and use analytics translators and chapter ownership to reduce adoption friction.
Environment isolation creates a development-data access problem.
Root cause: LATAM trains in development and promotes to production for deterministic behavior, but training in development still requires access to potentially sensitive data.
Resolution: Use data policies that hash or treat data according to sensitivity before it is available in development stages.
Vendor lock-in can creep in even when the business wants an in-house framework.
Root cause: The platform is deeply integrated with GCP services such as Vertex Pipelines and Cloud Build.
Resolution: Hide cloud-specific services behind Cosmos wrappers so service changes do not affect end users.
ML products fail if no domain group owns use, promotion, and feedback.
Root cause: LATAM is a non-native tech company, so model outputs require change management and accountable business users before coding starts.
Resolution: Require a domain group, outcome definition, and change-management plan before model development begins.
Evaluation
LATAM evaluates platform success through deployment lead time, production model impact, drift and data-quality monitoring, web A/B testing, event tracking, causal-inference measurement, and domain feedback through analytics translators and chapter teams.
Metrics: first production deployment lead time · data drift · data quality · A/B test lift · website events · causal impact · fuel cost savings · CO2 equivalent savings · aircraft-on-ground reduction · cancelled-flight reduction
3 supporting quotes
Outcomes
- Cosmos reduced first production deployment time from three to four months to less than one week.
- The extra-fuel model is deployed for Colombia and Brazil flights and is reported to save millions of dollars and 4 kilotons of CO2 equivalent per year.
- The recommender combines LLM-generated qualitative destination scores with traditional ML and real-time website API serving.
- The inventory forecasting system maintains roughly 60,000 models and reduces stockouts, excess inventory, aircraft-on-ground events, and cancellations.
- LATAM reports that Cosmos affects a significant portion of company revenue.
LATAM presents Cosmos as a company-wide platform across a large airline with 350 aircraft, 150 destinations, over 1,600 daily departures, and more than 60,000 employees including external staff.