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:

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"]
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

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
“we start by connecting new data sources transforming and cleaning the data using qurator our own implementation of data form”transcript, stated
“then we train models on our own implementation of Vex AI pipelines”transcript, stated
“after we leverage ER everything that that we used before for batch processing dashboard and realtime prediction and finally for chatbots”transcript, stated

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
“we maintain a centralized mlop team that standardized tools and development practice through an unified framework”transcript, stated
“the decentralized team have a better understanding of the business problem in the specific domain”transcript, stated
“this is also has the advantage that we are no longer dependent on gcp service but on implementation of the robber”transcript, stated

Models used: traditional machine learning models · large language models · Vertex AI Pipelines · statistical forecasting models · recommendation models · chatbots · classification models · parsers

Scale

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.

“we develop custom rappers around gcp Ena us to meet our unique cicd requirement”transcript, stated
“if we need to change vertex pipeline we only need to point to another qflow pipeline service”transcript, stated

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.

“the only part that is centralized is the maintenance and creation of this of the of the framework”transcript, stated
“each ER chapter we call it chapter but it's the each business unit has their own environment and their own ecosystem”transcript, stated

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.

“where the supervisor can overwrite some prediction as they are mainly a suggestion to the supervisor”transcript, stated
“the final decision and responsibility is still in the dispatcher”transcript, stated

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.

“in the first iteration to ask to a large language model to create score for this category for each destination”transcript, stated
“the second part is to um train a standard machine learning model”transcript, stated

Patterns

synthetic-data-generation (data)

LATAM uses an LLM to generate qualitative destination scores, then feeds those generated features into a traditional recommender model.

“We Invented some categories that could be Beach quality night life safety nature Sport Life Etc”transcript, stated
“ask to a large language model to create score for this category for each destination”transcript, stated

human-in-the-loop-gate (governance)

Safety-sensitive fuel recommendations remain suggestions, with supervisors able to override predictions and dispatchers retaining final responsibility.

“where the supervisor can overwrite some prediction as they are mainly a suggestion to the supervisor”transcript, stated
“the final decision and responsibility is still in the dispatcher”transcript, stated

observability-tracing (operations)

Cosmos includes data drift monitoring, data quality checks, SRE practices, Backstage cataloging, A/B tests, events, and a measurement team.

“our approaches includes monitoring for data drift ensuring data quality and applying Sr practices”transcript, stated
“we use backstage from Spotify H that's an open source H tool and we centralize all the information of our data products”transcript, stated

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.

“we have to do AV testing so we normally we can choose or in a specific zone or like random percentage of people”transcript, stated
“a separate team that's called a measurement team that uses Cal inference to determine how much impact do we have”transcript, stated

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.

“development integration and production we maintain strict isolation between environment”transcript, stated
“production is only touched by our c cicd that is currently ER Cloud build from gcp”transcript, stated

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.

“decentralized data strategy within each domain”transcript, stated
“to ensure consistency we maintain a centralized mlop team”transcript, stated

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.

“we develop custom rappers around gcp Ena us to meet our unique cicd requirement”transcript, stated
“we are no longer dependent on gcp service but on implementation of the robber”transcript, stated

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.

“this feature will help us to train a machine learning model afterwards with more qualitative data”transcript, stated
“historical passenger preference and and then we store all that all that data in a data warehouse”transcript, stated

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.

“our goal is to machine learning ER algorithm algorithm to improve this decision”transcript, stated
“the final decision and responsibility is still in the dispatcher”transcript, stated

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.

“you can have a model in one week the the the slowest part is always H the integration into the company system”transcript, stated
“sometimes it can be quick less than a month sometimes it takes H three to four months”transcript, stated

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.

“we TR TR models in development and then promote them to production enjoying deterministic Behavior between both environment”transcript, stated
“it requires data access in the development stages we achieve this with data policies where data is Harsh or treated according”transcript, stated

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.

“today we are very integrated with gcp so this presentation may seem like a gcp advertisement”transcript, stated
“allowing us to change services transparently for our end users”transcript, stated

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.

“no Model start development unless a group inside the company in a specific domain is responsible for use promote and give feedback”transcript, stated
“to have the definition of outcome and the change management in order to start coding any product”transcript, stated

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
“our approaches includes monitoring for data drift ensuring data quality and applying Sr practices”transcript, stated
“every time we do uh an implementation on the on the we the web page that is like for this particular recommender system we have to do AV testing”transcript, stated
“a separate team that's called a measurement team that uses Cal inference to determine how much impact do we have”transcript, stated

Outcomes

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.

3 supporting quotes
“currently we can do it in less of a week including exploration”transcript, stated
“cost saving in the order of million of dollars and also reduce aircraft on the ground”transcript, stated
“we currently affect a significant portion of the company's Revenue”transcript, stated