Как управлять ИИ-проектами: честно о компромиссах, данных и реальных ограничениях бизнеса

Внедрение решений ИИ подразумевает не просто установку библиотеки и подключения к API. Это постоянный компромисс между качеством данных, точностью ответов и скоростью работы, и эксперименты становятся обязательными стадиями проекта.

Как выбирать между классическим ML и большой языковой моделью? Как принимать решения, когда данные неструктурированы? Что делать, если решение работает в тесте, но падает в контуре? И главное, как не провалить ИИ-проект, ориентируясь не на моду, а на реальные ограничения бизнеса? Ответы на эти вопросы разбирали экспреты Академии АйТи (кластер fabricaONE.AI ГК Softline) Даниил Монахов и Наталья Елисеева на вебинаре «ИИ-проект ≠ ИТ-проект: что должен знать руководитель до старта».

		Наталья Елисеева, ведущий менеджер по развитию технологической экспертизы SLSoft
		Даниил Монахов, руководитель комплексных проектов ИИ SLSoft

ML или LLM: не спрашивайте заказчика, а учитывайте его ограничения

Практика показывает: выбор технологии невозможен без предварительного анализа данных и тестирования нескольких вариантов решения. Получив от data-команды объективные показатели по точности, срокам и стоимости для каждого из них, заказчик выбирает оптимальный вариант с учетом своих бизнес ограничений: бюджет, время, политика безопасности.

ML требует размеченных данных. Для обучения понадобятся сотни или тысячи документов одного типа. При этом модель работает быстро и не нуждается в мощных GPU. В отличие от экспертных систем, ML не строится на жестких правилах «если, то,  иначе»: модель самостоятельно выявляет закономерности на предоставленных примерах.

LLM работает со смыслами. Например, необходимо сравнить два договора и найти противоречия. ML будет искать конкретные несовпадения: расхождения в суммах, датах завершения, штрафных санкциях. LLM пойдет глубже. Если в одном договоре запрещено привлекать подрядчиков, а в другом указано «применять третью сторону для исполнения работ», LLM выявит смысловое противоречие, хотя формулировки не совпадают дословно.

Выбор между классическим ML и LLM определяется не только характером задачи, но и доступными ресурсами. В практике тренеров Академии АйТи, действующих специалистов, был случай, когда крупный заказчик не мог определить, какой подход для него предпочтительнее. Провели исследование на небольших датасетах: от двух до пяти тысяч документов. Замеры показали: ML с точностью 85 % на настройку одного пакета документов требует около трех месяцев. LLM достигает той же точности за три-четыре недели, но нуждается в GPU для параллельных вычислений. В итоге заказчик выбрал ML, поскольку не был ограничен сроками и мог выделить три месяца, а также не хотел использовать генеративные сервисы. Так удалось сэкономить средства на ненужном оборудовании и найти решение, реально подходящее заказчику.

Высокая неопределенность в ИИ-проекте требует экспериментов для проверки достижимости метрик и сравнения подходов. В результате принимается решение о целесообразности продолжения и уточненные требования.

Как бороться с галлюцинациями LLM и дрейфом данных

Ситуации, когда модель генерирует информацию, отсутствующую в исходных данных, либо уверенно утверждает то, чего не было обозначаются как галлюцинации. Одним из способов борьбы является технология RAG, ограничивающая модель конкретным набором документов. Например, загружены гражданский и административный кодексы, ответы будут только по ним, точность повышается до 85-90 %. При сходстве двух документов модель может скомбинировать фрагменты из разных источников и это будет не чистая галлюцинация, а потеря релевантности, обращения к внешним источникам не произойдет.

С помощью корректно составленного промпта можно задать два правила. Первое: при отсутствии ответа модель должна сообщать «я не знаю». Второе: при обнаружении противоречий в разных источниках следует приводить все источники для самостоятельного решения пользователя. Эти методы не решают проблему полностью, но для большинства типовых проектов их достаточно.

Однако галлюцинации не являются единственной угрозой. После сдачи ИИ-проекта возникает другая проблема: дрейф данных. В классическом ИТ-проекте жизненный цикл завершается приемкой продукта. В ИИ-проекте после сдачи начинается непрерывный мониторинг и дообучение (MLOps). Дрейф данных, изменение поведения модели, появление новых форматов документов требуют постоянного внимания.

