Ваш любимый ИИ не умеет считать. Что ещё скрывает текстовая модель?

2026-04-17 в 9:15, admin, рубрики: function calling, llm, rag, RLHF, агенты, искусственный интеллект, нейросети, цифровой двойник, языковые модели

Технократический разбор для инженеров и бизнес-аналитиков. Без преувеличений и продающих лозунгов.

Данная статья представляет собой результат кабинетного исследования об основных особенностях работы ИИ (LLM, модель). Здесь в систематизированном виде относительно простым языком описано, как реализуется вся та “магия” про ИИ, с которой мы сталкиваемся сами или слышим в восторженно-продающих материалах.

Сразу уточню, что под ИИ тут понимается именно публичная Большая языковая (текстовая) модель (LLM), вроде ЧатаГПТ, ГигаЧата, Дипсика и др.

В этой статье мы:

сначала рассмотрим два базовых заблуждения относительно LLM (главы 1 и 2)
потом после минимального погружения в технологию самой LLM (глава 3) рассмотрим возможности, ограничения и особенности (глава 4), и типовые инструменты (глава 5)
эти знания дадут нам ракурс для углубленного понимания что такое ИИ-агенты (глава 6) и Цифровой двойник с ИИ (глава 7)
в заключение пробежим по типовым слоганам (глава 8) и возражениям (глава 9)

1. Границы LLM - ничего, кроме текста

Начнем с тезиса:

LLM - это текстовая генеративная нейросеть и она умеет только разговаривать: “понимать запрос” и генерировать текст.

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

Если вы просите модель создать картинку, то текстовая модель не станет делать этого сама, потому что не умеет. В этом случае LLM сформирует запрос и отправит его другой нейросети (которая умеет рисовать, но не умеет разговаривать) и покажет вам результат.

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

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

свести исходные условия к простым понятным действиям, ответ на которые очевиден
выполнить эти действия, потому что она “знает” ответ на них. Модель “воспроизведет паттерн”, что 2*2=4, потому что и вся таблица умножения и многие другие частые примеры и задачи были в обучающей выборке
собрать итоговое решение и проверить что это то, что надо

Если попросить умножить 592 на 946, то модель разобьет действия на простые (воспроизведет шаблон умножения столбиком) и скорее всего получит правильный ответ, но если вы попросите умножить 44 567,456554 × 0,000004430987, то округлит или ошибется.

Мой практический пример: недавно я отправил в Гигачат такой запрос (можете повторить): “Сколько будет 44 567,456554 × 0,000004430987?” модель поступила иначе, она написала простой код на Питон и запустила его в интерпретаторе:

a = 44567.456554
b = 0.000004430987
print(a*b)

Получила результат от интерпретатора 0.19747782061383878 и показала пользователю. Повторил опыт с другой LLM Мистраль:

модель в режиме “рассуждения” также вызвала интерпретатор, который вернул ей такой же точный ответ,
модель “решила” (вероятностно выбрала формат вывода), что такая точность мне не нужна и корректно округлила ответ до меньшего числа знаков после запятой

Тут обе модели показали правильное поведение: видя, что задача требует выполнения сложного расчета вместо того чтоб считать самостоятельно модель описала задачу (текст это её стихия) на расчет и вызвала соответствующий инструмент.

Другие типичные инструменты:

поиск в интернете (модель вызывает поисковик)
открытие страниц в интернете (модель вызывает встроенный браузер)
чтение файлов (модель вызывает сервисы извлечения текста из файлов)
рисование схем и диаграмм (модель описывает диаграмму текстом, а инструмент показывает текст в виде схемы)

Умение модели самостоятельно строить решение позволяет не объявлять явно вызов инструментов. В примере выше запрос не содержал указания “вызови нейросеть, которая рисует”, “вызови интерпретатор”, “вызови поиск в интернете” - модель вызвала инструмент сама, потому что видела его у себя в списке доступных и включила в цепочку шагов для получения ответа. Такая “неявная” работа с инструментами и дает основание для заблуждения, что модель способна на многое.

Вывод: без инструментов LLM умеет только в буквы и больше ни во что.

Далее перейдем к разбору другого распространенного заблуждения, что пользователь может чему-то научить модель.

2. Обучение это не генерация

Понимание, что разговор с пользователем ничему не учит модель, прямо следует из знания тезиса:

