Послуги з розробки AI/ML рішень — TRUETECH

Чому distribution shift — головний ворог production ML?

Приходить клієнт з датасетом у 200k рядків: «Чому baseline-модель дає accuracy 87%, а в продакшні падає до 71%?». Відповідь майже завжди та сама — distribution shift між train та inference-даними, який ніхто не виміряв. З цього починається справжня AI-розробка: не з вибору архітектури, а з розуміння даних.

Ми — команда з 7-річним досвідом у production ML та 50+ реалізованими проєктами. Будуємо системи, які працюють під навантаженням: відтворювані пайплайни, версіонування моделей, моніторинг дрейфу даних та SLA на інференс. Гарантуємо прозорість метрик і reproducible результати.

Що входить у розробку 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 за оригінальними чанками.

Коли варто обирати open‑source моделі, а коли – API?

Для задач, де контроль даних і вартість масштабування критичні, open‑source (Llama 3, Mistral, Qwen) дають гнучкість і знижують операційні витрати на 30-50% при високому навантаженні. API-моделі (GPT-4o, Claude 3.5) виправдані на етапі прототипування або коли потрібна максимальна якість «з коробки» без власної інфраструктури. Ми допомагаємо визначити точку окупності: зазвичай після 50k запитів на місяць open‑source стає вигіднішим у 2-4 рази.

Мовленнєві технології

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 тест, налаштування алертів на метрики якості та дрейф даних. Модель без моніторингу деградує непомітно. За нашими даними, системи без моніторингу втрачають до 30% якості за 2 місяці.

Орієнтовні терміни та вартість

Вартість залежить від обсягу даних, обчислювальних вимог та інфраструктурної складності — оцінюємо індивідуально після аудиту завдання. Економія на інференсі за рахунок оптимізації (vLLM, квантизація) може досягати 40% від операційних витрат.

Перевірте, наскільки ваше завдання готове до ML-рішення. Отримайте консультацію щодо вашого проєкту — замовте попередній аудит даних та вимог. Зв'яжіться з нами для оцінки вашого завдання.