DKДенис Кажаев
RUEN

ML / LLM Engineer · production RAG

Production RAG и LLM-системы: retrieval, оценка качества, fine-tuning и MLOps.

Строю LLM-сервисы от ingestion до мониторинга: гибридный поиск и reranking, grounded-генерация, PEFT/LoRA, claim-level оценка, оптимизация latency, воспроизводимые эксперименты и продакшен-инфраструктура. Самостоятельно веду задачу и сам договариваюсь с заказчиком о метриках и ограничениях.

Написать в Telegram ↗ d.al.kazhaev@gmail.com

Сербия · удалённо · UTC+1  /  Русский — родной, английский — B1

Что я даю команде

01

Production RAG

Ingestion и метаданные, чанкинг, подобранный на eval-наборе, dense + BM25, RRF, cross-encoder reranking, фильтры по продукту и версии, fallback при слабом контексте.

02

Оценка качества

Golden sets, Recall@K, NDCG / MRR для retrieval; groundedness и доля неподтверждённых утверждений для генерации; регрессионные прогоны и shadow mode.

03

Fine-tuning

PEFT / LoRA на хороших ответах, реальных ошибках и примерах корректного отказа. Сравниваю версии по claim-level метрикам, а не «на глаз».

04

Latency и стоимость

Разбор latency по этапам, кэш эмбеддингов, retrieval и контекста, лимит кандидатов для reranker, async I/O, контроль длины контекста. P50 / P95, а не среднее.

05

MLOps

ClearML для экспериментов, Docker, CI/CD на GitHub Actions, деплой в AWS, Prometheus и Grafana с дашбордами по этапам пайплайна и алертами.

06

Backend

Python, FastAPI, PostgreSQL, Redis, Pydantic-схемы для structured output, ретраи, идемпотентность, health checks, структурные логи.

Как я веду ML-задачу

Стандартный цикл ML System Design: постановка и метрики → данные → бейзлайн → эксперименты → оценка → раскатка → мониторинг. Любое изменение промпта, модели или retrieval проходит через регрессионный прогон.

  1. 01

    Постановка и метрики

    Ограничения, целевые offline- и online-метрики, бюджет по latency и стоимости запроса.

  2. 02

    Данные и golden set

    Реальные запросы с размеченными источниками, сегменты (перефразирования, точные термины и коды), регрессионный набор сложных случаев.

  3. 03

    Бейзлайн

    Простое интерпретируемое решение — точка отсчёта, чтобы видеть, где сложные компоненты реально дают прирост.

  4. 04

    Эксперименты

    Чанкинг, retrieval, reranker, промпты, PEFT / LoRA. Параметры, версии данных и кода, метрики и артефакты — в ClearML.

  5. 05

    Оценка

    Retrieval, генерация и система отдельно; срезы по сегментам; регрессионный прогон перед любым изменением.

  6. 06

    Раскатка

    Shadow mode на реальном трафике, постепенный rollout, возможность быстрого отката индекса и модели.

  7. 07

    Мониторинг

    Latency по этапам, ошибки, fallback, cache hit rate, лаг индексации; алерты и разбор деградаций.

Проекты

01

YADRO · ML Engineer · 08.2024 — 11.2025

RAG-ассистент по технической документации

Задача

Большая, регулярно обновляемая документация с похожими терминами, версиями и конфигурациями. Ответ должен опираться на актуальный источник, а не на общие знания модели.

Что я построил
  • Ingestion со смысловым чанкингом и метаданными (продукт, версия, компонент); размер и overlap подобраны на eval-наборе.
  • Гибридный поиск: dense + BM25, RRF, cross-encoder reranker на top-N, фильтры по продукту и версии.
  • Grounded-генерация со ссылками на источники и fallback при слабом контексте.
  • LoRA/PEFT-адаптация и claim-level оценка на регрессионном наборе.
Инженерные решения
  • Latency разложена по этапам; кэш эмбеддингов, retrieval и контекста, лимит кандидатов для reranker.
  • Каждое изменение — через регрессионный прогон и shadow mode.
  • Воспроизводимые эксперименты в ClearML.
Результат

Заметный рост Recall@5 относительно бейзлайна, меньше неподтверждённых утверждений на регрессионном наборе, latency в целевом SLA.

Что это показывает → Полный цикл production RAG: retrieval, генерация, fine-tuning, оценка и latency.

Python · Transformers · Sentence Transformers · PEFT/LoRA · BM25 · cross-encoder · FastAPI · ClearML · Docker · Prometheus · Grafana

02

1-lab · LLM Engineer · автодилер, продакшен

LLM-оценка звонков с измеримой надёжностью

Задача

Каждый звонок отдела продаж нужно оценить по чек-листу из 15 взвешенных критериев — без человека и так, чтобы оценке можно было доверять. Вручную слушали 20–30% звонков.

Что я построил
  • Транскрибация с диаризацией, разметка реплик «менеджер / клиент» с таймкодами.
  • Первый LLM-шаг — классификатор типа звонка по содержанию, а не по длительности: технический, сорвавшийся, клиент едет сам, полноценная продажа.
  • Второй шаг — скорер: бинарные ответы по каждому критерию плюс текст возражения, причина отказа и краткое саммари.
  • Пост-валидация в коде: извлечение JSON, приведение к сетке «0 или вес критерия», обрезка полей, детерминированный расчёт итогового балла.
Инженерные решения
  • Два вызова вместо одного: разные задачи и разная строгость — меньше ложных нулей на коротких содержательных звонках, чек-лист меняется без правки фильтрации.
  • Набор эталонных транскриптов с ожидаемыми оценками прогоняется при каждом изменении критериев; выборка регулярно сверяется с ручной оценкой, расхождения уходят в правила промпта.
  • Классификатор настроен консервативно: лучше оценить лишний звонок, чем пропустить содержательный.
