«Синимекс» два года внедряла AI в разработке: точность 80% не сэкономила ни минуты

Родион, руководитель отдела анализа данных в Лаборатории данных «Синимекс», опубликовал на Хабре подробный разбор того, как команда с 2023 года пробовала встраивать LLM (большие языковые модели, те самые «нейросети», которые генерируют текст и код) в собственные продукты. За два года компания прошла путь от завышенных ожиданий к трём конкретным правилам, которые полезны любому, кто думает об AI в разработке.

Что понадобится

• Доступ к LLM: открытые модели (опенсорс) или коммерческие (ChatGPT и аналоги). В России доступны YandexGPT, GigaChat, а также открытые веса моделей, которые можно развернуть локально.
• Реальные данные по задаче: техзадания, регламенты, код на целевом языке. Без них дообучение (fine-tuning, обучение модели на ваших примерах под узкую задачу) бессмысленно.
• Целевая аудитория для обратной связи: аналитики, тестировщики, разработчики, те, кто будет пользоваться результатом.
• Время: от нескольких недель на прототип (PoC, proof of concept, проверка гипотезы «в принципе работает») до нескольких месяцев на MVP (минимально жизнеспособный продукт).

Пошаговая инструкция: как «Синимекс» выстроила процесс

1. Сформулируйте гипотезу от боли пользователя, а не от возможностей модели. В 2023 году команда начала с обратного: взяла NER-подход (Named Entity Recognition, автоматическое выделение ключевых сущностей из текста) и попыталась научить LLM разбирать техзадания, выделять требования и сущности. Метрики получились неплохими: ROC-AUC 0.7, F1 0.61. Но когда показали результат аналитикам и архитекторам, те ответили прямо: «Если система ошибается хотя бы в двадцати процентах случаев, нам всё равно приходится полностью перепроверять результат вручную. Практической ценности почти нет.»

2. Считайте не точность модели, а стоимость проверки её ответа. Это главный вывод первого года. Хорошие ML-метрики не равны ценности для бизнеса. Пользователю неважно, что F1 вырос с 0.5 до 0.61, если каждый ответ всё равно нужно проверять целиком. Формула простая: если полная перепроверка обязательна, экономия времени равна нулю.

3. Разговаривайте с будущими пользователями до прототипа, а не после. Второй кейс 2023 года, генерация тестов для продукта CTT (Cinimex Test Tool), начинался правильнее: команда провела брейнштормы с тестировщиками, отобрала сценарии по критериям бизнес-ценности. Прототип на открытых моделях и ChatGPT работал, тесты генерировались. Но затраты на развитие решения перевесили ценность. Проект остановился, зато не были потрачены месяцы на масштабирование тупика.

4. Проверяйте масштабируемость отдельно от работоспособности. Третий кейс: цифровой ассистент для первой и второй линии поддержки банка из топ-20. По сути, классическая RAG-система (retrieval-augmented generation, когда модель ищет ответ в вашей базе знаний, а не выдумывает). PoC на открытых нормативных документах сработал. MVP на реальных данных одного подразделения тоже. Инициатор проекта сказал: «Работает.» Но соседние подразделения отреагировали иначе: «Нам оно зачем?» Пилот остановился. Успешный пилот не доказывает, что сценарий масштабируем.

5. Ищите задачу, где AI закрывает дефицит, а не оптимизирует изобилие. Прорыв случился в 2024-м с нишевыми языками. Команда сделала инструмент на базе LLM, встроенный в IDE (среду разработки), для генерации кода на RPGLE и COBOL. Специалистов по этим языкам всё меньше, а системы на них продолжают работать. Собрали датасет из репозиториев GitHub, The Stack v2, внутренних репозиториев GitLab «Синимекс», провели дообучение и встроили модель в IDE. Результат: автокомплит, генерация кода, помощь при написании тестов, возможность дообучать модель под конкретный проект. Впервые команда осталась довольна: модель реально начала помогать разработчикам.

# Пример структуры подхода (не код, а логика решения):
1. Определить боль → дефицит специалистов по RPGLE/COBOL
2. Собрать датасет → GitHub, The Stack v2, внутренний GitLab
3. Дообучить открытую LLM на этом датасете
4. Встроить в IDE → автокомплит + генерация + тесты
5. Отдать разработчикам, замерить не метрики, а сэкономленное время

Что делать с этим прямо сейчас?

Авторам Дзена и копирайтерам. Когда вы подключаете нейросеть для генерации текстов, не оценивайте результат по внутреннему ощущению «вроде неплохо». Замерьте, сколько минут уходит на редактуру каждого сгенерированного фрагмента. Если правите всё подряд, инструмент не помогает, а создаёт иллюзию помощи.

Маркетологам. Если вы внедряете AI-ассистента для клиентской поддержки или аналитики, спросите у команды не «какая точность?», а «сколько времени человек тратит на проверку каждого ответа?». Это единственная метрика, которая переводится в деньги.

Предпринимателям в РФ и СНГ. Опыт «Синимекс» показывает: AI в разработке работает, когда закрывает конкретный дефицит (мало специалистов, слишком много рутинных документов), а не когда «все внедряют». Открытые модели доступны для локального развёртывания, дообучение возможно на собственных данных. Из доступных в РФ инструментов для начала: YandexGPT, GigaChat, открытые модели через Hugging Face.

Кейс «Синимекс» оставляет одну формулу, которая стоит всех четырёх экспериментов: если пользователь обязан перепроверить каждый ответ AI целиком, вы автоматизировали не работу, а иллюзию работы, и никакой рост F1 это не исправит.