Услуги по разработке AI/ML решений — TRUETECH

Почему distribution shift — главный враг production ML

Заказчик приходит с датасетом в 200k строк и вопросом: «почему baseline-модель даёт accuracy 87%, а в продакшене падает до 71%?». Ответ почти всегда один и тот же — distribution shift между train и inference-данными, который никто не замерил. С этого и начинается настоящая AI-разработка: не с выбора архитектуры, а с понимания данных.

Мы — команда с 7-летним опытом в production ML и 50+ реализованными проектами. Строим системы, которые работают под нагрузкой: воспроизводимые пайплайны, версионирование моделей, мониторинг дрейфа данных и SLA на инференс. Не ноутбуки с «обещающими результатами».

Что входит в разработку AI решений

Под AI/ML мы понимаем полный цикл: сбор и разметка данных, обучение, валидация, деплой, мониторинг и переобучение. Каждая стадия может быть отдельной задачей или частью сквозного проекта.

Направления, с которыми работаем:

• LLM и генеративный AI — fine-tuning, RAG-пайплайны, мультиагентные системы, деплой через vLLM
• Computer Vision — детекция объектов, сегментация, OCR, face recognition, видеоаналитика
• NLP — NER, классификация текста, sentiment analysis, извлечение информации, эмбеддинги
• MLOps — инфраструктура обучения и деплоя, model registry, CI/CD для моделей, мониторинг
• Рекомендательные системы — collaborative filtering, content-based, гибридные подходы, real-time serving
• Data Engineering для ML — feature store, ETL-пайплайны, разметка, data quality
• Speech — ASR (распознавание речи), TTS, speaker diarization

Какой стек мы используем и почему

Выбор инструментов зависит от задачи, не от привычки.

Обучение моделей. PyTorch — основной фреймворк. TensorFlow держим для legacy-проектов и TensorFlow Serving. JAX используем, когда нужна высокая производительность на TPU или кастомные градиенты. Hugging Face Transformers + PEFT + trl — стандарт для работы с языковыми моделями: LoRA, QLoRA, DPO, RLHF. DeepSpeed и FSDP — для распределённого обучения на нескольких GPU.

Инференс. vLLM с PagedAttention для LLM — держит 200+ req/s при P99 latency < 800ms на A100. ONNX Runtime + TensorRT для CV-моделей — даёт 3-8x ускорение относительно нативного PyTorch inference. bitsandbytes для квантизации в INT4/INT8 без существенной потери качества.

Векторные базы данных. pgvector для проектов на PostgreSQL (нулевая инфраструктурная зависимость). Qdrant и Weaviate — когда нужен production-grade векторный поиск с фильтрацией и масштабированием. FAISS — для офлайн-индексов и экспериментов. ChromaDB — в разработке и прототипировании.

LLM-оркестрация. LangChain для сложных агентных пайплайнов. LlamaIndex — когда задача — RAG поверх документов. Прямые вызовы OpenAI API, Claude API, Mistral API — там, где оркестратор избыточен.

MLOps. MLflow для tracking экспериментов и model registry. Weights & Biases — для проектов с интенсивным экспериментированием, где нужна визуализация и collaboration. Kubeflow для ML-пайплайнов на Kubernetes. DVC для версионирования данных и моделей.

Почему GPU OOM убивает сроки больше, чем плохая архитектура

Это один из самых частых stoppers в реальных проектах. Команда потратила неделю на подбор архитектуры, запустила обучение 7B модели на A100 40GB — и через 10 минут OOM. Причины типичны.

Первое: не настроен gradient_accumulation_steps. При batch_size=32 и длине последовательности 2048 токенов активации занимают ~18GB только для forward pass. Решение — уменьшить batch до 4 и поставить gradient_accumulation_steps=8, эффективный batch тот же, memory footprint радикально меньше.

Второе: обучение в fp32 вместо bf16. Переключение torch_dtype=torch.bfloat16 в Hugging Face Trainer сокращает потребление памяти вдвое. На Ampere-архитектуре (A100, A6000) bf16 работает быстрее fp16 и без loss scaling.

Третье: не используется gradient checkpointing. model.gradient_checkpointing_enable() жертвует 20-30% скорости обучения, но режет потребление активаций в 5-8 раз. На длинных последовательностях это критично.

С QLoRA ситуация ещё лучше: 4-битная квантизация базовой модели через bitsandbytes + LoRA-адаптеры позволяют fine-tune Llama-3 70B на двух A100 40GB. Trainable параметров ~0.5% от общего числа, но результат fine-tuning сопоставим с полным обучением на узких задачах.

Распределение по типовым задачам

Понимание того, какая часть проекта занимает больше всего времени, помогает правильно планировать.