Обучение модели и Генерация текста (разговор с пользователем) - это два принципиально разных процесса, которые не могут происходить одновременно.

Далее чуть более развернуто. Процесс генерации текста (получения вывода на запрос пользователя) называется “инференс” и выглядит примерно так:

Модель (включающая структуру нейронов и таблицу весов) размещается в памяти видеокарты.
Управляющая программа Сервер инференса подает на вход запрос пользователя .
Модель обрабатывает запрос, пропуская его через все свои нейронные слои и выдает в качестве результата генерации 1 (ОДИН!) токен (слово или часть слова).
Сервер инференса берет этот результат генерации, присоединяет его к изначальному запросу и комбинацию опять подает на вход (повтор шага 2) (это называется “авторегрессивная генерация”). Т.е. теперь модель увидит и первоначальный запрос и то, что она уже начала отвечать и сможет продолжить.
Шаги 2-4 повторяются до тех пор, пока сервер не получит от модели специальный токен, означающий что ответ закончен.
Сервер инференса отправляет результат генерации пользователю.

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

Подчеркнем: во время Генерации таблица весов не меняется - поэтому модель в этот момент не учится

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

Полноценное обучение чистой модели с нуля называется предобучение (pretraining) (как часть Глубокого обучения “deep learning”) - это дорого и долго, потому что требует очень большого корпуса обучающих данных и много времени на сам процесс обучения. В ситуации, если надо, чтоб модель “знала” детали в какой-то узкой предметной области применяют другой подход - доучивание “fine-tuning”. При этом фактически берут уже обученную базовую модель и подвергают её обучению дополнительным материалам. Это существенно быстрее и менее требовательно к объему обучающих данных, но тоже ощутимо по срокам и стоимости.

Возвращаясь к вопросу о влиянии на модель диалога с пользователем, ответ теперь понятен - именно та модель именно в момент разговора ничему не учится. Однако многие провайдеры публичных LLM используют диалоги с пользователем для обучения будущих версий своих моделей. В профиле пользователя доступна опция “Разрешите использовать ваш контент для обучения наших моделей и улучшения наших сервисов. Мы обеспечиваем конфиденциальность ваших данных.”, при выборе которой поставщик обезличит ваши диалоги и включит в “учебник” новых моделей. И с этой точки зрения ваши диалоги способны повлиять на LLM.

Если обучение - это дорого и долго, как же тогда нам сделать так, чтоб модель знала наши инструкции и нашу информацию.

Ответ следует из описанного выше процесса инференса (генерации текста) - для этого процесса у модели есть только запрос и таблица весов. А поскольку изменение весов - это обучение, то у нас остается только запрос (системный промпт, контекст и пользовательский запрос) как единственный способ повлиять на модель и больше ничего. И все технологии, которые мы рассмотрим в дальнейшем так или иначе направлены на “обогащение” именно запроса.

Теперь мы знаем что LLM это генератор текста на основе знаний, помещенных в нее заранее или переданных с запросом.

А что представляет из себя LLM с более технической стороны рассмотрим в следующей главе.

3. Что такое LLM

Сделаем микро-экскурс в историю вопроса (глазами стороннего наблюдателя):

Давно существует большая область, которая называется искусственный интеллект, ИИ еще десятилетия назад лет назад обещал скорое появление думающих роботов и т.п. Эта область имеет “старые” достижения вроде Экспертных систем, с которыми никто кроме узких специалистов не сталкивался и относительно “новые” достижения вроде ML - где знания не закладываются в явном виде, а “сами” формируются когда мы обучаем модели (нейросети с определенной структурой).
Современные достижения ML вроде компьютерного зрения, распознавания речи и семантических анализаторов (оценка тональности текста) активно применяются как в промышленных системах, так и в нашей повседневной жизни.
Относительно недавно появились и активно начали захватывать всю нашу жизнь нейросети с которыми можно поговорить или которые по текстовому запросу могут создать изображение или музыку.

Вот этот последний прорыв случился благодаря:

нейросетям особого типа “Трансформер” (вдохновлённый некоторыми принципами обработки информации в мозге);
тому, что получив подтверждения в экспериментальных образцах были затрачены усилия на глобальное обучение Трансформеров очень большого размера на данных “примерно всего интернета”.

