Привет, на связи Юлия Рогозина, аналитик бизнес-процессов Шерпа Роботикс. Сегодня я перевела для вас статью, тема которой касается именно использования Large Language Models (LLM) как части вашего продукта, а не использования ИИ как инструмента в процессе разработки (например, таких инструментов, как Cursor или Zed AI).

Применение LLM для выполнения определённых задач в рамках жизненного цикла разработки программного обеспечения (SDLA) имеет свои проблемы. Однако важно понимать, что то, как мы создаём продукт, обычно отличается от того, что мы продаём конечным пользователям. 

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

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

LLM противоречат одному из основных принципов вычислительной техники — идее, что задачи можно разбивать на составные части. 

Рабочий компонент программного обеспечения, независимо от того, был ли он создан внутри компании или нет, состоит из кода, который можно протестировать с использованием юнит-тестов. Эти компоненты должны взаимодействовать друг с другом надёжно и предсказуемо. Возьмём, к примеру, продукт, использующий базу данных Oracle. Мы все понимаем, что сохранение данных — это элемент проектирования, а решение о типе хранилища принимается на техническом уровне. Уже на этом этапе часто задействуются тестовые сценарии, и хотя инновации в области баз данных продолжаются, ни у одного клиента не возникнет мысли, что провайдер хранилища каким-то образом контролирует программное обеспечение.

В академической среде проблемы с отсутствием декомпозируемости часто сочетаются с проблемой необъяснимости. Это ведет к ряду серьёзных бизнес-проблем, которые влияют на использование LLM в реальных программных решениях.

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

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

Юридическая собственность остается проблемной. Мы можем доказать, что результат операции, выполненной с помощью холодного вычисления, является повторяемым и всегда дал бы тот же ответ при одинаковых исходных данных. Однако, поскольку LLM всегда несет с собой «груз» данных, на которых она обучалась, мы просто не можем доказать, что она не использовала чужие разработки.

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

Статья, однако, не о том, как использовать LLM для помощи в разработке, и не о том, чтобы просто дать конечному пользователю «сырой» доступ к утилите LLM с циничным пожиманием плеч.

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

По изложенным выше причинам невысока вероятность, что LLM имеет будущее в качестве сервисов в составе продуктов — за исключением случаев, когда сам продукт и будет являться LLM.

Но даже это — серьезная ловушка для бизнеса.

Когда Эрик Юань, основатель Zoom, представил идею присутствия ИИ-клонов на совещаниях в Zoom, его справедливо высмеяли за то, что он ожидал, что эта возможность появится каким-то образом «на нижних уровнях». Передав основные инновации поставщику LLM-моделей, он просто передал контроль над своей дорожной картой другой компании.

Как разработчики программного обеспечения должны реагировать на это?

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

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

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

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

Но теоретически, нет причин, почему это не может измениться в будущем.

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

Комментарий Юлии

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

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

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

В связи с этим в нашей компании специалисты развивают методы дообучения LLM.

В частности, наш эксперт применяет подход In-Context fine-tuning, который объединяет в себе классический RAG и fine-tuning.

В следующих статьях я планирую подробно остановиться на этом подходе к дообучению.

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