Ключови моменти
Най-добрият AI резултат идва от повторяем pipeline за данни, силни проверки за качество и ясни версии, не от „магически“ модел.
За да обработваш данни за AI, направи три неща подред: (1) дефинирай какъв проблем решаваш и как ще измериш успеха, (2) изгради повторяем pipeline за почистване, трансформации и етикетиране, и (3) заключи процеса с версии, проверки за качество и защита от data leakage. Обработката на данни е мястото, където печелиш или губиш 80% от качеството на модела.
В реални проекти „данните“ рядко идват чисти: липсващи стойности, разнородни формати, дубликати, шум, пристрастия, несъответствие между training и продукция. В тази статия ще ти дам практична рамка за data processing, която работи за класически ML (таблични данни), за текст (LLM/RAG), и за смесени източници.
Най-скъпата грешка е да правиш cleaning на ръка и без документация, защото после не можеш да повториш резултата.
Започни с 5 ясни отговора:
Това диктува кои трансформации са нужни. Пример: за churn модел важат времеви прозорци и „as-of“ правила; за RAG важи chunking и deduplication на съдържание.
Дори малък проект печели от „паспорт“ на данните:
Ако работиш в ЕС и/или моделът е в регулаторно чувствителен домейн, трябва да си дисциплиниран и за data governance. В EU AI Act (изисквания за high-risk системи) се акцентира върху качество на training/validation/test данните, подготовка (labeling/cleaning/updating) и проследимост на произхода.
Тук целта е да сведеш данните до последователен формат.
Провери:
Често полезни техники:
Провери:
Практика: преди embeddings/RAG, извлечи „същинския“ текст и отдели метаданни (заглавие, дата, автор, продукт).
Ако имаш supervised задача, label-ите са критични.
Минимални правила:
Когато етикетите идват от поведение (кликове, покупки), помни:
По-добре 5 000 реда с чисти labels, отколкото 200 000 със съмнителни.
Data leakage е когато информация от бъдещето или от теста „изтича“ в обучението и ти дава фалшиво високи резултати.
Практични правила:
Ако работиш със scikit-learn, използвай Pipeline/ColumnTransformer, за да гарантираш, че трансформациите се учат само върху training частта.
Най-честите трансформации:
Добра практика: пази отделно „raw“ слой и „features“ слой. Това помага за дебъг и за повторяемост.
Pipeline без проверки е покана за проблеми.
Добави автоматични проверки:
Версионирай:
Практичен минимум:
dataset_version идентификаторfeatures_version идентификаторПровери split-а (по време/по entity), виж дали метриките „падат драстично“ при правилен split и дали има features, които съдържат бъдеща информация.
Източник, период, дефиниции на полетата, трансформации, правила за изключване/включване и версия на dataset-а.
Почти винаги да, но внимателно: понякога „дубликат“ означава реално повтарящи се събития. Дефинирай ключ за дедупликация.
С комбинация от: (а) домейн правила, (б) имputation стратегия и (в) допълнителен флаг, че стойността е липсвала.
Когато имаш малко примери за редки случаи, но само ако можеш да валидираш, че синтетиката не вкарва систематични грешки и не нарушава правила за поверителност.
Ако работиш с таблични данни (CRM, транзакции, логове), типичният минимален pipeline изглежда така:
raw_events_2026_02_10). Не редактираш исторически партиции.Добави тестове, които се пускат при всяко обновяване на данните:
customer_id IS NOT NULL)price >= 0, age BETWEEN 0 AND 120status IN ('active','canceled','trial')< 5% за критични полета)Тези проверки може да ги имплементираш като SQL assertions, като тестове в dbt, или като Python валидатор (например с Pandera/Great Expectations стил). Важно е да са автоматични и да блокират pipeline-а при груби аномалии.
import pandas as pd
def validate(df: pd.DataFrame) -> None:
assert df["customer_id"].notna().all()
assert (df["price"] >= 0).all()
assert df["status"].isin(["active","canceled","trial"]).all()
# мониторинг: аларма ако липсващите скочат
missing_rate = df["email"].isna().mean()
assert missing_rate < 0.2
Тук не търсим „перфектни“ проверки, а такива, които ловят катастрофални промени рано.
При LLM-и най-често обработваш текст. Практики, които реално помагат:
Ако разработваш AI за чувствителни домейни (HR, финанси, здраве, образование), обработката на данни не е само инженерна задача. EU AI Act поставя изисквания за data governance и качество на training/validation/test данните при high-risk системи. Практически това означава: да можеш да покажеш произход, подготовка, критерии за включване/изключване, мерки срещу bias и как обновяваш данните.
Дори да не си в high-risk категория, този подход ти дава по-добра стабилност: по-малко „изненади“ след промени в източниците и по-лесен дебъг, когато метриките паднат.
Дори перфектно почистен training dataset не гарантира стабилност в продукция. След деплой следи поне:
Когато метриките паднат, първо провери дали източникът не се е променил (нов формат, нови категории, различен timezone). Накрая, планирай backfill стратегия: ако коригираш cleaning правило, преработи историческите партиции, иначе ще имаш „две истини“ в данните.