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

Откуда у C‑level берётся представление о розовых единорогах?

Как обычно всё происходит? Руководство компании икс живёт вполне себе людской жизнью и так же, как и обычные люди, получает информацию из тех же источников, что и остальные. Понятно, что есть и специфические каналы получения информации у разных категорий лиц, но мы говорим о тех источниках, которыми пользуются все.

К таким источникам можно отнести, конечно же, интернет‑ресурсы. Чаще всего это статьи на сайтах и видео на разных площадках. Реже — это информация из новостей по телевидению или из книг.

Какая информация находится в таких источниках? Ответ прост: любая. Но важно не это, а процент верных данных. Если разобраться, то достаточно просто запустить рекламную кампанию на любой из популярных площадок — и порой это вовсе не за деньги.

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

Вот из всего этого шума, который на первый взгляд хаотичный, но по факту состоит из выстроенных процессов и политик тех, кому тот или иной «кирпичик» выгоден, и состоит наш информационный канал.

А теперь, если собрать воедино всё, о чём было написано выше, получается, что мы чаще всего слышим и видим то, что ИИ захватывает мир, вот‑вот и свершится бум, так как скоро ИИ наделят разумом, подобным разуму человека, или ИИ сэкономил какой‑то крупной компании миллиарды.

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

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

Вот примерно так и формируется мнение и стереотипы масс под напором новостей и слов авторитетных людей. Так у C‑level зарождается мысль о внедрении ИИ и о том, что это панацея. Возможно, даже не во всём, а только в одном или в части.

Они убеждены, что решают конкретную проблему для бизнеса. Убеждены в том, что ценность от внедрения ИИ достаточно велика. Что деньги, которые будут вложены во внедрение ИИ или даже в трансформацию, легко окупятся. В любом случае графики в человеко‑часах говорят именно об этом. У бизнеса просто нет шансов не попасться на эту удочку.

Но ведь любой руководитель достаточно грамотен и осведомлён, в том числе технически, так как в его окружении находится армия технарей. Так почему же на крючок всё равно попадаются?

Об этом ниже в разделе «Почему никто не говорит о том, что ИИ — это не швейцарский нож и подходит не для всех задач?».

Почему не во всех компаниях ИИ взлетает?

a) ИИ просто изначально не подходит

Самая частая и банальная причина — ИИ просто изначально не подходил для решения конкретной задачи, круга задач или цели (целей). Такое происходит из‑за того, что при задумке очень часто опускаются и остаются непроработанными достаточно важные моменты. Совокупность таких моментов вполне способна определить исход: внедрять ИИ или это плохая идея. Но такого не происходит, так как невозможно всё просчитать, и порою всё кажется очевидным и прозрачным. Поэтому внедрение часто рассматривается сквозь пальцы.

Примерно так: есть данные, есть модель, есть DevOps, есть ресурсы, есть инфраструктура… Что ещё нужно? Всё есть? Да, все компоненты присутствуют. Тогда — в путь!

А как насчёт того, чтобы просчитать и учесть фактор шумных соседей на арендованном «железе» в виде GPU в облаке? Как учесть, что в облаке соединители не в виде NVLink или что время по итогу превысит ожидания на пару секунд, что станет критичным для всего мероприятия?

Вот такие моменты — и ещё кучу других — мы просто опускаем, а точнее, даже не задумываемся об этом при проектировании. А потом удивляемся, что версия ядра cuda не работает на конкретном фреймворке под устаревшими драйверами — в случае, если всё же отважились на on‑premise‑решение.

b) Низкое качество данных

Это следующая по популярности причина, почему не взлетело. Дело в том, что при моделировании процессов происходит то же самое: многие моменты просто‑напросто не учитываются.

Например, при мыслях о данных самое первое, на что обращают внимание, — это на достаточность и полноту данных. Казалось бы, действительно, что может быть важнее, чем объём, непротиворечивость и достоверность? Но дело в том, что данные из разделов могут быть очень близкими и похожими. Данные могут изменяться в моменте, могут очень быстро стать противоречивыми. Какие‑то сведения схлопываются и обретают общие универсальные формулировки и т. п.

Как в таком случае строить тот же RAG? Он будет смешанным или только на графах? Какой инструмент будет использоваться для эмбеддинга? И это всё чрезвычайно важно.

Важно и то, как переобучить модель, которая уже была зафейнтюнингована до этого. Какие техники для этого будут применяться? В каком соотношении документы должны быть «скормлены», чтобы установить иерархичность источников, которая должна быть учтена при «раздумьях» модели?

