# Data Quality's Impact on Large Language Models

Mona Rakibe & Maxim Lukichev, Telmai | LLMs in Production 2023 | 26:41

Source: https://www.youtube.com/watch?v=4iAw8eUMlt8
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/data-qualitys-impact-on-large-language-models
Published: 2023-11-02
Tags: data-quality, fine-tuning, monitoring, observability

## TL;DR
- Poor data quality lowers model performance and raises the cost of training and fine-tuning large language models.
- Enterprise LLM projects often combine data from many systems, so missing, duplicated, malformed, stale, or inaccurate records can grow worse through transformations and joins.
- Data quality checks should begin before model training and continue in production, where bad data can also make a good model return unreliable answers.

## Summary
Mona Rakibe and Maxim Lukichev argue that data quality directly affects the cost and usefulness of enterprise LLM projects. Companies are bringing years of data from many systems into classification, search, summarization, and chat applications. That data often contains missing values, duplicates, malformed fields, inaccurate records, stale information, and class imbalance. Transformations and joins can amplify these defects. Maxim explains that checking a small sample or writing manual SQL checks is not enough for large, changing datasets. Data profiling and observability can identify distribution shifts, truncation, duplicate records, and other anomalies across the full dataset. The talk also discusses allowing valid records to continue through a pipeline while separating suspicious data for review. In their experiment, injecting common data problems into a book-genre fine-tuning dataset reduced precision. Their conclusion is that data quality belongs at the start of the LLM architecture and must also be monitored when models serve enterprise data.

## Key ideas
### Enterprise LLM projects depend on old, distributed data
[03:32](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=212s)
Mona says enterprise teams are adopting LLMs for internal document classification, search, summarization, and chat interfaces. Much of the source material has accumulated over years or decades and sits in different formats, storage systems, and organizational silos. Companies often prefer open-source models because enterprise data raises privacy and licensing concerns. In conversations with large businesses, Mona says the main objections to adoption include cost, security, and data quality. The quality of the input affects the return they get from an LLM, just as it affects traditional analytics and machine learning.

### LLMs magnify familiar data quality problems
[08:28](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=508s)
Maxim says companies often do not know how bad their data is until they try to use it. LLM fine-tuning can magnify the problem because teams repeatedly feed large datasets into experiments, inspect failures, change the data, and run the process again. That cycle consumes infrastructure and staff time and can produce unpredictable results. He lists missing values, imbalanced datasets, polluted records, duplicates, malformed fields, invalid values, inaccurate measurements, and stale data. Data defects introduced early can become more damaging after enrichment, transformations, and joins.

### Enterprise data requires broad integrations and full-scale analysis
[14:12](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=852s)
Maxim says LLM projects pull information from CRM systems, semi-structured sources, the web, internal databases, ticketing systems, and legacy systems that may not support simple SQL queries. Some enterprise and medical data is encrypted at the record level. Master data systems can also contain deeply hierarchical JSON structures that combine information from many sources into a single record. Teams need to understand whether these inputs are reliable before using them. Analyzing only a small random sample may reveal what exists, but it cannot measure accuracy or expose blind spots across the full dataset.

### Manual anomaly checks leave teams with little confidence
[17:47](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=1067s)
A common starting point is to write SQL queries and inspect attributes one at a time for missing or unusual values. Maxim calls this manual, expensive, and error-prone. He recommends profiling and statistical analysis that can examine larger volumes and identify unusual value lengths, distributions, and patterns. The system should scale from megabytes to terabytes without requiring extensive infrastructure planning. Historical analysis adds another layer by learning normal data behavior and identifying when current values or business metrics fall outside it.

### Data observability connects data quality to changing behavior
[18:55](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=1135s)
Maxim distinguishes data quality properties from data observability. Quality includes whether data is complete, correct, accurate, and fresh. Observability adds historical context, so a system can learn how an attribute or business metric normally behaves and flag a new deviation. He gives examples of duplicate records, truncated values, and sales numbers that no longer make sense for a region or customer. This matters when an LLM generates a correct query against poor data, because the application can still return an irrelevant or incorrect answer.

### Pipelines can separate suspicious records without stopping everything
[21:11](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=1271s)
Blocking an entire pipeline whenever bad data appears can protect downstream systems, but it can also delay dashboards and model updates while someone fixes a small problem. Maxim describes data cleaning and circuit-breaker patterns that split good records from suspicious ones early in the pipeline. If the suspicious portion is limited, valid data can continue while the problem is investigated. This design avoids making a whole day's processing wait for a defect that affects only part of the input. The choice depends on how much bad data can safely pass through a particular system.

### Common data defects reduce fine-tuning precision
[23:23](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=1403s)
Maxim describes an experiment using a Hugging Face model that predicts book genres from titles. The team injected problems that resemble defects seen in customer data. Truncated titles reduced precision. Mixing book titles with author fields created another failure mode. Imbalanced training data also harmed model performance when one class became much more common than another. The experiment is meant to show that data quality should be checked before fine-tuning rather than treated as a final cleanup step. Earlier checks can reduce repeated experiments, wasted infrastructure, and poor model results.

### Data quality also determines the answers an application serves
[25:15](https://www.youtube.com/watch?v=4iAw8eUMlt8&t=1515s)
Maxim extends the argument beyond training. An LLM application can generate a good query and still return bad results when the underlying enterprise data is unreliable. Users experience that as a broken application, even when the model itself is functioning correctly. This applies to systems built with LangChain and other applications that retrieve or query company data. He recommends planning data quality into the architecture, checking the dataset before model work begins, and continuing to monitor data that enters serving and retraining workflows.

## Notable quotes
- Mona Rakibe: "Data quality is the foundation of successful Generative AI, traditional ML, and data-driven initiatives." (00:54)
- Maxim Lukichev: "No one knows how bad the data is until they start doing something with this data." (08:28)
- Maxim Lukichev: "Analyzing just a sample, a tiny sample, random sample especially, is no good." (16:45)
- Maxim Lukichev: "Data quality is paramount of the architecture, not an afterthought." (25:40)

## Tools & references mentioned
- Telmai
- Hugging Face
- LangChain
- Stack Overflow
- OpenAI

## Who should watch
- You are building an enterprise LLM application from old data spread across multiple systems and need to estimate the risks before fine-tuning.
- Your team is spending time rerunning model experiments without knowing whether the dataset contains duplicates, truncation, imbalance, or stale records.
- You operate data or model pipelines and need a way to isolate suspicious records without stopping every downstream process.

## Related talks

- [Look At Your ****ing Data 👀](https://mlopstalks.com/talks/look-at-your-ing-data) (Kenny Daniel, Hyperparam, 1:05:26)
- [Want High Performing LLMs? Hint: It Is All About Your Data](https://mlopstalks.com/talks/want-high-performing-llms-hint-it-is-all-about-your-data) (Vikram Chatterji, Galileo, 33:56)
- [Data Selection for Data-Centric AI: Data Quality Over Quantity](https://mlopstalks.com/talks/data-selection-for-data-centric-ai-data-quality-over-quantity) (Cody Coleman, 1:11:01)
- [LLMs in Focus: From One-Size Fits All to Verticalized Solutions](https://mlopstalks.com/talks/llms-in-focus-from-one-size-fits-all-to-verticalized-solutions) (Venky Ganti & Laurel Orr, Numbers Station, 55:15)
- [Data Quality = Quality AI](https://mlopstalks.com/talks/data-quality-quality-ai) (Samuel Partee, Redis & Chad Sanderson, Gable & Joe Reis, Ternary Data & Maria Zhang, Proactive AI Lab Inc & Pushkar Garg, Clari Inc, 27:15)