Инфраструктурные ограничения: от дефицита GPU до сюрпризов безопасности

Значительным ограничением является отсутствие у заказчика графических процессоров (GPU). При локальном развертывании LLM требуются дорогостоящая инфраструктура. Острее всего проблема проявляется в государственном секторе, где из-за строгих требований к безопасности нельзя пользоваться облачными версиями и модели приходится устанавливать внутри собственного периметра. Однако у многих организаций не хватает вычислительных мощностей, а их закупка и обслуживание вводят дополнительные расходы. В итоге ИТ-службы и подразделения информационной безопасности разворачивают LLM во внутренней сети, но несут заметные финансовые нагрузки. 

Технически модель возможно загрузить на собственный компьютер. Существуют модификации разного объема: от сотен миллионов до сотен миллиардов параметров. В промышленных системах используются специализированные версии LLM, адаптированные под конкретные задачи. Следовательно, необходимо точно знать вычислительные ресурсы заказчика и его готовность подключаться к облачным сервисам.

Но даже при совпадении формальных параметров могут проявиться скрытые ограничения, связанные с настройками безопасности. В практике наших экспертов был случай, когда внешне все выглядело одинаково: модель Qwen, аналогичные вычислительные мощности и видеокарты. При тестировании в собственном периметре загрузка документа на сто страниц проходила штатно. У заказчика при загрузке того же документа система корректно обрабатывала только двадцать страниц, а по остальным генерировала ответы, не основанные на исходных данных, из-за выхода за пределы ограниченного контекста. Это классический пример галлюцинации из-за неучтенных ограничений контекста. Причиной оказалось искусственное ограничение размера контекста, заданное настройками безопасности заказчика. Выявить это смог только опытный ML-инженер.

О тестировании и договоренностях

Приведем пример проекта с крупной нефтяной компанией. Заказчик поставил задачу: в системе электронного документооборота находится 10 миллионов документов. Традиционный поиск неэффективен, сотрудники затрачивают избыточное время. Требовалось обеспечить выдачу всех документов, содержащих точное сочетание слов, указанное в поисковой строке, а также реализовать смысловой поиск по внутренним документам компании, например: «найди документы, регламентирующие использование автотранспорта при транспортировке негабаритных грузов» или «правила перевода письменного стола».

Команда не стала сразу разрабатывать жесткое техническое задание. Вместо этого они провели несколько экспериментальных итераций с тестированием гибридного поиска, векторных представлений и RAG. Финальную архитектуру выбрали после нескольких циклов.

Обычно для подобных задач применяется RAG – технология, находящая релевантный фрагмент текста в ограниченном массиве документов, перефразирующая его и предоставляющая ссылку. RAG эффективен, когда число документов измеряется тысячами, но не миллионами.

В рассматриваемом случае RAG оказался неприменим: перебор десяти миллионов документов за один запрос занимал много времени. ML-инженеры спроектировали многоуровневое решение: от метаданных к ключевым фрагментам и затем к полному тексту. Опуская технические детали, работу вели на тестовой выборке из ста тысяч документов, что позволяло впоследствии масштабироваться на все десять миллионов. Решение протестировали  и передали в пилотный контур заказчика.

В боевом контуре решение перестало работать корректно: обработка запроса занимала не 10-15 секунд, как в тестовой среде, а 10-15 минут. Выяснилось, что заказчик развернул решение на виртуальных машинах, а не на физических. Высоконагруженные операции ввода-вывода (индексация, поиск по миллионам документов, постоянное чтение с диска) на виртуализированном оборудовании дают значительные накладные расходы из-за разделения ресурсов между несколькими виртуальными машинами. Сложная интеллектуальная задача, успешно решеная на физических серверах, упирается в архитектурную деталь, не учтенную на этапе проектирования. Этот фактор необходимо включать в риски и обязательно тестировать решение на боевых мощностях, а не только на тестовых.