Этот результат начали называть Большая языковая модель (LLM). Её свойством и единственной “родной” способностью является “понимание” текста и генерация текста. Только текста и больше ничего.

Современная публичная LLM - это связка двух крупных блоков:

трансформер, который обеспечивает понимание текста и генерацию;
RLHF (обучение с подкреплением на основе обратной связи человека), который делает модель послушной и настраивает её на формат ассистента.

Трансформер “видит” все сразу

Архитектура трансформер, в отличие от старых нейросетей, которые обрабатывали текст слово за словом, позволяет подать на вход, а значит “увидеть” весь запрос целиком. Максимальный размер запроса соответствует “ширине” LLM и называется контекстным окном.

Благодаря этой особенности трансформер замечает противоречия и закономерности, не воспринимаемые обычными алгоритмами. Если в одном месте будет сказано “статья для специалистов без технических навыков”, а в другом месте введены термины Инференс “deep learning” и “fine-tuning” без должного объяснения - модель заметит нестыковку.

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

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

Объяснение такое: “Трансформер работает с паттернами (шаблонами/схемами) и эти паттерны образуют вложенную иерархию: некоторые задают очень крупно структуру всего ответа (чертёж дома), другие определяют порядок слов внутри фраз (кладка кирпичей). Их совместная работа и создаёт иллюзию, что модель «видит» на несколько фраз вперёд.”

Генерацию LLM сравнить с импровизацией, например, джазового музыканта: он не знает следующей ноты, но общее направление задано тональностью и ритмом.

Дрессировка модели

LLM как обученный трансформер (без надстройки) - это просто генератор продолжений текстов. Если такой модели написать просто “Привет”, то она может продолжить его произвольно, например так “[Привет], сказал Пяточек Гене и сел в сугроб” или продолжить писать письмо и др.

Для того чтоб объяснить, что любой текст от пользователя - это инструкция, на которую надо ответить полезно, безопасно и правдиво используют Обучение с подкреплением (RLHF - Reinforcement Learning with Human Feedback).

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

Простыми словами RLHF это как дрессировка собаки. Если до этого модель умеет говорить и не умеет считать, то после дрессировки (RLHF) она по‑прежнему не умеет считать, но уже разговаривает с уважением и даже готова предложить вам дружбу и назвать вас «крестным».

Итог: LLM = комбинация двух технологий: трансформер (воспроизводит шаблоны/паттерны) + RLHF (дрессировка, следование инструкциям и безопасность).

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

4. Сильные и слабые стороны

Текстовая модель “из коробки” имеет возможность:

понять запрос (на естественном языке);
ответить из своих знаний (до даты обучения);
ответить, используя внешнюю базу знаний (RAG — Retrieval-Augmented Generation) (подробнее - далее);
трансформировать текст: обобщить/ детализировать, сменить тон, сменить направленность текста (бизнес/ технический) и т.п.;
следовать инструкциям, заданным в промпте (описание роли, доступных инструментов, правил работы);
понять какие инструменты доступны:
- какие параметры они требуют и что возвращают;
- оценить достаточно ли информации для вызова инструмента;
- вызвать инструмент в правильном формате и интерпретировать результат;
построить последовательность решения задачи (в т.ч. уточнения у пользователя, вызовы инструментов и т.п.) (пошаговые рассуждения — Chain of Thought);
получать и отвечать в машиночитаемом формате (json, yaml, xml и т.п.).

Другими словами, модель может делать с текстом почти все.

При этом LLM имеет следующие ограничения, которые напрямую следуют из ее архитектуры, а именно не может своими силами:

выполнять математические расчеты (даже в элементарных может допустить ошибку);
держать в “памяти” в моменте (а значит учитывать в рассуждениях) большой объем информации (есть жёсткий лимит контекстного окна);
помнить о пользователе после завершения сессии (без сохранения истории и повторной подачи её в новый контекст);
выполнять операции над большими датасетами (миллионы строк не помещаются в контекст) и модель не умеет их обрабатывать как табличный процессор (нужны инструменты, например, код на Python или SQL);
знать данные на текущий момент - знания во внутренней памяти ограничены датой окончания обучения.

Также следует принимать во внимание следующие особенности:

