Компании, которые внедряют ИИ в бизнес, часто сталкиваются с рядом сложностей: хаотичные данные клиентов, разрозненные требования, устаревшие системы, а также недоверие клиентов к технологиям искусственного интеллекта. CloudMile, имеющая опыт работы с тысячами проектов в разных отраслях (финансы, полупроводники и др.), выделила ключевые этапы и нюансы успешного внедрения ИИ.
Важную роль в этом процессе играет концепция FDE (Forward Deployed Engineer, передний инженер по развёртыванию). Её впервые предложил Palantir, а поддержали OpenAI, Anthropic и другие AI‑компании. Суть концепции в том, что продукт — это не просто модель ИИ, а надёжность системы в целом. Чтобы решить проблемы клиента, нужно не только разрабатывать инструменты в офисе, но и глубоко погружаться в его работу: изучать процессы, выявлять узкие места и в итоге поставлять стабильную систему.
CloudMile определила 5 этапов внедрения ИИ. Первый этап начинается с переговоров после получения запроса от клиента — здесь важно не спешить с написанием кода. В ходе переговоров необходимо выяснить:
* какие проблемы наиболее актуальны для клиента (а не какие решения он хочет реализовать);
* есть ли бюджет на проект и каков его объём (это влияет на дизайн решения);
* как устроены внутренние процессы клиента;
* кто принимает окончательные решения по проекту (важно избежать ситуации, когда спустя 3 месяца переговоров выясняется, что ключевые лица не были вовлечены).
Также важно проанализировать данные клиента: какие данные есть, какого они качества, где хранятся, насколько они чистые («Garbage in, garbage out» — «мусор на входе — мусор на выходе»). При этом есть сложность: клиент не всегда может чётко сформулировать свои требования.
Например, компания обратилась с запросом на создание HR‑системы: изначально требовалось использовать ИИ для анализа резюме и сокращения времени отбора персонала. Была создана демо‑версия: HR загружает резюме, ИИ автоматически анализирует и выдаёт оценку. После демонстрации клиент начал расширять требования — захотел изменить UI/UX, добавить PM, подключить внешние платформы, предложил создать AI‑агента в роли интервьюера. Требования не формулируются заранее — они появляются после демонстрации продукта. Для управления расширением требований нужно заново определять рамки проекта. Например, после разработки и демонстрации версии функционала с AI‑интервьюером стало понятно, что функция далека от реальных потребностей, а затраты не оправданы. В итоге решили сосредоточиться на анализе резюме.
Ещё один пример — проект для розничного канала. Проблема заключалась в том, что поставщики присылали изображения товаров без названий и классификации, а также множество документов (счета, сертификаты, накладные). Сотрудникам приходилось вручную сверять данные, что было трудоёмко и чревато ошибками. Разработали два инструмента:
* один — на основе мультимодальной модели для автоматической классификации изображений товаров и извлечения информации;
* второй — для распознавания документов, извлечения ключевых полей, перекрёстной сверки и формирования отчёта о различиях.
Выяснилось, что на подтверждение требований и проектирование решения уходит около 30% времени проекта — ещё до написания первого кода. Этот этап нельзя сокращать, так как экономия времени на нём приводит к большим затратам на доработку в дальнейшем.
На этапе разработки и тестирования возникает расхождение между представлением инженера о рабочем процессе и реальным способом работы пользователя. Например, в проекте по сверке документов изначально предполагалось, что пользователь будет загружать все документы сразу перед анализом. Но на практике пользователи начинали сравнение документов, не дожидаясь всех данных, имея лишь несколько частей. Система была переработана, чтобы подстраиваться под рабочий ритм пользователей, а не требовать от них адаптации к инструменту.
Также была решена проблема с отображением «None» в случае отсутствия данных в поле: это было непонятно пользователям. Проблему решили, выделив «None» красным цветом и преобразовав расхождения между документами в понятный текст.
Многие проблемы, которые изначально кажутся связанными с моделью, на деле обусловлены качеством данных и их соответствием реальным условиям использования. При приёмке и запуске ИИ нельзя оценивать его по «ощущениям от чата», так как вывод ИИ содержит неопределённость — одинаковые запросы могут давать разные ответы. Вместо этого нужно использовать систему оценки качества ИИ (Evaluation). Например, в финансовом проекте применялся NL to SQL.
Для оценки ИИ используют реальные данные за последние три месяца как эталон, а также ручные запросы как эталонный ответ, затем сравнивают результаты ИИ и человека. Важно совместно с клиентом утвердить набор тестовых данных для критериев приёмки. Неопределённость ИИ нельзя устранить, но можно управлять ею. После запуска поведение ИИ может меняться из‑за изменения данных или условий использования — система может начать давать ошибочные ответы. Каждый агент отслеживается в рамках Evaluation. В финансовой отрасли стремятся к почти нулевому количеству ошибок, в ритейле, играх, Web3 допустимый уровень ошибок отличается. Стандарты приёмки различаются в зависимости от отрасли.
Подписаться в Макс
