Конспект доклада про применение LLM в бизнес-задачах дата-инженера с третьего занятия «Вечерней школы. ИИ для инженеров: польза и риски» от Слёрма
Менеджер крупной компании начинает утро со списка на обзвон. Список длинный, а на проверку одной регистрации партнёра уходит от 5 минут, потому что если человек не берёт трубку, звонить нужно ещё раза три. К обеду список кажется бесконечным, а большая часть звонков в пустоту или уходит на платные номера. Именно с этой рутины начал третье занятие «Вечерней школы. ИИ для инженеров: польза и риски» дата-инженер Дмитрий Дунаев, и дальше показал, как обычный список на обзвон превратился в приоритизированный список, где самую нудную часть работы берёт на себя LLM.
Этим летом Слёрм запустил бесплатную «Вечернюю школу. ИИ для инженеров: польза и риски». Шесть открытых онлайн занятий о том, где искусственный интеллект реально помогает инженеру, а где создаёт новые риски. Занятия построены на живых кейсах и рабочих процессах: инженеры, архитекторы, безопасники и даже юрист разбирали, как ИИ встраивается в разбор инцидентов, автофикс прода, SOC и code review, на разных моделях и инструментах.
Первое занятие школы было про то, как ИИ-агент разбирает алерты и собирает контекст инцидента за дежурного инженера, а во втором разобрали, как сервис на основе ИИ автоматически чинит типовые проблемы CI/CD. Прочитать оба конспекта можно здесь: «Как научить ИИ разгребать метрики, пока дежурный допивает чай» и «Автофикс проблем прода с ИИ без инженера».
Третье занятие прошло 28 июля 2026 года и было посвящено тому, как использовать LLM не только в чисто инженерных задачах, но и в бизнес-процессах: там, где раньше все решения принимали люди, разбирая данные вручную.
Доклад прочитал Дмитрий Дунаев (@Runemal). Дмитрий рассказал два реальных кейса из своей практики: как команда с помощью LLM разгрузила менеджеров по продажам от ежедневного ручного обзвона и как вторая команда выстроила процесс для сопоставления порядка 209 тысяч наименований номенклатур между полу сотнями представительств компании.
Спикер: Дмитрий Дунаев (@Runemal)
дата-инженер
работает в строительной компании
строит озеро данных и выстраивает пайплайны обработки данных
экспериментирует с применением ИИ в работе с данными
Слайд презентации: спикер доклада
Дальше в статье: почему подготовка данных определяет качество ответа модели, как устроен антифрод-классификатор для регистраций, как команда сопоставила 209 тысяч наименований товаров, какие критерии важны при выборе модели для бизнес-задачи и когда вообще стоит строить агента, а когда не стоит.
Коротко о докладе, если ты дата-инженер или инженер, который начал заходить в бизнес-задачи с ИИ
дата-инженер готовит для модели структурированные, очищенные данные, потому что принцип garbage in, garbage out работает в LLM в полной мере
в кейсе с антифродом LLM-классификатор делит регистрации на зелёные, жёлтые и красные, и менеджер обзванивает уже приоритизированный список вместо случайного
в кейсе с сопоставлением справочников команда объединила LLM, embedding, fuzzy-поиск и ручную верификацию, потому что по отдельности ни один из способов не давал приемлемого качества
для работы с персональными данными (152-ФЗ) команда выбрала локальную модель в защищённом контуре вместо облачного сервиса
из 15 протестированных моделей лучший баланс детерминизма, безопасности и качества работы с русским языком для антифрода показала YandexGPT 5 Lite
строить агента стоит там, где решения повторяемы и есть возможность проверить результат, для разовой задачи такая автоматизация обычно не окупается
Роль дата-инженера и почему подготовка данных решает
Дмитрий описал свою профессию через сравнение с соседними ролями: дата-инженер работает где-то между DevOps-инженером и аналитиком. Он собирает, структурирует и очищает данные из баз и файловых хранилищ, готовит для аналитиков слой данных, по которому быстро строятся отчёты и дашборды, и для этого использует Python, SQL и разные инструменты интеграции.
Для бизнес-задач с LLM это особенно важно. Контекстное окно моделей ограничено, и если закинуть в модель необработанный массив документов и файлов, она либо не разберётся, либо выдаст непредсказуемый результат. Дмитрий сформулировал правило так: неопределённость на входе почти всегда превращается в неопределённость на выходе, а определённые, чистые и структурированные данные дают предсказуемый и проверяемый результат. Единственное исключение, где работа с сырыми, неочищенными данными оправдана, это исследовательские задачи и проверка гипотез, когда бизнес сам ещё не знает, что ищет, и скорость там сознательно приносят в жертву глубине анализа.
Кейс 1: антифрод при регистрации партнёров
Проблема: обзвон без приоритета
Дмитрий предложил представить крупную геораспределённую компанию, основной бизнес которой строится на странах СНГ. Каждое утро менеджер, который работает с партнёрами, получает длинный список регистраций для подтверждения по телефону: список без приоритета, просто фамилия, имя, отчество и номер.
Цена одной регистрации по времени составляет от 5 минут, потому что если человек не берёт трубку сразу, звонить приходится ещё раза три. Менеджер не обязан заранее знать, какой стране принадлежит номер и не платный ли он, поэтому риск потратить время впустую и нарваться на платный номер довольно высокий. Стандартный ответ на рост числа заявок в такой ситуации, просто увеличить штат менеджеров.
Что можно сделать бэкендом и почему этого мало
Часть задачи решается без всякого ИИ. По коду региона в номере телефона можно определить государство (НО! Например, код, начинающийся на +7, принадлежит сразу двум странам, России и Казахстану), а по IP-адресу через сервисы вроде MaxMind получить географию: для Европы и Северной Америки точно до города, для остального мира хотя бы до страны и примерного региона. Отдельно можно попробовать определить признаки VPN или прокси.
Проблема в том, что это лишь добавляет менеджеру данных для анализа. Саму работу с него это не снимает. Вместо фамилии, имени, отчества и номера он теперь получает ещё несколько параметров, которые сам должен интерпретировать: страна по номеру, страна по IP, признаки подмены адреса. Квалификация, которая требуется от менеджера, растёт, а рутина никуда не девается.
Как помогает LLM
Здесь в дело вступает LLM. Модель умеет сопоставлять сразу много разнородных признаков: типичность или нетипичность фамилии и имени для конкретной страны, телефонный код, географию по IP, и вместе с вердиктом может объяснить, почему регистрация выглядит подозрительно.
Перед менеджером поставили классификатор на основе LLM, который распределяет все входящие регистрации на три категории. Зелёные, с высокой вероятностью, что это реальный человек, их обзванивают в первую очередь. Жёлтые, спорные случаи, по которым решение принимает уже сам менеджер. Красные, где модель считает риск мошенничества высоким. Менеджер получает готовый приоритизированный список: сначала зелёные, потом жёлтые, потом красные.
Критерии выбора модели
Так как речь идёт о персональных данных, работа подпадает под 152-ФЗ, и передавать такие данные во внешние сервисы нельзя. Команда рассматривала облачных провайдеров с защищённым контуром, но пришла к выводу, что дешевле и практичнее собрать собственный сервер с видеокартой и работать с локальной моделью прямо в офисе.
Дмитрий выделил шесть критериев для выбора модели под эту задачу.
Детерминизм. Способность модели давать одинаковый или очень повторяемый результат на одни и те же входные данные при каждом запуске. Для антифрода нестабильный, каждый раз разный ответ на одинаковые данные не подходит.
Компактность. Модель должна помещаться в разумный объём, до 12 ГБ, чтобы её можно было развернуть на локальном железе и получать быстрый ответ.
Работа с русским языком и менталитетом СНГ. Основная клиентская база компании из стран СНГ, значит модель должна хорошо понимать типичные для этого региона фамилии, имена и формулировки.
Логическая корректность. Модель должна верно выполнять базовые математические операции и сравнения, включая простые вроде сравнения десятичных чисел, без этого нельзя доверить ей подсчёт коэффициента риска.
Безопасность. Модель не должна легко соглашаться выдать то, чего не следует, по короткому или манипулятивному запросу.
Структурированный вывод. Даже если в системном промпте явно задать формат ответа, не все модели этот формат соблюдают. Часть моделей вместо короткого структурированного вердикта выдаёт развёрнутое рассуждение на пару страниц.
Тестирование и выбор
Команда тестировала модели на реальных и синтетических фрод-кейсах, меняла температуру (параметр, который отвечает за вариативность ответа модели: чем она ниже, тем ответ стабильнее и предсказуемее, а чем выше, тем больше у модели простора для творческих связей), сравнивала объяснения и то, как модели распределяют одни и те же данные по трём категориям.
Всего протестировали около 15 моделей, и в тройку лидеров вышли три. Gemma 3 показала сильные результаты, но плохо работает с русским языком и менталитетом СНГ. Модель T-lite от T-Bank отлично работает с русским языком и неплохо справляется с переводом, но оказалась менее безопасной: короткого промпта достаточно, чтобы она выдала то, чего не следует. YandexGPT 5 Lite показала лучший баланс: стабильно соблюдала логику, была детерминированной, хорошо работала с русским языком и держала безопасность. На ней команда и остановилась.
Отдельно Дмитрий разобрал вопрос про цену ошибки классификации. Ложноположительная ошибка (мошенника пометили как надёжного) обходится дороже ложноотрицательной (реального человека ошибочно заблокировали как подозрительного), потому что реальный человек так или иначе даст о себе знать снова: напишет в поддержку, перерегистрируется или позвонит в офис. Деньги, потерянные на пропущенном мошеннике, вернуть уже не получится.
Результат
Количество необходимых звонков и риск нарваться на платный номер снизились. При этом сама длительность одного звонка короче не стала, менеджер по-прежнему тратит от 5 минут на созвон, если человек не берёт трубку сразу. Выигрыш получился в приоритизации звонков и в уменьшенном объёме ручной работы, которую раньше делал человек.
Кейс 2: сопоставление справочников номенклатуры
Проблема: 209 тысяч наименований
Второй кейс о компании с полусотней представительств по разным регионам и примерно 209 тысячами наименований товаров. На местах люди вносят данные по-своему: сокращают слова, меняют порядок, используют разные единицы измерения и внутренние названия, допускают опечатки и вставляют невидимые символы вроде неразрывного пробела.
Из-за этого один и тот же физический товар в разных представительствах может называться совершенно по-разному: полиэтилен превращается в «полиэт», диаметр записывают то в дюймах, то в миллиметрах, то через обозначение DN, а формат «3 на 2,5» может выглядеть как «3х2,5», «3*2,5» или в обратном порядке.
Почему прямой join не работает
Когда команда попробовала просто сджойнить таблицы из разных представительств по названию, сопоставилось около 1% всех записей. Дело в разнообразии написаний одного и того же товара. Само качество данных здесь ни при чём.
Поиск по подстроке и fuzzy matching (поиск похожих, но не идентичных строк, вроде «кабель» и «кабели», по проценту схожести между строками) находит только часть совпадений. Ручная верификация экспертами по номенклатуре работает, но дорого и медленно: по наблюдению Дмитрия, концентрация у человека на такой монотонной работе заметно падает уже после 3 или 4 часов такой работы. LLM понимает смысл сокращений и может объяснить сопоставление, но иногда ошибается и не гарантирует стопроцентного покрытия. По отдельности ни один способ решения не дал приемлемого результата.
Архитектура решения
Команда объединила все три подхода в единую архитектуру. Эталонный справочник разбили на классы и атрибуты, эту разбивку проверил человек, и только после этого данные превратили в embedding (числовое векторное представление текста, по которому можно быстро искать похожие по смыслу фразы, даже если они записаны по-разному).
Тем же способом обработали данные каждого представительства: разбили на классы и атрибуты, нашли кандидатов на сопоставление через embedding и fuzzy-поиск. Найденные совпадения показывают человеку для подтверждения, а если система решает, что перед ней что-то новое, запись тоже уходит на ручную верификацию к эксперту, который решает, новый это товар или уже известный, просто записанный иначе.
Для самых запутанных случаев, где расхождений в написании особенно много, по словам Дмитрия, лучше всего сработала модель GPT-5.6 Sol с максимальным уровнем рассуждений (reasoning XHigh), хотя такой режим сильно расходует токены.
Результат
Комбинация LLM, embedding, fuzzy-поиска и ручной верификации заменила прямой join, который сопоставлял только около 1% записей. Полностью убрать человека из процесса не вышло: ручная верификация справочника и спорных случаев остаётся обязательным этапом, но объём монотонной ручной работы заметно сократился по сравнению с сопоставлением вообще без автоматизации.
Чек-лист: когда стоит строить агента
Дмитрий сформулировал пять условий, при которых имеет смысл строить агента под бизнес-задачу.
решения в задаче повторяются регулярно
данных достаточно, а экспертизы для их разбора не хватает
цена ошибки (ложноположительной и ложноотрицательной) заранее оценена
есть человеческая экспертиза, чтобы проверить результат агента
предусмотрен fallback-процесс на случай, если агент начнёт ошибаться
Инструменты для тестирования моделей
По ходу доклада Дмитрий показал два инструмента, которыми пользуется его команда.
Cherry Studio. Графический интерфейс для работы с множеством моделей и агентами одновременно. Поддерживает облачных и локальных провайдеров (NVIDIA, Yandex, Ollama, LM Studio, OpenRouter, GitHub Models и другие), сборку своих агентов, генерацию изображений, перевод, базу знаний с embedding для задач в духе RAG, поддержку CLI-агентов и MCP. Из ограничений Дмитрий отметил рейт-лимиты у отдельных провайдеров, например у NVIDIA лимит 40 запросов в минуту, из-за чего у агента с частыми запросами возможны задержки.
Прокси-шлюз для локальных и облачных моделей. Многие агентские инструменты вроде Codex или Claude Code плохо работают с чужими нестандартными эндпоинтами, например с эндпоинтами NVIDIA. Прокси-шлюз поднимается через docker-контейнер в пару команд и решает эту проблему: агент подключается к шлюзу как к обычному провайдеру, а шлюз уже сам разговаривает с NVIDIA, Ollama или LM Studio.
Личное железо, на котором Дмитрий тестирует локальные модели: процессор Ryzen 7 на 8 ядер, 64 ГБ оперативной памяти и видеокарта RTX 3060 на 12 ГБ. Этого достаточно, чтобы локально гонять модели вроде Gemma и GLM 4.7 Flash.
Практические рекомендации от Дмитрия
строить агента там, где решения повторяемы, а разовые задачи оставлять человеку
заранее оценивать цену ошибки и предусматривать fallback-процесс с участием человека
держать ручную верификацию обязательной хотя бы на старте, пока не накоплена статистика по качеству модели
относиться к тестированию моделей и агентов как к непрерывному процессу, который продолжается и после запуска
менять модель, когда меняется сам бизнес-процесс. Выход новой версии модели сам по себе поводом не считается
Ещё аудитория спрашивала
Правда ли, что подготовка данных важнее промпта? Да. Даже хорошо составленный промпт не спасает, если на входе неопределённые данные, потому что неопределённость на входе почти всегда превращается в неопределённость на выходе.
Пробовали ли BERT-модели для сопоставления справочников? Конкретно в этом кейсе команда их не тестировала.
Использовали ли роутеры вроде OpenRouter? Пробовали, но в основном команда работает с NVIDIA из-за бесплатного доступа к топовым моделям. По наблюдению Дмитрия, ответы DeepSeek через NVIDIA оказались качественнее, чем на официальном сайте той же модели, поэтому его совет один: провайдера и модель выбирают через тестирование. Репутация тут не аргумент.
Как через Cherry Studio перепроверять код, который написал другой агент, например Codex? Дмитрий советует для ревью привлекать вторую, отдельную модель. Той же самой, которой писали код, для проверки лучше не пользоваться: она слишком хорошо узнаёт собственные паттерны и не замечает в них проблем.
Как решили вопрос 152-ФЗ с YandexGPT, если на слайде она выглядела как облачное решение? На самом деле модель локальная. YandexGPT 5 Lite развёрнута через Ollama, доступна и на Hugging Face, а данные не покидают защищённый контур компании.
Есть ли риск, что доступ к нейросети отключат или условия изменятся? Да, это отдельный риск при работе с облачными провайдерами, наравне с рисками по чувствительным данным, поэтому команда и выбрала для антифрода локальную модель.
Домашнее задание от Дмитрия
Дмитрий подготовил для слушателей материалы, чтобы можно было попробовать всё это на практике самостоятельно.
системный промпт для анализа регистраций: ссылка на промпт
синтетический датасет для проверки фродовых регистраций: ссылка на датасет
репозиторий с прокси-шлюзом GOLN для подключения к NVIDIA и локальным моделям через Ollama и LM Studio: github.com/Runemal/goln_code
Задание простое: подключить датасет к разным моделям через Cherry Studio или через шлюз GOLN и сравнить, как разные модели классифицируют одни и те же регистрации по системному промпту.
Итоги доклада
Дмитрий на двух реальных кейсах показал, что путь инженера в бизнес-задачи начинается с подготовки данных и честной оценки цены ошибки, а выбор конкретной модели становится уже следующим шагом. В обоих кейсах LLM работает в связке с другими методами: с бэкенд-логикой и приоритизацией в антифроде, с embedding и fuzzy-поиском в сопоставлении справочников, и в обоих случаях финальное решение по спорным случаям остаётся за человеком.
Отдельный практический вывод касается тестирования: у Дмитрия из 15 протестированных моделей только одна показала нужный баланс критериев для конкретной задачи, и без систематического тестирования выбрать её заранее было бы невозможно.
Это конспект третьего из шести занятий «Вечерней школы. ИИ для инженеров: польза и риски». Дальше в программе были юридические риски использования ИИ, дообучение LLM под конкретный SOC и разговор о том, как вообще меняется инженерное мышление в эпоху LLM.
Посмотреть запись этого занятия можно на YouTube по прямой ссылке, а все шесть занятий школы собраны в плейлисте «Вечерней школы. ИИ для инженеров».
А если хочется пройти всю школу целиком, с материалами и файлами для практики после каждого занятия, доступ к курсу на обучающей платформе Слёрма можно получить на сайте slurm.io/ai-school.