Ответ модели не идемпотентен: при одном и том же запросе модель может выдавать разные ответы (из-за вероятностной природы генерации и случайных факторов).
Иногда модель может нарушать инструкции к форме вывода: несмотря на чёткое описание требуемого формата в системном промпте, модель может «галлюцинировать» и выдать ответ в другом формате (например, добавить лишний текст вне JSON, нарушить структуру). Это требует дополнительной валидации и обработки ошибок в продакшн-системах.
Чувствительность к формулировке запроса: даже небольшое изменение промпта может сильно изменить ответ.
Ответ модели (генерация) - это всегда исполнение инструкции. Инструкции имеют иерархию:
- заложенные внутри самой модели при обучении, например, инструкции по безопасности;
- поданные в системном промпте, например, “отвечай, но соблюдай безопасность”;
- поданные в запросе пользователя, например, “вот данные, сделай это”.
Модель может галлюцинировать - это классическое “врёт как очевидец” - модель полностью уверена это правда (соответствует знаниям из таблицы весов с учетом вероятностной генерации) и это затрудняет проверку.

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

Алгоритмы — для строго формализуемых, детерминированных задач (расчёты, сортировка, криптография).
LLM — для текстовых задач (анализ, генерация, диалоги, обобщение).

А нейросети другого типа и комбинированные решения для задачи иных классов:

Другие нейросети (CNN, RNN, трансформеры не-LLM) — для обработки изображений, звука, временных рядов (распознавание, прогнозирование).
Гибридные решения — LLM/нейросети обрабатывают неструктурированные данные, алгоритмы выполняют точные вычисления.
Суррогатные модели — если точный алгоритм слишком сложен или дорог, нейросети могут дать быстрое приближение (например, прогноз погоды).

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

5. Ключевые технологии усиливающие LLM - RAG и Function Calling, Управление контекстом (запрос и история)

Что надо ИИ

Ключевой тезис: для того, чтоб получить от LLM качественный и точный ответ должно сложиться два фактора:

Модели достаточно знаний для понимания и решения поставленной задачи
Модели достаточно “рассудительности”.

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

В части знаний модели, как мы упомянули выше, у нас есть только запрос и веса (меняются обучением). Обучение мы тоже оставляем за рамками данной статьи, упоминая его только для полноты картины. Остается только управление запросом - и для большинства задач этого достаточно.

Переформулируем задачу - нам надо снабдить модель достаточным объемом знаний, передав их в составе запроса.

Здесь много зависит от типа и разнообразия задач, которые будет решать модель. Если мы настраиваем ИИ на ответы на конкретные вопросы - мы можем написать качественную инструкцию, включающую и способ решения задачи и необходимые для этого данные. Но что если спектр вопросов и объем данных велик? Эту проблему можно условно разбить на два аспекта:

Неопределённость инструкции — заранее неизвестно, по какому алгоритму отвечать, какие шаги выполнять, к какому результату прийти и при этом контекстное окно ограничено.
Неопределённость конкретных данных — заранее неизвестно, какой объём и какая именно информация потребуются для ответа, из каких источников её брать. В модель нельзя заранее заложить данные, тем более если они постоянно меняются (как остатки на складе), а для того, чтоб подать данные в запросе надо понимать, из каких именно шагов будет состоять решение (а до вызова LLM это может быть не известно).

RAG - база знаний для LLM

RAG (Retrieval-Augmented Generation) — инструмент для подтягивания относительно постоянных статичных данных, таких как документы, инструкции, регламенты и т.п. В основе этой технологии лежит поиск фрагментов текста по “семантической близости” в векторном хранилище. Описание работы этой технологии упрощенно таково:

Этап сохранения документа в хранилище: Документ (инструкция, регламент) помещается в хранилище, при этом он:

разбивается на фрагменты (просто по длине, по разделам или по смысловым блокам) и эти фрагменты называются “чанки”;
для каждого чанка вычисляется вектор - последовательность из десятка цифр.

Этап обработки запроса:

для запроса тоже вычисляется вектор;
векторное хранилище проводит поиск “близких” векторов (сравнивая вектор запроса с векторами всех чанков) и возвращает несколько (например, 10) самых близких вариантов векторов;
хранилище находит чанки, соответствующие этим векторам и возвращает это как результат.

В результате если в Базе знаний есть инструкция по эксплуатации автомобиля, и вы спрашиваете “а двери-то как открываются?”, то база знаний к примеру, вернет чанки где будет упоминание открытия/закрытия дверей (как самый близкий), а также другие фрагменты про дверные ручки и про открытие/ закрытие люка и капота (как менее вероятное).