Заметили, сколько много вопросов? А ведь это всё ещё связано между собой и зависит от ещё +100 500 факторов.

Возможно ли всё это предусмотреть команде технических специалистов? Нет, так как они не погружены в предметную область. А если и погружены, то насколько глубоко? Они же ведь технари.

Со стороны бизнеса — точно такая же ситуация: погружён ли бизнес в технические дебри? Очевидно, что нет. Да и бизнес другой бизнес порою не понимает. Например, ответ на вопрос «Как дела?» в виде пресловутого «Нормально» может значить всё что угодно.

То ли дело технари: код, написанный на одном конце света, будет прочитан и однозначно понят на другом конце света. Ну да ладно, это всё лирика, а мы живём в суровом мире IT!

c) Непонимание предметной области

Это находит своё отражение в непонимании того, как протекают процессы компании, или в непонимании всех тонкостей, которые в конечном счёте могут играть решающую роль.

Можно много размышлять, откуда берутся данные, как они сопоставляются с другими данными и в каких структурах находятся. Но всё меняется, когда появляется вопрос: «А кто отвечает за те или иные данные?»

Если владелец вдруг нашёлся, то тут же можно смело задать вопрос о качестве данных:

какой фреймворк?

какие правила?

кто владелец правил?

А если данные обогащаются, то кто будет владельцем у них? И достаточно ли правила описывают ожидаемое?

Предположим, на эти вопросы мы каким‑то чудом получили положительный ответ. Но тогда идём дальше — и возникает следующий вопрос о готовности мастер‑системы к изменениям. Соответствует ли структура и контейнер должному уровню, чтобы отвечать всем требованиям из разряда консистентности и доступности? А что произойдёт, если столбец в таблице пропадёт? Как это повлияет на весь процесс выгрузки, доставки, обучения модели?

d) Непрофессионализм менеджеров со стороны разработки (к разрабам вопросов нет)

Зачастую менеджеры уходят в формализм. Происходит это примерно так: «В самом начале дайте нам данные для обучения модели. Дали? Отлично, теперь мы на этих данных будем творить чудо».

Ой, не получилось? Но виноваты вы, так как именно вы предоставили противоречивые или некачественные данные. Мы всего лишь исполнители и работаем с материалом, который предоставляет заказчик.

Это в корне неправильная позиция, ведь к ним и обратились как к профессионалам, а тут такое.

Далее начинается самое интересное: есть результаты, но неудовлетворительные. И вместо того, чтобы продумать подход, менеджеры дают команду залатать брешь, чтобы показать бизнесу, что теперь эта конкретная неточность устранена. А далее появляется ещё, и ещё, и ещё — и так до бесконечности, потому что процессы и данные видоизменяются, и происходит это постоянно!

Почему никто не говорит о том, что ИИ — это не швейцарский нож и подходит не для всех задач?

Дело в том, что в бизнесе достаточно грамотные люди. Они могут легко понять, что делает та или иная технология и как устроен тот или иной компонент. А если такие люди ещё и часто общаются с технарями, то уровень технической подкованности просто начинает зашкаливать.

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

Но есть одна проблема: указанная категория ребят — T‑shape, так как им нужно знать много всего и «по верхам».

Возникает вопрос: а что, если сходить к ребятам «на земле» — к самим разработчикам? Конечно, можно! Так многие и делают, для того чтобы со всех сторон решение было взвешенным и объективным.

Так в чём же тогда проблема? А в том, что нужно массу всего увязать. Не всегда нас окружают люди, опыт которых достаточен. Да, часто это хорошие профессионалы, но невозможно иметь опыт во всём или во всём, но нельзя всего знать идеально.

Дальше к этому подмешиваются проблемы коммуникаций, чрезмерная уверенность без подтверждения, опускание некоторых важных факторов, которые для кого‑то само собой разумеются, а для кого‑то — полная неизвестность. Вот и получаем то, что тонны процессов нужно согласовать, а во всех процессах — люди. Думаю, не стоит говорить о человеческом факторе…

Итог:

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

Уверенность и давление со стороны социума просто не оставляют шансов на трезвое решение. Всё воспринимается так, что решать проблемы будем по мере поступления.

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

Но так ли всё плохо? Конечно, нет! Может быть и ещё хуже, а может быть и лучше!

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

До встречи!