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

Эта статья — результат кабинетного исследования о работе больших языковых моделей (LLM). Здесь простым языком объясняется, как работает та «магия» ИИ, с которой мы сталкиваемся в повседневной жизни или слышим в рекламе.

Под ИИ здесь понимается публичная Большая языковая модель (LLM), например ChatGPT, GigaChat, Mistral и другие.

В статье мы:

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

1. Границы LLM — только текст

LLM — это текстовая генеративная нейросеть. Она умеет только понимать запросы и генерировать текст.

На первый взгляд это противоречит опыту: мы получаем от ИИ картинки, голосовые ответы, расчёты. Но на самом деле модель использует для этого дополнительные инструменты.

Если вы просите нарисовать изображение, LLM не рисует сама. Она формирует текстовый запрос и передаёт его другой нейросети, которая специализируется на генерации изображений.

При голосовом взаимодействии:

• ваша речь преобразуется в текст с помощью сервиса Speech-to-Text;
• LLM обрабатывает текст и генерирует текстовый ответ;
• этот ответ озвучивается через Text-to-Speech.

Голосовой диалог — это цепочка из трёх технологий.

С расчётами — аналогично. Модель не считает, а воспроизводит паттерны. Например, 2×2=4 она «знает» из обучающей выборки. Но при умножении 592 на 946 модель может разбить задачу на шаги, имитируя умножение столбиком.

Сложные расчёты, например 44 567,456554 × 0,000004430987, модель не выполнит в уме. Вместо этого она может сгенерировать код на Python и запустить его через интерпретатор.

В моём эксперименте:

• GigaChat сгенерировала код, запустила его и выдала точный результат: 0.19747782061383878;
• Mistral сделала то же самое, но округлила результат, решив, что такая точность не нужна.

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

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

• поиск в интернете (вызов поисковика);
• открытие веб-страниц (встроенный браузер);
• чтение файлов (извлечение текста);
• построение диаграмм (текстовое описание → визуализация).

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

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

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

Разговор с пользователем не учит модель. Это два разных процесса.

Генерация текста (инференс) происходит так:

1. Модель загружается в память видеокарты.
2. Сервер подаёт запрос.
3. Модель обрабатывает его и выдаёт один токен (слово или его часть).
4. Этот токен добавляется к запросу, и процесс повторяется (авторегрессия).
5. Цикл продолжается до получения специального токена окончания.
6. Результат отправляется пользователю.

Во время генерации таблица весов не меняется. Значит, модель не учится.

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

• Предобучение — обучение с нуля на огромном объёме данных. Дорого и долго.
• Дообучение (fine-tuning) — адаптация уже обученной модели под узкую задачу. Быстрее, но всё равно требует ресурсов.

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

Что делать, если нужно, чтобы модель «знала» вашу информацию?

Единственный способ — передать знания через запрос. Поскольку веса нельзя менять в реальном времени, всё, что влияет на ответ, должно быть в запросе: системный промпт, контекст, данные.

LLM — это генератор текста на основе заранее заложенных или переданных с запросом знаний.

3. Что такое LLM

LLM — результат двух прорывов:

1. архитектура Трансформер, вдохновлённая принципами работы мозга;
2. обучение на огромных объёмах данных — «почти всего интернета».

Современная публичная LLM — это два блока:

1. Трансформер — понимает и генерирует текст;
2. RLHF (обучение с подкреплением на основе обратной связи человека) — делает модель вежливой, безопасной и послушной.

Трансформер «видит» всё сразу

В отличие от старых нейросетей, Трансформер обрабатывает весь запрос целиком. Максимальный объём — это контекстное окно.

Благодаря этому модель замечает противоречия. Например, если в одном месте сказано «для новичков», а в другом используются термины вроде «инференс» и «fine-tuning» — она это увидит.

Как модель генерирует связный текст, если на каждом шаге она предсказывает только один токен?

Ответ: иерархия паттернов. Некоторые шаблоны задают структуру всего ответа, другие — порядок слов. Вместе они создают иллюзию целостного понимания.

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

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

Без RLHF модель — просто генератор текста. Напишите «Привет» — и она продолжит как угодно.

RLHF учит её понимать, что запрос — это инструкция, и отвечать полезно, безопасно и вежливо.

Это как дрессировка собаки: модель не становится умнее, но начинает слушаться.

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

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

LLM «из коробки» может:

• понимать запросы на естественном языке;
• отвечать на основе знаний (до даты обучения);
• использовать внешние данные (RAG);
• трансформировать текст (обобщать, менять стиль и тон);
• следовать инструкциям в промпте;
• понимать, какие инструменты доступны и как их использовать;
• строить цепочки рассуждений (Chain of Thought);
• работать с машиночитаемыми форматами (JSON, XML и др.).