База знаний сама только сохраняет документы и возвращает “семантически близкие” чанки в ответ на запрос. Системой дополнения генерации (RAG) она становится только в связке с LLM.

Существуют две наиболее распространенные схемы реализации RAG:

запрос пользователя до того, как его увидит LLM проходит через базу знаний и автоматически (по решению базы знаний) дополняется чанками близкими по смыслу к исходному запросу. И уже в таком дополненном виде попадает к LLM. Это называется Семантический пайплайн.
запрос пользователя попадает к модели с дополнением, что “доступна база знаний вот таким способом …” и вызов к базе знаний сделает сама LLM, если и столько раз сколько сочтет необходимым. Это называется Агентский пайплайн и реализуется с помощью второго инструмента - Вызов функций.

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

Function Calling (Tools) - инструменты для LLM

Function calling (вызов функций) — инструмент для получения живых данных и способ действовать. Модель вызывает внешние API, калькуляторы, базы данных, симуляции в реальном времени. Описание работы этой технологии упрощенно таково:

Пользователь отправляет запрос
Оркестратор дополняет запрос доступными инструментами. В состав пользовательского запроса добавляются инструкции для модели наподобие “…Тебе доступны инструменты: База знаний, для вызова ответь в таком виде [JSON-спецификация]; Вызов функции калькулятора, для вызова ответь в таком виде [JSON-спецификация]…”
Модель видит запрос и доступные инструменты и строит цепь решения, при необходимости, предполагая вызов инструментов. Если модель решит вызвать инструмент, то на данный запрос она ответит не человеко-читаемым текстом, а машино-читаемой JSON-структурой
Оркестратор (алгоритм) проверяет что ответ это JSON с ожидаемой спецификацией, валидирует и выполняет вызов инструмента
Оркестратор, получив ответ от инструмента добавляет это в историю диалога и отправляет как новый запрос в LLM. Т.е. теперь в LLM будет в составе запроса отправлено: первоначальный запрос пользователя + JSON-структура для вызова инструмента + ответ от Инструмента + Новый набор доступных инструментов.
LLM, видя всю историю диалога и новый набор доступных инструментов заново строит цепь решения задачи и либо вызывает новый инструмент либо дает ответ на первоначальный запрос
Оркестратор проверяет, что ответ это не JSON, а простой текст и отправляет его пользователю. При этом факт вызова инструментов обычно скрывается от пользователя для его удобства.

Предоставив модели доступ к Инструментам, мы снимаем ограничение на неопределенность данных, а также открываем возможность осуществлять (через Оркестратор) самые разные действия. Мы не знаем, какие данные нужны модели, но теперь модель сама может их запросить, указав что именно сейчас надо. Например, модель вызывает по API ИТ-систему склада, получает остаток 23 штуки и использует это в ответе.

RAG и Function Calling не заменяют друг друга. RAG нужен для того, что редко меняется (документы, инструкции) - статика. Function calling — для того, что меняется каждый день (остатки, цены, статусы) - динамика. Вместе они позволяют модели работать в условиях неопределённости, которые для классического алгоритма были бы непреодолимы.

Оркестратор - алгоритмическое ядро ИИ-системы

Внимательный читатель при описании Function Calling обнаружил упоминание некоего Оркестратора. Оркестратора - это алгоритм, выполняющий множество задач, в т.ч.:

подает системный промпт как инструкцию - содержит роль, цели, бизнес-логику и является ключевым элементом настройки - оркестратор управляет промптами, их версионированием и оценкой эффективности;
обеспечивает память диалога - подача в составе запроса истории диалога и его суммаризация и обрезка при необходимости;
обрабатывает ошибки в формате вывода (если LLM работает в составе информационной системы) - валидация и повторные попытки при нарушении инструкций (например, невалидный JSON);
однократно обогащает запрос данными из базы знаний (RAG - семантический пайплайн)
дает модели возможность самой запрашивать информацию из базы знаний (RAG - агентский пайплайн);
дает модели возможность вызывать инструменты - (Function calling) модель может использовать объявленные функции;
реализует мультимодальные возможности - в т.ч. например, связать модель с сервисами распознавания и генерации речи;
дает доступ к информационным системам по API / MCP (Model Context Protocol) — интеграция с внешними сервисами;
реализует асинхронные задачи и триггеры - инициировать диалог, если агент должен работать асинхронно (например, проверять обновления);
оркестрирет суб-агентов - вызов других агентов или пайплайнов для сложных сценариев.