Данные всегда дороже, чем кажется. Это не пессимизм — это опыт после десятков проектов.

Как валидировать систему, а не только модель

Модель с F1 0.91 на holdout-сете — не гарантия F1 0.91 в продакшене. Разрыв между offline и online метриками возникает по нескольким причинам.

Temporal leakage. Train содержит данные из будущего относительно validation. При случайном split с временными данными это происходит автоматически. Правильный подход — temporal split с gap между train и val, чтобы исключить утечку признаков.

Feature drift. Распределение входных данных меняется со временем. Модель обучена на данных за предыдущие периоды, а сегодня пользовательское поведение изменилось. Мониторинг distribution shift через PSI (Population Stability Index) или KL-divergence — обязательная часть production ML-системы.

Label shift. Соотношение классов в продакшене отличается от train. Особенно критично в задачах fraud detection и медицинской диагностике, где дисбаланс может достигать 1:5000.

Для нейтрализации этих эффектов используем: stratified k-fold с temporal awareness, calibration через Platt scaling или isotonic regression, threshold tuning под реальные business-метрики (не accuracy, а precision@recall).

Генеративный AI в продакшене: реальные ограничения

LLM-проекты имеют специфику, которую не описывают в туториалах. Три наиболее частые проблемы.

Галлюцинации в RAG. Модель уверенно отвечает на вопрос, которого нет в контексте. Причина часто не в модели, а в плохом retrieval: chunk_size=512 без overlap приводит к тому, что релевантный ответ разрезается между двумя чанками. Решение: overlap 20-30%, гибридный поиск (dense + sparse BM25), re-ranking через cross-encoder (например, ms-marco-MiniLM-L-6-v2 из sentence-transformers).

Latency. Наивный деплой 13B модели на одном A10G даёт P50 latency ~4s — неприемлемо для интерактивных приложений. vLLM с PagedAttention и continuous batching снижает это до 600-900ms P50 при той же нагрузке. Для ещё более агрессивной оптимизации — AWQ квантизация до 4 бит с минимальной деградацией качества.

Управление контекстом. При context window 128k токенов модели деградируют на середине контекста (lost in the middle). Для длинных документов лучше работает иерархический RAG: сначала coarse retrieval по summary-эмбеддингам, потом fine retrieval по оригинальным чанкам.

Речевые технологии

ASR-задачи часто приходят с требованием «распознать отраслевую лексику» — медицинские термины, юридические конструкции, названия продуктов. OpenAI Whisper large-v3 даёт хорошую baseline WER, но на специализированном словаре ошибки резко растут.

Дообучение Whisper через LoRA на корпусе из 50-200 часов размеченной речи снижает WER на специализированной лексике в 2-3 раза. При этом адаптеры весят 30-50MB — в отличие от полной модели (3GB для large-v3), их удобно версионировать и деплоить.

Для speaker diarization используем pyannote.audio 3.x с претренированными пайплайнами и кастомной адаптацией под конкретный акустический домен.

Этапы проекта и примерный бюджет

Аудит данных и постановка задачи. Смотрим на распределение классов, качество разметки, объём, наличие temporal паттернов. Часто задача переформулируется: из «предскажи отток» в «ранжируй клиентов по вероятности оттока в следующие 30 дней». Это меняет метрики и архитектуру.

Baseline за 1-2 недели. Простая модель с воспроизводимым пайплайном. Цель — зафиксировать метрики, убедиться в адекватности данных, получить точку отсчёта. XGBoost или логрегрессия как baseline лучше, чем нейросеть без понимания задачи.

Итеративное улучшение. Feature engineering, выбор архитектуры, hyperparameter tuning через Optuna или Ray Tune. Каждый эксперимент логируем в MLflow или W&B — без этого невозможно понять, что реально помогло.

Валидация и stress-тестирование. Проверка на edge cases, adversarial inputs, тестирование при нагрузке. Для LLM — red teaming и оценка галлюцинаций.

Деплой и мониторинг. Canary release, A/B тест, настройка алертов на метрики качества и дрейф данных. Модель без мониторинга деградирует незаметно.

Ориентировочные сроки и стоимость

Стоимость зависит от объёма данных, вычислительных требований и инфраструктурной сложности — оцениваем индивидуально после аудита задачи. Экономия на инференсе за счёт оптимизации (vLLM, квантизация) может достигать 40% от операционных затрат.

Проверьте, насколько ваша задача готова к ML-решению. По данным MLflow documentation, системы без мониторинга деградируют в среднем за 2 месяца. Получите консультацию по вашему проекту — закажите предварительный аудит данных и требований. Свяжитесь с нами для оценки вашей задачи.