LLM (large language model, большая языковая модель) — это программа, обученная на огромных объемах текста предсказывать продолжение фразы. Модель получает запрос, разбивает его на короткие фрагменты и подбирает наиболее вероятное следующее слово, затем следующее — так собирается связный ответ. Готовых ответов внутри нет, есть статистические связи между словами, выведенные из текстов во время обучения. Поэтому одна и та же модель пишет письмо клиенту, пересказывает длинную переписку, определяет тему обращения и отвечает на вопрос по инструкции.
Ниже разобраны расшифровка термина, отличие от чат-бота, работа с токенами и контекстом, обучение, корпоративные сценарии, ограничения и порядок запуска пилота.
Что такое LLM простыми словами
Ближайшая аналогия — подсказка при вводе текста в телефоне: клавиатура предлагает следующее слово по уже написанному. Большая языковая модель делает то же самое, но опирается на несопоставимо больший объем текста и удерживает связь между началом и концом документа.
Отсюда главное свойство: модель хорошо работает с текстом и плохо работает как источник фактов. Она уверенно перескажет переданный договор и так же уверенно придумает пункт, которого ей не показывали.
Что языковая модель умеет без дополнительных настроек:
- Сокращать текст. Переписка на сорок сообщений сворачивается в пять строк с договоренностями.
- Переписывать текст. Черновик становится вежливым ответом клиенту, техническое описание — понятным пользователю.
- Классифицировать текст. Обращение получает тему, тип и признак срочности по описанию проблемы.
- Извлекать данные. Из письма достаются компания, контакт, сумма и срок.
- Отвечать по документу. Модель находит нужный фрагмент инструкции и объясняет его своими словами.
Сама по себе модель не хранит клиентскую базу, не знает внутренних регламентов и не проверяет собственный ответ. Это добавляется отдельно: подключением источников, настройкой прав доступа и проверкой результата.
Как расшифровывается LLM
LLM расшифровывается как large language model, русский вариант термина — большая языковая модель. В деловой переписке встречаются оба написания, в документации чаще используют аббревиатуру.
Слово «большая» относится к двум величинам: объему текстов, на которых модель училась, и числу параметров — внутренних коэффициентов, через которые она хранит связи между словами. Чем больше параметров, тем сложнее уловленные закономерности и тем дороже каждый запрос.
Отсюда ориентир при выборе: крупная модель нужна для рассуждений и сложных документов, для классификации коротких обращений хватает модели поменьше.
Чем LLM отличается от чат-бота и генеративного AI
Три термина часто используют как синонимы, и разговор о проекте уходит в сторону. Генеративный AI — широкий класс решений, создающих новый контент. LLM — один из его видов, работающий с текстом. Чат-бот — интерфейс, через который человек обращается к модели или к готовому сценарию.
Отдельно стоит RAG (retrieval-augmented generation) — способ подключить модель к корпоративным документам: система сначала находит нужные фрагменты в базе знаний, затем передает их модели вместе с вопросом.
| Термин | Что это | Где используется | Пример |
|---|---|---|---|
| LLM | Модель, генерирующая текст по запросу | Ядро решения, вызов из приложения или процесса | Черновик ответа на жалобу по описанию обращения |
| Чат-бот | Интерфейс диалога с пользователем | Сайт, мессенджер, внутренний портал | Окно чата с вопросом об условиях доставки |
| Генеративный AI | Класс решений, создающих контент: текст, изображение, код | Маркетинг, разработка, дизайн, аналитика | Баннер для кампании и текст к нему |
| RAG | Схема работы модели с внешними источниками | База знаний, регламенты, архив документов | Ответ по регламенту отпусков со ссылкой на пункт |
Из таблицы видно, где возникает путаница: фраза «нам нужен чат-бот» описывает канал общения и ничего не говорит об источнике ответов.
Сценарный бот отвечает по дереву вопросов и упирается в первую нестандартную формулировку. Бот на языковой модели понимает вопрос в свободной форме, но без подключенных источников опирается на общие знания из обучения. Поэтому требование формулируют в двух частях: канал общения и источник ответов.
Как работает большая языковая модель
Механика описывается четырьмя понятиями: токены, контекст, промпт и вероятностный ответ. Ниже они разобраны без формул.
Токены
Модель работает с токенами — короткими фрагментами текста. Токеном бывает слово целиком, часть слова или знак препинания; для русского языка слово занимает обычно от одного до трех токенов.
Через токены считают стоимость запроса: оплата идет за их число на входе и на выходе. Через них же задан предел длины запроса и ответа.
Контекст
Контекст — весь текст, который модель видит в момент ответа: инструкция, вопрос, переданные документы и предыдущие реплики. Объем ограничен размером контекстного окна.
Когда переписка не помещается в окно, начало разговора вытесняется, и ранние договоренности перестают учитываться. Это решают сжатием: длинную историю сначала пересказывают коротко и передают модели уже пересказ.
Промпт
Промпт — текстовый запрос к модели. Рабочий промпт содержит роль и задачу, входные данные, ограничения и формат ответа. Формулировка «напиши ответ клиенту» дает разброс от двух строк до письма на страницу, поэтому формат задают явно.
Пример: «Ты специалист поддержки. По описанию обращения составь ответ клиенту: три абзаца, деловой тон, в конце — срок из поля «Плановая дата». Если срока нет, напиши, что уточнишь его». Последняя фраза закрывает типовую ошибку: иначе модель подставит правдоподобную дату сама.
Вероятностный ответ
Ответ собирается пошагово: на каждом шаге модель оценивает вероятность следующего токена и выбирает вариант. Разброс регулируется параметром температуры: около нуля ответы почти повторяются, ближе к единице формулировки становятся разнообразнее.
Для классификации и извлечения полей температуру ставят низкой, для черновиков писем разброс допустим. В обоих случаях одинаковые запросы дают разный текст, поэтому результат проверяют перед использованием дальше по процессу.
Как обучают LLM
Обучение проходит в несколько этапов, у каждого своя стоимость и зона ответственности. Компании участвуют обычно в последних двух, и разница между этапами влияет на бюджет проекта.
Предобучение
На первом этапе модель читает большой корпус текстов и учится предсказывать пропущенные фрагменты. Так формируется базовое владение языком: грамматика, устойчивые обороты, общие представления о мире.
Этап требует мощностей промышленного масштаба и выполняется разработчиками моделей. Компания-заказчик выбирает уже готовую базовую модель.
Дообучение
Дообучение (fine-tuning) настраивает готовую модель под узкую задачу на своих примерах: для сервиса это пары «обращение — корректный ответ», для продаж — письма в принятом стиле.
Свежести данных дообучение не добавляет: регламент, вышедший после обучения, в модель не попадет. Его выбирают ради устойчивого стиля или специфической терминологии и заранее оценивают стоимость подготовки примеров.
Обучение с обратной связью
Люди сравнивают несколько ответов модели и отмечают лучший. По этим оценкам модель настраивают так, чтобы она чаще выбирала полезные и безопасные формулировки. Метод известен как RLHF — обучение с подкреплением на основе обратной связи от человека.
В корпоративных проектах принцип работает проще: операторы оценивают ответы в интерфейсе, команда разбирает оценки и правит промпты или подборку источников.
RAG и корпоративные данные
RAG подключает модель к документам компании без переобучения. Схема из четырех шагов: вопрос переводится в поисковый запрос, система находит подходящие фрагменты в базе знаний, передает их модели вместе с вопросом, модель формирует ответ и указывает использованные документы.
Подход закрывает три задачи. Правка документа сразу отражается в ответах, потому что поиск идет по актуальной базе. Ответ содержит ссылку на источник и поддается проверке. Права доступа применяются при поиске, поэтому сотрудник видит ответы только по разрешенным документам.
Где применяются LLM
Сценарии делятся на две группы. В первой модель помогает сотруднику: готовит черновик, сокращает текст, подсказывает формулировку, решение остается за человеком. Во второй она встроена в процесс и работает без оператора: классифицирует, маршрутизирует, заполняет поля. Первую группу запускают быстрее: ошибка видна до отправки.
Рабочие сценарии, которые чаще всего закрывают в компаниях:
- Поиск по базе знаний. Сотрудник спрашивает своими словами и получает ответ со ссылкой на регламент.
- Ответы клиентам. Модель готовит черновик по истории обращения, оператор правит и отправляет.
- Подготовка писем. Предложение или письмо после встречи собирается по карточке клиента и заметкам менеджера.
- Обработка заявок. Из письма извлекаются тема, тип обращения, продукт и контакт, поля карточки заполняются автоматически.
- Резюме встреч. Из расшифровки звонка собирается список договоренностей, задач и ответственных.
- Помощь по сделке. Перед звонком история коммуникаций сворачивается в справку: что обсуждали и где остановились.
- Анализ документов. Из договора или анкеты извлекаются реквизиты, сроки и условия для проверки специалистом.
Подразделения приходят к похожим сценариям с разными требованиями к данным. Таблица показывает, что готовят до старта.
| Отдел | Задача | Какие данные нужны |
|---|---|---|
| Продажи | Справка по клиенту перед звонком, письмо после встречи | История коммуникаций, карточка сделки, прайс, шаблоны |
| Маркетинг | Варианты текстов кампаний, разбор обратной связи | Описание продукта, правила бренда, база опросов |
| Клиентский сервис | Классификация обращений, черновик ответа, поиск похожих случаев | Архив обращений с решениями, база знаний, шаблоны ответов |
| ИТ и внутренняя поддержка | Ответы на типовые заявки, маршрутизация по группам | Каталог услуг, регламенты, история заявок |
| Юристы и документооборот | Извлечение условий договора, сверка с типовой формой | Типовые формы, архив договоров, перечень стоп-условий |
Закономерность видна по третьей колонке: ценность создают данные компании, и подготовка данных занимает больше времени, чем подключение модели. Поэтому первым берут направление с собранным архивом — обращения сервиса или базу знаний.
LLM в CRM и бизнес-процессах
Внутри CRM-платформы языковая модель встраивается туда, где сотрудник работает с текстом: подсказка по сделке собирается из истории коммуникаций, переписка сворачивается в выжимку для руководителя, обращение получает тему и приоритет по описанию проблемы, черновик ответа готовится по карточке, поиск по регламентам возвращает ответ со ссылкой на пункт документа.
Отдельный сценарий — внутренние заявки. В связке с управлением ИТ-услугами модель разбирает обращение сотрудника, определяет группу ответственных и предлагает решение из истории похожих заявок. Правка оператора становится материалом для следующей настройки.
Рядом с языковыми моделями работают классические ML-модели: они прогнозируют значения полей и вероятности событий по историческим данным. В BPMSoft они обучаются на данных, уже накопленных в системе: обращениях, продажах, активностях клиентов, документах — отдельный сбор исторических данных не нужен. Настройка идет без программирования: типы моделей и их параметры задаются в разделе «Модели машинного обучения», а запрос к языковой модели добавляется в схему бизнес-процесса элементом «Работа с LLM» — промпт собирается из полей объекта, ответ сохраняется в параметр процесса и используется на следующих шагах средствами low-code или разработки.
Ограничения LLM
Ограничения языковых моделей известны заранее и поддаются контролю. Проблемы начинаются там, где проект строят на допущении, что модель отвечает правильно по умолчанию.
- Галлюцинации. При нехватке данных модель достраивает правдоподобный текст: придумывает номер пункта регламента, дату или название документа. Ошибка стилистически не отличается от корректного ответа и замечается позже других.
- Отсутствие свежих данных. Знания ограничены датой окончания обучения: без подключенных источников модель не видит ни вчерашнего приказа, ни статуса заказа.
- Риск раскрытия данных. Данные клиентов и условия сделок уходят во внешний сервис вместе с текстом запроса, если это не ограничено правилами и настройками.
- Зависимость от промпта. Переформулировка запроса меняет ответ. Промпты, зашитые в процесс, со временем расходятся с практикой и требуют ревизии наравне с регламентами.
- Сложность проверки. Выбор формулировки нельзя проследить так же однозначно, как работу правила в системе. Контроль держится на ссылках на источники и выборочных проверках.
| Риск | Как проявляется | Что проверить |
|---|---|---|
| Галлюцинация | В ответе появляется несуществующий пункт, срок или условие | Есть ли ссылка на источник и открывается ли фрагмент |
| Устаревшие данные | Модель отвечает по отмененной редакции регламента | Дата обновления базы и отметка об архивных версиях |
| Утечка данных | Данные клиентов и условия сделок уходят во внешний сервис | Состав данных в промпте, площадка размещения, журнал запросов |
| Нарушение прав доступа | Сотрудник получает ответ по закрытому для него документу | Применяются ли права доступа при поиске фрагментов |
| Разброс ответов | Одинаковые запросы дают разные формулировки и решения | Температура и жесткость формата ответа в промпте |
| Слепое доверие | Оператор отправляет черновик без чтения | Требует ли процесс подтверждения перед отправкой |
Строки таблицы складываются в правило: чем выше цена ошибки, тем ближе к решению стоит человек. Классификация идет автоматически с выборочной проверкой, спорный ответ подтверждает оператор, юридически значимый документ проходит обычное согласование.
Как оценивать качество LLM-решения
Оценка «отвечает хорошо» не переживает первой претензии от бизнеса. Качество измеряют на фиксированной выборке: берут 100–200 реальных запросов, прогоняют через решение и размечают результат.
- Точность ответа. Доля ответов без фактических ошибок относительно исходных документов.
- Полнота. Доля ответов, закрывающих вопрос целиком, без потери условий и исключений.
- Ссылка на источник. Доля ответов со ссылкой на документ, который удалось открыть и сверить.
- Соблюдение прав доступа. Число случаев с данными, закрытыми для роли пользователя; целевое значение — ноль.
- Скорость. Время от запроса до ответа в интерфейсе с учетом поиска по базе.
- Доля эскалаций. Часть обращений, переданных человеку, и причины передачи.
- Доля правок. Как часто оператор меняет черновик перед отправкой и что именно правит.
Замер повторяют на той же выборке после каждой правки промптов, иначе улучшение одного сценария незаметно ломает соседний. Доля правок и причины эскалаций собираются в аналитике CRM рядом с остальными показателями подразделения.
Порог приемки задают до пилота. Формулировка «точность не ниже согласованного уровня, ноль нарушений прав доступа, доля эскалаций в известных границах» превращает спор о впечатлениях в сверку с цифрами.
Как подготовить компанию к внедрению LLM
Маршрут первого проекта состоит из шести шагов. Порядок важен: пропущенная подготовка данных всплывает на пилоте и обесценивает замеры.
- Выбрать сценарий. Один процесс с понятным объемом и измеримым результатом: классификация обращений, поиск по регламентам или черновики ответов.
- Собрать базу знаний. Актуальные документы в одном месте, устаревшие редакции помечены, у каждой есть владелец.
- Настроить доступы. Определить, какие роли к каким документам обращаются, и применить правила при поиске фрагментов.
- Подготовить инструкции. Промпты с ролью, форматом ответа и правилом поведения при нехватке данных; отдельно — темы для передачи человеку.
- Запустить пилот. Ограниченная группа пользователей, фиксированный срок, сбор оценок в интерфейсе.
- Измерить качество. Прогон по выборке, сравнение с порогом приемки, решение о расширении или доработке.
Чек-лист готовности к пилоту
На каждый вопрос отвечают «да» или «нет». Любое «нет» — работа до старта.
- Выбран один сценарий и назван его владелец со стороны бизнеса?
- Известно, какие документы и записи модель использует для ответа?
- Устаревшие редакции убраны из базы или помечены?
- Описано, какие данные запрещено передавать в промпт?
- Площадка размещения модели согласована со службой безопасности?
- Права доступа применяются на этапе поиска по базе?
- Задан формат ответа и поведение модели при нехватке данных?
- Определены темы, которые передаются человеку без попытки ответа?
- Собрана выборка запросов для замера и согласован порог приемки?
- Есть способ собирать оценки ответов и ответственный за ревизию промптов?
Команды, которые начинают с подключения модели и откладывают документы и доступы, возвращаются к этим пунктам после первого разбора неудачных ответов. Смежные термины разобраны в глоссарии BPMSoft.