Среди упомянутых задач выделим “память диалога”. Это ответ на то, что модель не помнит ничего кроме текущего запроса - а значит весь диалог необходимо подавать в каждом запросе. Другими словами то, что со стороны пользователя выглядит как последовательный диалог, со стороны LLM выглядит как множество несвязанных запросов, к каждому из которых добавлен растущий “хвост” истории.

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

Повторим, RAG, дополнение запроса - это не обучение модели. Хотя внешне модель ведет себя так, как будто знает, но это знание передано в запросе, а не зашито в ее таблице весов.

В следующих двух главах остановимся на двух практических аспектах применения LLM - агентские системы и цифровые двойники

6. ИИ-агенты

С учетом рассмотренного в предыдущих главах у нас достаточно информации, чтобы рассмотреть ИИ-агентов и понять как они устроены.

Сделаем еще один небольшой экскурс в историю и расскажем, что агент, агентская система и коллаборация агентов это старые термины, которые возникли до появления LLM. Ранее агентские системы, как и вся автоматизация в целом строилась на жестких правилах и имели в основе строгий алгоритм “если-то”. Например, “Если случилось событие А (триггер) и выполнено Условие Б, то сделай В”. Схематично Агентская система до ИИ описывается так:

Агент = Триггер + Правила + Действия.

Но также как и с экспертными системами, разработка агентских систем была дорога, длительна и касалась очень немногих.

С появлением LLM ситуация изменилась. Теперь можно написать инструкцию для LLM: “Ты — агент по возвратам. У тебя есть инструменты: проверить заказ (API), найти инструкцию (RAG), вызвать оператора. Вот письмо клиента […] прими решение и ответь с уважением”. Получив такой запрос, LLM сама решает, какие инструменты вызвать и в каком порядке. Например, сначала проверить заказ, потом — если что‑то не так — найти инструкцию, а затем эскалировать оператору.

Схема теперь выглядит так:

Агент = триггер + инструкция + LLM + инструменты + действия.

Т.е. концептуально стартовый триггер и выполняемые действия остались в схеме без изменений.

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

Как принципиальное изменение можно отметить то, что правила стали вероятностными, а не строгими (детерминированными). Раньше мы были уверены что при определенных триггерах и условиях гарантировано будут выполнены конкретные действия, но количество условий для Продакшн-системы имело характер взрывного роста. То теперь “LLM принимает решение”, что сняло потребность учитывать миллион нюансов в алгоритме - теперь LLM может учесть их (и часто с достаточным уровнем качества). Одновременно с этим пропала гарантия что в схожих ситуациях будут приняты схожие решения.

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

Слабость: Модель может пропустить шаг, вызвать не тот инструмент, сгенерировать JSON с ошибками и т.п.

Для снижения вероятности ошибки есть практический паттерн: Комбинация “Агента выполняющего функцию” и “Агента проверяющего” позволяет с высокой вероятностью гарантировать постоянство качества ответа ИИ. Сначала первый агент генерирует результат, а потом второй агент проверяет результат и при наличии ошибки результат с замечаниями возвращается первому агенту для повторной генерации. Т.е. ответ модели не выпускается наружу, пока не пройдет внутреннюю валидацию. Этот прием позволяет многократно сократить вероятность ошибки, сведя ее до приемлемых величин.

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

С агентами стало понятнее - технология LLM без преувеличения дала им новое рождение и новое качество, но перейдем к другому практическому примеру - управления организацией на основе цифрового двойника.

7. Цифровые двойники

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

Интеграция разнородных данных (ERP, MES, IoT, внешние источники).
Симуляционное моделирование (дискретно-событийное, агентное, системная динамика).
Предиктивная и прескриптивная аналитика (ML, оптимизационные движки).
Интерактивная визуализация (3D, дашборды, AR/VR).
Обратная связь - влияние на реальный мир (API, интернет вещей IoT).

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

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

В отношении этого типа систем, также как с экспертными и агентскими системами, LLM приносит новое качество, в т.ч.:

Интерфейс на естественном языке (NL) между человеком и системой - LLM понимает запросы на естественном языке, превращает их в формализованные команды (NL2API, NL2SQL), обобщает и показывает пользователю результаты.
Агентность — агент действует по инструкции (системный промпт), использует инструменты для получения данных и выполнения операций, может вызывать суб-агентов.
Оркестратор планирует последовательность вызовов симуляций, оптимизаторов, запросов к данным, интерпретирует результаты.
Адаптивное управление по текстовым событиям позволяет обрабатывать текстовые триггеры и факторы. LLM может реагировать на события в текстовых уведомлениях (например, «задержка на таможне») и корректировать планы, вызывая перепланирование через оптимизатор, уведомление логистов и т.п.
Объяснимость решений и в некоторой степени объяснение результатов расчетов. Конечно, если классический оптимизатор не предоставил достаточно информации, модель не объяснит почему он выбрал именно этот вариант, но строя цепочку рассуждений (Chain of Thought) на основе данных по входам и выходам покажет, что именно повлияло на результаты расчетов.
Понимание неструктурированных данных. LLM из документов, почты, новостей извлекает сущности, события, настроения. В цифровом двойнике это превращается в дополнительные факторы для прогнозов и сценариев (например, риски контрагентов из новостей и т.п.).

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

Тут векторного хранилища (RAG) и инструментов начинает не хватать, потому что большое количество знаний, разрозненных по местам хранения, но связанных по смыслу, предъявляют очень высокие требования к рассудительности модели и к скорости вызовов большого количества инструментов.

Индустрия отвечает на эту потребность “старой” технологией, которой LLM тоже дает новую жизнь - это графы знаний или онтологии. Технология известна давно, но ранее применяемая ограниченно в силу сложности и стоимости. Графы знаний в синергии с LLM существенно усиливают друг друга:

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

Объединенную систему Цифровой двойник + LLM можно назвать Гибридной системой и представить ее архитектуру так:

Верхний уровень - когнитивный коммуникативный слой. Пользователь взаимодействует с системой на естественном языке.
Средний уровень - оркестрация классических расчетных и процессных инструментов. Модель решает, что сделать в моменте: подтянуть статичные инструкции (через RAG), запросить живые данные (вызовы API), запустить симуляцию, обратиться к графу знаний для сложных связных вопросов. Это чисто агентная задача, соответствующая сильным сторонам LLM.
Нижний уровень - классические движки (расчеты, процессы, симуляции) ML-модели, транзакционные системы и графы знаний.

Гибридная архитектура системы позволяет рассчитывать на следующие кумулятивные эффекты от ее внедрения:

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

В этом — настоящий бизнес-эффект гибридной системы: от удобного интерфейса к самостоятельной аналитике, а от неё — к координации целых процессов.

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

8. Другие громкие фразы

1. «Цифровой сотрудник» (Digital Employee)

Обещание: ИИ-коллега, решающий рабочие задания как человек.

Реальность: Набор программных роботов (RPA/ скриптов) с аватаром, использующих LLM для обработки документов и принятия простых решений. Архитектурно это развитие RPA технологии за счет синергии с LLM, и, возможно, ML (в части распознавания образов и речи).

Бизнес-эффект: может быть значительным, способен автоматизировать рутинные задачи, позволяет реализовывать сценарии, где раньше нужен был человек (обработка писем, документов).

2. «Agentic AI»

Обещание: автономный интеллект, который даже цели ставит себе сам.

Реальность: Набор ИИ-агентов.

Бизнес-эффект: может быть значительным, если хорошо продуманы цепочки автономных действий.

3. «RPA 2.0» / «Intelligent Automation»

Обещание: умная роботизация.

Реальность: аналогично п.1. «Цифровой сотрудник».

4. «Copilot» (Microsoft и другие)

Обещание: ИИ‑помощник рядом.

Реальность: LLM + инструменты (доступ к файлам, календарю, почте) + RAG.

Бизнес‑эффект: очевидное ускорение работы.

Аналогично и многие другие слоганы, которые звучат как нечто совершенно новое, на уровне технологий сводятся к комбинации: LLM, RAG, RPA и инструменты. RAG, чтобы модель знала контекст и function calling, чтобы модель могла получить актуальные данные и действовать.

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

9. Предупреждая возражения