Однако LLM не может своими силами:

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

Особенности поведения:

• Ответ не идемпотентен — один и тот же запрос может дать разные результаты.
• Модель может нарушить формат вывода (например, испортить JSON), требуя валидации.
• Очень чувствительна к формулировке запроса.
• Инструкции имеют иерархию: встроенные (безопасность), системные промпты, пользовательские запросы.
• Может галлюцинировать — уверенно выдавать ложную информацию.

Разделим области применения:

• Алгоритмы — для детерминированных задач: расчёты, сортировка, криптография.
• LLM — для текстовых задач: анализ, генерация, диалоги.
• Другие нейросети — для изображений, звука, временных рядов.
• Гибридные решения — LLM обрабатывает текст, алгоритмы — выполняют точные расчёты.
• Суррогатные модели — нейросети дают быстрое приближение там, где точный расчёт слишком дорог.

LLM в продакшене почти никогда не работает в одиночку — её усиливают дополнительные технологии.

5. Технологии, усиливающие LLM: RAG и Function Calling

Что нужно ИИ?

Два условия для качественного ответа:

1. Достаточно знаний.
2. Достаточно рассудительности.

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

Обучение — вне рамок статьи. Остаётся управление запросом.

Проблема: мы не знаем заранее, какие данные и шаги понадобятся. Это две неопределённости:

• Неопределённость инструкции — неясно, как решать задачу.
• Неопределённость данных — неясно, какие данные нужны и откуда их брать.

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

RAG (Retrieval-Augmented Generation) — способ подтягивать статичные данные: документы, инструкции, регламенты.

Как это работает:

1. Документ разбивается на фрагменты («чанки»).
2. Для каждого чанка вычисляется вектор (семантическое представление).
3. При запросе вектор запроса сравнивается с векторами чанков.
4. Находят самые близкие и возвращают их.

Например, запрос «как открываются двери?» вернёт фрагменты про двери, ручки, капот.

Две схемы RAG:

• Семантический пайплайн — система автоматически дополняет запрос релевантными чанками.
• Агентский пайплайн — LLM сама решает, когда и что запросить, используя Function Calling.

Function Calling — инструменты для LLM

Function calling — способ получать живые данные и выполнять действия: вызов API, калькуляторов, баз данных.

Процесс:

1. Пользователь отправляет запрос.
2. Оркестратор добавляет описание доступных инструментов.
3. Модель решает, нужно ли вызвать инструмент, и отвечает JSON-структурой.
4. Оркестратор выполняет вызов и получает результат.
5. Результат добавляется в историю и отправляется модели как новый запрос.
6. Модель либо вызывает новый инструмент, либо даёт финальный ответ.
7. Оркестратор отправляет ответ пользователю.

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

Оркестратор — ядро ИИ-системы

Оркестратор — алгоритм, управляющий взаимодействием:

• управляет системным промптом и его версиями;
• обеспечивает память диалога (история + суммаризация);
• обрабатывает ошибки формата (например, невалидный JSON);
• обогащает запрос через RAG;
• позволяет модели вызывать инструменты;
• реализует мультимодальность (речь, изображения);
• интегрирует с внешними системами (API, MCP);
• запускает асинхронные задачи;
• оркестрирует суб-агентов.

Память диалога — ключевая функция. LLM «помнит» только то, что в запросе. Поэтому история диалога передаётся в каждом новом запросе.

Память между сессиями — не обучение. Это дополнение запроса сохранёнными фактами (например, «обращайтесь ко мне по имени-отчеству»).

RAG и дополнение запроса — не обучение. Это передача знаний в запросе, а не изменение весов модели.

6. ИИ-агенты

Раньше агенты строились на жёстких правилах:

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

С LLM всё изменилось. Теперь:

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

Например, агент по возвратам может:

• получить письмо клиента;
• проверить заказ через API;
• найти инструкцию через RAG;
• вызвать оператора при необходимости.

Преимущества:

• LLM учитывает нюансы: тон письма, противоречия, неполноту данных.

Риски:

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

Решение — агент-проверяющий. Первый агент генерирует ответ, второй проверяет его. При ошибке — возврат на доработку. Это снижает вероятность сбоев.

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

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

Цифровой двойник — виртуальная модель организации, включающая:

• интеграцию данных (ERP, IoT и др.);
• симуляции (дискретно-событийные, агентные);
• аналитику (ML, оптимизация);
• визуализацию (3D, дашборды);
• обратную связь с реальным миром (API, IoT).

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

Слабые: сложный интерфейс, требует экспертов.

LLM добавляет новое качество:

• интерфейс на естественном языке (NL2API, NL2SQL);
• агентность — выполнение задач по инструкции;
• оркестрация симуляций и оптимизаторов;
• реакция на текстовые события (например, «задержка на таможне»);
• объяснимость решений через Chain of Thought;
• обработка неструктурированных данных (почта, новости).

Когда RAG и инструменты не хватает — на помощь приходят графы знаний (онтологии). Они:

• позволяют модели быстро работать с большими объёмами связанных данных;
• сами могут создаваться и обновляться с помощью LLM.

Гибридная архитектура:

1. Верхний уровень — LLM и естественный язык.
2. Средний уровень — оркестрация: RAG, инструменты, симуляции.
3. Нижний уровень — классические движки: расчёты, ML, транзакционные системы, графы знаний.

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

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

• Цифровой сотрудник — RPA + LLM для обработки документов. Эффект: автоматизация рутины.
• Agentic AI — набор ИИ-агентов. Эффект: автономные цепочки действий.
• RPA 2.0 / Intelligent Automation — то же, что «цифровой сотрудник».
• Copilot — LLM + инструменты + RAG. Эффект: ускорение работы.

Большинство громких слоганов — это комбинация: LLM, RAG, инструменты и RPA.

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

• «А если обучить трансформер на матрицах — он будет считать?» — Нет. Это будет другая нейросеть, не LLM.
• «RLHF добавляет логику?» — Нет. Только послушание и вежливость.
• «А как же логические рассуждения?» — Это воспроизведение паттернов, а не логика.
• «Контекстное окно в миллион токенов — она всё запомнит?» — Нет. Даже код среднего проекта может не поместиться.
• «LLM как база данных?» — Рискованно. Модель уверенно «помнит» частые факты, но придумывает редкие.
• «Зачем RAG, если можно всё загрузить в контекст?» — Можно, но дорого и неэффективно.
• «LLM пишет работающий код!» — Да, но нет гарантий. Часто содержит уязвимости. Требует проверки.
• «ИИ прогнозирует продажи — значит, LLM работает с большими данными?» — Нет. Прогнозы делают другие модели (градиентный бустинг, временные ряды), не LLM.

Новое качество возникает не от одной технологии, а от их комбинации:

• LLM = Трансформер + RLHF. Уникальна в работе с неопределённостью.
• RAG и Function calling расширяют её возможности.
• LLM не заменит алгоритмы и расчётные системы.
• Агент — это оркестрация модели, инструментов и инструкции.
• Гибридные системы — путь вперёд: LLM для гибкости, классические движки — для точности.
• Цифровые двойники с LLM — мейнстрим ближайших лет.

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

Данная статья представляет собой результат кабинетного исследования об основных особенностях работы ИИ (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?”модель поступила иначе, она написала простой код на Питон и запустила его в интерпретаторе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Что такое LLM

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

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

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

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

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

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

1. трансформер, который обеспечивает понимание текста и генерацию;
2. 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 качественный и точный ответ должно сложиться два фактора:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Пользователь отправляет запрос
2. Оркестратор дополняет запрос доступными инструментами. В состав пользовательского запроса добавляются инструкции для модели наподобие “…Тебе доступны инструменты: База знаний, для вызова ответь в таком виде [JSON-спецификация]; Вызов функции калькулятора, для вызова ответь в таком виде [JSON-спецификация]…”
3. Модель видит запрос и доступные инструменты и строит цепь решения, при необходимости, предполагая вызов инструментов. Если модель решит вызвать инструмент, то на данный запрос она ответит не человеко-читаемым текстом, а машино-читаемой JSON-структурой
4. Оркестратор (алгоритм) проверяет что ответ это JSON с ожидаемой спецификацией, валидирует и выполняет вызов инструмента
5. Оркестратор, получив ответ от инструмента добавляет это в историю диалога и отправляет как новый запрос в LLM. Т.е. теперь в LLM будет в составе запроса отправлено: первоначальный запрос пользователя + JSON-структура для вызова инструмента + ответ от Инструмента + Новый набор доступных инструментов.
6. LLM, видя всю историю диалога и новый набор доступных инструментов заново строит цепь решения задачи и либо вызывает новый инструмент либо дает ответ на первоначальный запрос
7. Оркестратор проверяет, что ответ это не 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 можно назватьГибридной системойи представить ее архитектуру так:

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

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

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

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

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

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;
• работа ИИ в составе ИТ-систем (взаимодействие в машиночитаемых форматах);
• системы с онтологией / графом знаний в ядре;
• нейро‑символические гибриды;
• механики работы мультиагентных систем;
• самообучающиеся системы;
• авто-промптинг и версионирование промптов, как итеративный тюнинг инструкции;
• рассудительность модели;
• оркестратор и фреймворки для его реализации и много другое.

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