Способы повышения точности и качества ответов
Качество ответов - одна из ключевых задач при настройке ботов на основе LLM-моделей. Существует множество способов его повышения. В данной главе мы рассмотрим основные:
улучшение качества промптов
уменьшение контекста
Первому пункту мы посвятили всю прошлую главу, поэтому в данной главе остановимся на втором.
Уменьшение контекста
У каждой модели существует такой параметр как внимание - это то, как модель четко следует своей системной инструкции. Существует закономерность - чем меньше инструкция - тем проще модели ее соблюдать. Когда мы имеем дело с большими инструкциями, какие-то из ее важных аспектов могут быть упущены ботом. В этом случае мы можем использовать фразы "Обращай внимание, Всегда" и т.п., но это может не давать стабильного результата, когда мы хотим точность 10 из 10.
Логичным выводом является - уменьшение инструкции или "контекста".
Под уменьшением контекста понимается оптимизация и сокращение объема основной инструкции или передаваемой информации в модель.
Уменьшать инструкцию за счет смысловой нагрузки не всегда правильно, поэтому существуют механизмы, которые позволяют оптимально распределить смысловой контекст и уменьшить инструкцию без потери качества:
Использование базы знаний
Уменьшение истории диалога
Использование таблиц
Мультиагентность
Использование базы знаний
Использование базы знаний позволяет выносить целые блоки информации из общей инструкции в отдельный раздел, например:
Предположим в инструкции присутствует блок информации о реквизитах компании (подобных блоков может быть множество):
Наши контакты:
ООО "Рога и копыта"
ИНН 7811616380 / КПП 781101002
АО "ТБанк"
БИК 044525974
р/с 40702810310000021420
Адрес: Москва, Измайловский 30, оф. 15
Данный блок необходим только по запросу клиента, когда клиент прямо спрашивает о реквизитах. В этом случае, в базе знаний можно создать файл с названием "Реквизиты компании" и вставить в него данный текст, а из инструкции его убрать:

По аналогии все типовые ответы на типовые вопросы выносятся в базу знаний.
База знанийУменьшение истории диалога
Уменьшение истории диалога означает, что мы можем передавать не всю историю диалога с клиентом, а только сообщения за нужный отрезок времени, или не передавать ее вообще.
В бьюти-индустрии клиенты часто возвращаются регулярно, с повторяющимися запросами. Если собрать всю историю их общения за этот период и передавать её боту, она станет излишне длинной и неэффективной для решения конкретной текущей задачи.
Длинная инструкция и история часто размывает внимание бота
Бот не знает, когда было написано конкретное сообщение, и это может сбить его с толку.
Он просто не поймет что нужно клиенту, учитывая и предыдущую переписку, тратя на нее свое "внимание".
Так же существует ситуации, когда создается бот не для ведения диалога, а просто ответов на конкретные вопросы без учета истории.
Для всех этих ситуаций существует настройка позволяющая обрезать контекст диалога. Она находится в дополнительных параметрах и называется "История сообщений (контекст)":

Выбирая нужную опцию вы можете подстроить передачу контекста под ваш кейс.
Использование таблиц
Расширенная инструкция по настройке таблиц находится в отдельном разделе. Но здесь мы коснемся их в части задачи по улучшению качества ответов.
Таблицы (CSV-XLS / Google)Предположим, что у вас имеется какой-то прайс на 100 позиций. 100 позиций - это не слишком много и не слишком мало в контексте работы модели. Чтобы предоставить информацию о данном прайсе мы могли бы пойти несколькими путями:
Загрузить прайс в инструкцию
Загрузить прайс в базу знаний
Разбить прайс на несколько файлов в базе знаний
Использовать таблицы
Первый вариант не рассматриваем - это не разумно, инструкция будет большая - модель будет перегружена контекстом, а стоимость одного сообщения вырастет кратно.
❌ Минусы:
перегруз инструкции
большой объем токенов = стоимости
✅ Плюсы:
простота настройки
Второй вариант лучше, НО все равно - это большой объем информации, который модель должна будет за раз прочитать, а поскольку, то что она прочитала по умолчанию сохраняется в ее историю, после срабатывания данного файла будет увеличивать стоимость всех последующих сообщений.
❌ Минусы:
перегруз истории
большой объем токенов = стоимости
✅ Плюсы:
простота настройки
Третий вариант с разбивкой прайса на разные файлы базы знаний в целом лучше, чем предыдущие, он позволит снизить стоимость, НО она все равно вырастит за счет количества файлов внутри базы знаний, но при этом за счет разбивки тут можно избежать перегруза истории.
❌ Минусы:
средний объем токенов = стоимости
дополнительные заморочки с настройкой
✅ Плюсы:
средний объем токенов = стоимости
Четвертый вариант - то загрузка прайса в таблицу. Данный вариант позволяет работать не только с объемом в 100 позиций, а с любым объемом строк не увеличивая стоимость, поскольку работа с таблицей происходит выборочно с наложением предварительных отборов, который модель делает при помощи специального механизма SQL-запросов.
❌ Минусы:
средняя сложность настройки
✅ Плюсы:
более низкий объем токенов = стоимости
неограниченный объем позиций / строк
сокращение контекста инструкции и истории
высокая прогнозируемость и правильность ответов
Высокая прогнозируемость и правильность ответов достигается за счет того, что мы не читаем всю таблицу, а получаем только нужные нам ее ячейки, таким образом ни контекст ни история не перегружается.
Last updated
Was this helpful?