1. «А если обучить трансформер на матрицах — он же будет считать?». Полученный результат не LLM, а другая нейросеть — например, для прогнозирования временных рядов или анализа данных. LLM — это нейросеть-трансформер, обученная на тексте.

2. «А как же RLHF? Он же добавляет логику?». RLHF добавляет послушание, а не логику. Модель не начинает лучше считать или рассуждать, она просто становится вежливой и учится следовать инструкциям (см. главу «Что такое LLM»).

3. «Но я видел логические рассуждения LLM!». Это называется не логика, а воспроизведение паттернов рассуждений, которые модель выучила из текстов.

4. «У модели контекстное окно в миллион токенов — она всё запомнит». Миллион токенов это не “всё”, и в эту границу легко упереться на достаточно сложных задачах - даже объем кода при разработке ПО небольшого размера может превысить её.

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

6. «А почему нельзя просто загрузить все инструкции в контекст и обойтись без RAG?». Можно, если у вас относительно немного инструкций и это будет дороже с т.з. расхода токенов. В этом случае если модели написать “Привет”, то она получит в составе запроса большой блок инструкции и одно слово от вас в конце и будет обрабатывать весь запрос.

7. «Но я видел, как LLM написала сложный код, который работает!». Если у модели есть актуальные знания о фреймворках и ваша инструкция очень-очень подробна, то есть шанс получить работающий код. Одна, во-первых нет гарантии, во-вторых часто написать код быстрее, чем очень подробную инструкцию по его безошибочному созданию, и в-третьих, говорят, код, написанный LLM может содержать уязвимости по безопасности (ведь в инструкции мы часто упоминаем про функционал кода, но не просим явно следовать паттернам безопасности). Для production‑кода нужна проверка, тесты и участие человека.

8. «Но я слышал, что ИИ отлично прогнозирует продажи на основе больших данных. Почему вы говорите, что LLM не работает с миллионами строк?». «ИИ» — это зонтичный термин и под ним скрываются десятки разных технологий. Для прогнозирования продаж обычно используют методы ML (градиентный бустинг, нейросети на временных рядах), которые действительно работают с большими объёмами структурированных данных - но это не является LLM.

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

Итоги

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

LLM - это комбинация технологий: Трансформер + RLHF. Это текстовая модель с добавленной исполнительностью и она уникальна способностью работать с неопределенностью, но имеет свои ограничения (размер контекстного окна и актуальность знаний).
RAG и Function calling - это инструменты, расширяющие границы LLM, позволяющие получать нужные в моменте знания, актуальные данные и действовать.
LLM сама по себе не заменит собой все обычные системы, не заменит расчетные алгоритмы, и не надо ожидать, что ИИ способен заменить все подряд.
Агент — это не одна “интеллектуальная” технология, а оркестрация трёх компонентов: модели, набора инструментов и инструкции. Маркетинг называет это «агентом». Инженер называет это “системой с LLM в цикле принятия решений”.
Гибридные системы (LLM + классические движки) — это практический путь, при котором каждая часть дает то, что умеет лучше всего: гибкость и понимание языка от LLM, точность от классических движков, а для глубоких связных вопросов — структурированное знание из графов.
Цифровые двойники, дополненные LLM, могут кардинально упростить работу с данными и моделями, поэтому ожидается, что такие архитектуры станут мейнстримом в ближайшие годы.

Спасибо, что дочитали. Вы теперь знаете об LLM больше, чем 90 % менеджеров продуктов. И почти столько же, сколько автор этой статьи.

Комментарии открыты — готов уточнить и дополнить.

Олег Колосов, Директор по архитектуре Knowledge Space

Послесловие:

За рамками данной статьи осталось много интересных тем:

chain of Thought;
работа ИИ в составе ИТ-систем (взаимодействие в машиночитаемых форматах);
системы с онтологией / графом знаний в ядре;
нейро‑символические гибриды;
механики работы мультиагентных систем;
самообучающиеся системы;
авто-промптинг и версионирование промптов, как итеративный тюнинг инструкции;
рассудительность модели;
оркестратор и фреймворки для его реализации и много другое.

Отмечайте в комментариях наиболее интересные вопросы - это будет учтено в выборе тем следующих статей.

Автор: OlegArchi

Источник

Информация

Комментарии

Рекомендуем