Еще один пример показывает, почему при тестировании ИИ-систем нельзя полагаться только на предоставленный датасет. Перед командой стояла задача обработки медицинских справок. В документах встречались печатный и рукописный текст, таблицы, печати, подписи. Часть полей заполнялась вручную, штамп мог располагаться в левом или правом верхнем углу. Формат справок варьировался, практически ни одна не повторяла другую.

Требовалось выделить, кто выдал справку, дату выдачи, кому выдана, наличие печати, штампа и подписи. Решение реализовали на мультимодальной LLM, обрабатывающей одновременно текст и изображения. Заказчик после демонстрации отказался оценивать систему на документах, которые она уже видела. Он попросил в реальном времени подавать новые, ранее не встречавшиеся справки. Справки предоставили, точность замерили, она подтвердила заявленные 85 %. Затем последовал следующий тест. Заказчик спросил: «Если я удалю печать в графическом редакторе, система зафиксирует ее отсутствие?» Эксперимент провели: печать стерли, справку подали,  система не обнаружила оттиск. Система отработала корректно, печати действительно не было, но сам запрос вышел за рамки исходного технического задания.

Этот пример показывает, что заказчик может тестировать систему способами, не прописанными в ТЗ. Границы ответственности и сценарии использования необходимо оговаривать до подписания контракта. Пример формулировки для договора: «Заказчик подтверждает, что система протестирована на репрезентативной выборке из N документов. Намеренное искажение входных данных (удаление печатей, обрезка фрагментов) не является предусмотренным сценарием использования и может снижать точность».

Как LLM помогают писать технические задания: опыт компании

Опыт показывает: использование больших языковых моделей для управления проектами не просто поощряется, а рекомендуется. В настоящее время около 80 % технических заданий создается с помощью LLM. Процесс выглядит так: записывается интервью с заказчиком, затем разговор транскрибируется с использованием ИИ, голос преобразуется в текст, текст распределяется по ролям, выделяются ключевые смыслы. После этого транскрипт загружается в LLM вместе с описанием сервисов и функционалов, уже реализованных на других проектах. Перед моделью ставится задача сопоставить пожелания заказчика с накопленными компетенциями команды.

LLM можно применять не только для генерации ТЗ «с нуля», но и для анализа уже готовых, предоставленных заказчиком документов. Например, крупный банк предоставил детальное ТЗ на десятки страниц, редкий случай исчерпывающей документации: юридический отдел, бухгалтерия, операционный комплаенс, требования 115-ФЗ, кредитные аналитики с предиктивной аналитикой по невозвратам. Каждое требование было детализировано и привязано к конкретным функциональным группам. Это ТЗ загрузили в собственную LLM, развернутую во внутреннем периметре, и запросили перечень уже реализованных функций. Набралось около пятидесяти: выделение атрибутов, интеллектуальный поиск, чат-бот и другие. Модель сопоставила требования банка с наработанными компетенциями. В итоге команда приступила к проекту, зная, что выполнит задачи, и четко представляла самые сложные участки работы.

Вместо заключения

Управление ИИ-проектами требует пересмотра классических подходов. Четыре практических вывода из опыта наших экспертов:

1. Качество данных и описание процессов необходимо проверять до старта, и продолжать проверять на каждой итерации. Даже 10 миллионов документов не спасут, если они плохо структурированы или развернуты на виртуальных машинах без учета I/O-нагрузки.

2. Важно заранее согласовать с заказчиком метрики успеха и честно объяснить, что и почему недостижимо. А также прописать границы тестирования.

3. Выбор между классическим ML и LLM должен относится не к предпочтениям, а к результату экспериментов на реальных данных. Необходимо учитывать инфраструктурные ограничения: наличие GPU, политики безопасности, допустимость облаков.

4. Не стоит бояться использовать ИИ для управления проектами (например, для генерации ТЗ). Это реально экономит сотни часов и помогает быстрее сопоставлять требования с компетенциями команды.

Там, где задействованы деньги и время, задачей команды становится сберечь ресурсы компании. К Искусственному интеллекту необходимо понимающее отношение, как к инженерное дисциплине с высокой долей экспериментов. Каждую галлюцинацию модели необходимо отрабатывать с уточнениями промтов, и каждый сбой требуется закладывать в риски.