Результат

25 950+ звонков оценено, покрытие 100% вместо 20–30%, оценка появляется через 1–2 минуты после сделки.

Что это показывает → LLM как надёжный компонент: декомпозиция задачи, ограниченный вывод, детерминированный скоринг и регрессионная оценка.

Python · AssemblyAI · LLM API · Pydantic · PostgreSQL · S3 · Docker · Grafana

03

1-lab · LLM Engineer · промышленный производитель, продакшен

RAG по каталогу B2B-оборудования

Задача

Сотни SKU, спецификации и прайсы регулярно меняются. Ассистент не должен выдумывать характеристики и цены и путать похожие модели.

Что я построил
  • Ingestion из Google Drive: детекция изменений по хешу, инкрементальная переиндексация каждые 15 минут, извлечение текста и технических таблиц.
  • Смысловой чанкинг по разделам, моделям и спецификациям, а не по числу символов; метаданные: SKU, категория, источник, дата, версия.
  • Retrieval с фильтрами по метаданным и порогом релевантности; grounded-генерация со structured output (ответ, поля, уверенность, флаг эскалации).
  • Оценка: golden set реальных вопросов с размеченными источниками (Recall@K, NDCG@K), groundedness и доля ответов без опоры; онлайн — handoff rate и задержка.
Инженерные решения
  • RAG, а не fine-tuning: каталог и прайсы меняются, индекс обновляется без переобучения.
  • Фильтр по SKU не даёт поиску уйти к похожей, но другой модели; нет опоры в контексте — нет цифры в ответе, вопрос уходит человеку.
  • Версия документа и время индексации хранятся в индексе — по любому ответу видно, из какой версии базы он собран.
Результат

Ассистент работает 24/7 по актуальной базе: обновлённый прайс или спецификация попадает в выдачу в течение 15 минут.

Что это показывает → Production RAG на часто меняющихся данных: инкрементальная индексация, метаданные, защита от галлюцинаций и трассируемость.

Python · embeddings · vector search · Pydantic · FastAPI · PostgreSQL · Redis · Google Drive API · Docker · Prometheus · Grafana

04

ALP GROUP · ML Engineer · 07.2022 — 06.2024

Генерация протоколов встреч

Задача

Из длинного ASR-транскрипта извлечь решения, задачи, сроки и ответственных — и не добавить того, чего на встрече не было.

Что я построил
  • Предобработка ASR: очистка, сегментация по времени и спикерам, сущности, привязка к таймкодам.
  • Интерпретируемый бейзлайн: TF-IDF, логистическая регрессия, градиентный бустинг.
  • RAG: Sentence Transformers + FAISS, BM25, RRF, reranker; иерархическая суммаризация по темам.
  • Валидация: Pydantic, проверка опоры на фрагменты, статус needs_review.
Инженерные решения
  • Весь транскрипт в контекст не отправляется: дороже, медленнее и теряет детали в середине окна.
  • Неподтверждённые сроки и ответственные подавляются — лучше пустое поле на ревью, чем выдумка.
  • CI/CD через GitHub Actions, деплой в AWS, мониторинг Prometheus / Grafana.
Результат

Рост Recall@10 на golden set и меньше галлюцинаций на регрессионном наборе — черновик протокола стал надёжнее для ревью.

Что это показывает → Бейзлайн перед LLM, работа с длинным контекстом и слой валидации против галлюцинаций.

Python · scikit-learn · Sentence Transformers · FAISS · BM25 · cross-encoder · Pydantic · FastAPI · Docker · GitHub Actions · AWS

Ещё в 1-lab

Мультиагентный конвейер с quality gate

Четыре роли с JSON-контрактом, порог качества и до 3 итераций, разные модели и температуры по ролям, human-in-the-loop перед публикацией.

LLM API · agent orchestration · Telethon · PostgreSQL

Стек

Backend
  • Python
  • FastAPI
  • Pydantic
  • PostgreSQL
  • Redis
LLM и модели
  • LLM API
  • open-source LLM
  • Hugging Face Transformers
  • Sentence Transformers
  • PEFT / LoRA
RAG и поиск
  • embeddings
  • FAISS
  • BM25
  • hybrid retrieval
  • RRF
  • cross-encoder reranking
  • metadata filtering
Оценка
  • golden sets
  • Recall@K
  • NDCG
  • MRR
  • groundedness
  • unsupported claim rate
  • regression suites
  • P50 / P95 latency
  • cache hit rate
MLOps
  • Docker
  • GitHub Actions
  • AWS
  • Prometheus
  • Grafana
  • ClearML (трекинг экспериментов)
Интеграции
  • n8n
  • CRM API
  • Google Drive API
  • Telegram API

Опыт

  1. 12.2025 — н.в.

    1-lab · LLM Engineer

    LLM-сервисы в продакшене: RAG по каталогу с инкрементальной индексацией, LLM-оценка звонков с детерминированным скорингом, мультиагентный конвейер с quality gate.

  2. 08.2024 — 11.2025

    YADRO · ML Engineer

    Production RAG по технической документации: гибридный поиск, reranking, LoRA/PEFT, claim-level оценка, latency.

  3. 07.2022 — 06.2024

    ALP GROUP · ML Engineer

    NLP и LLM для протоколов встреч: классический бейзлайн, гибридный RAG, иерархическая суммаризация, валидация.

Давайте поговорим

Открыт к удалённой работе. Быстрее всего отвечаю в Telegram.

Telegram · @den_kxcv ↗ d.al.kazhaev@gmail.com

Сербия · удалённо · UTC+1  /  Русский — родной, английский — B1