Стратегии программной и качественной оценки чат-ботов, созданных с помощью GPT и LlamaIndex.

Почему меня волнует оценка чат-ботов

В рамках Buildspace Nights and Weekends в настоящее время я работаю над изучением способов надежного повышения производительности чат-ботов с поддержкой данных. Я пытаюсь улучшить производительность одного конкретного приложения, моего Legal Tech Bot, чтобы найти стратегии, которые могут быть применимы в более широком смысле.

Сначала несколько уточнений. Я сосредоточен на чат-ботах, созданных поверх LLM/GPT. Когда я говорю о подключении к данным, я имею в виду чат-ботов, у которых есть средства передачи контекста в GPT из набора данных по вашему выбору. В моем случае это большой набор постов и статей в блогах. Популярным инструментом для этой цели является LlamaIndex.

Ранее я очертил четыре типа вопросов, с которыми, как мне кажется, борются чат-боты с поддержкой данных. Вкратце, это:

  1. Вопросы, на которые необходимо предоставить самый последний ответ из данных
  2. Субъективные вопросы
  3. Общие вопросы/вопросы высокого уровня
  4. Вопросы, требующие агрегирования фактов из данных

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

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

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

Все, что я буду обсуждать ниже, будет из контекста Legal Tech Bot, который создан с LlamaIndex и GPT. Этот пост будет наиболее полезен для всех, кто использует этот стек, но также будет охватывать общие соображения, которые должны быть полезны всем, кто работает с продуктами на основе чата.

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

Оценка чат-бота на высоком уровне

Что такое хороший ответ?

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

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

Как проводится качественная оценка?

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

Стратегия 1. Сформируйте интуитивное мнение

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

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

Стратегия 2: положитесь

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

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

Как проводится программная оценка?

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

В случае традиционного машинного обучения мы просим программу оценить довольно простой вопрос: соответствует ли предсказанная метка истинной метке. С генеративным ИИ не совсем ясно, какой именно вопрос мы хотим, чтобы программа оценивала для нас. Для чат-бота, я думаю, это примерно так: учитывая контекст, является ли ответ чат-бота справедливым ответом на вопрос пользователя? Да или нет.

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

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

  • Как выносится суждение о том, имеет ли ответ смысл с учетом вопроса и контекста?
  • Хотим ли мы учитывать контекст? Можем ли мы захотеть, чтобы наш бот также мог использовать знания вне контекста?
  • Хотим ли мы рассмотреть вопрос во время оценки? Если мы хотим измерить, насколько бот выдумывает что-то, мы можем просто заботиться об ответе в зависимости от контекста.
  • Как мы будем генерировать вопросы для запуска этого теста? Нужно ли нам беспокоиться о создании предвзятого множества?

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

Подробности о том, как я оцениваю результаты чат-бота

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

Процесс программной оценки

Я не буду предоставлять фрагменты кода или детали реализации. Если вам интересно, я предлагаю проверить отличную документацию LlamaIndex, GitHub и Discord для поддержки. Вместо этого я собираюсь объяснить шаблон использования высокого уровня, которому я следую, учитывая инструменты оценки, которые предоставляет LlamaIndex.

LlamaIndex предоставляет как минимум четыре разных способа оценки ответов, каждый из которых можно смешивать и сопоставлять. Я использую то, что LlamaIndex называет бинарной оценкой запроса, ответа и исходного контекста. В документах указано, что «этот режим оценки возвращает «ДА»/«НЕТ», если синтезированный ответ соответствует запросу + любому исходному контексту».

Как я уже говорил ранее, меня действительно интересует следующее: для вопросов, на которые мой контекст должен быть в состоянии ответить, имеет ли смысл ответ, предоставленный моим ботом? Этот способ оценки приближает нас к этому. Однако нам по-прежнему необходимо убедиться, что вопросы, на которые мы проводим этот тест, — это вопросы, на которые теоретически могут быть даны ответы в наших исходных документах. Один из способов сделать это — запустить eval, как описано выше, а затем для каждого неудачного вопроса проверить каждый фрагмент текста во всех исходных документах, чтобы увидеть, мог ли он ответить на вопрос. Это было бы очень медленно. LlamaIndex предлагает лучшее решение: класс DatasetGenerator. Этот класс позволяет вам генерировать вопросы из вашего контекста. Поскольку они генерируются непосредственно из ваших данных, мы можем разумно предположить, что они должны отвечать контексту.

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

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

  1. Создайте более 100 вопросов непосредственно из моего набора данных, используя генератор наборов данных LlamaIndex.
  2. Настройте цикл для запуска теста ДА/НЕТ, определенного выше для каждого из этих вопросов. Отслеживайте процент успешных ответов, определяемый [количество ДА] / [всего вопросов]. Это балл, который я буду использовать для оценки производительности.
  3. Создайте более 100 вопросов, просто используя GPT-4.
  4. Повторите шаг 2 для этих вопросов.

Внутри каждого из этих циклов я также создаю фрейм данных с четырьмя столбцами: вопрос, ответ, контекст (исходный контекст, найденный моим индексом), оценка (да/нет). Для каждого вопроса есть одна строка. Таким образом, я могу просматривать вещи визуально. Я сохраняю этот фрейм данных в лист Google, чтобы иметь под рукой для дальнейшего использования. Опять же, моей основной метрикой будет процент вопросов, получивших оценку ДА. То есть процент ответов, которые соответствуют контексту запроса + источника. В моем первом тесте вопросы, сгенерированные LlamaIndex, набрали 78%, а вопросы, сгенерированные GPT, набрали 79%. Я буду запускать это после каждого серьезного изменения в моем боте.

В этом процессе много несовершенств. Например, я действительно хотел бы, чтобы мой бот попытался ответить на общие вопросы по юридическим технологиям, которые не находятся непосредственно в моих исходных данных. Я обнаружил, что GPT-4 хорошо справляется с такими вопросами, как «как ИИ используется в юридических технологиях?» который может быть слишком общим для индекса, чтобы найти хороший фрагмент контекста. Даже с этими несовершенствами эти инструменты оказываются чрезвычайно полезными. Теперь у меня есть средство для запуска программной оценки качества моего бота. Цель состоит в том, чтобы увеличить этот показатель. Что не менее важно, эта оценка также служит для сравнения моего интуитивного мнения о производительности моего бота.

В этом процессе есть одна большая проблема: каждый оцениваемый вопрос требует вызова API к выбранному вами LLM. Это означает, что оценка выполняется медленно и дорого. Это не говоря уже о первоначальном процессе генерации вопросов, требующем большого количества токенов. Отсюда небольшое количество (100) вопросов, которые я предлагаю использовать выше. Если вы следуете этому процессу для продукта производственного уровня, я бы предложил провести оценку по гораздо большему количеству вопросов. 100 должно быть достаточно, чтобы обеспечить значимую оценку качества для небольших проектов. Но представьте, что кто-то генерирует 1000 вопросов и разбивает их на 10 наборов по 100. Оценочный балл для каждого из этих наборов будет различаться, и трудно сказать, насколько. Я надеюсь, что умная инженерия сможет решить эту проблему в будущем. Вот почему я считаю разумным использовать такие инструменты, как LlamaIndex, вместо того, чтобы самостоятельно создавать инструменты для подключения к данным.

Процесс качественной оценки

Ранее я обозначил четыре конкретных типа вопросов, с которыми мой Legal Tech Bot не справляется. Я также объяснил, почему я думаю, что это общие проблемы, которые следует ожидать от ботов с поддержкой данных, созданных с помощью таких инструментов, как LlamaIndex. Я планирую заняться одним из них за один раз. При этом я буду следить за программной оценкой. Но я также буду следовать этому процессу, чтобы качественно оценить производительность:

  1. Прежде чем пытаться решить проблему, соберите несколько примеров проблемы. Например, неспособность учитывать недавность. Найдите эти примеры методом проб и ошибок. У меня также есть несколько тестовых пользователей, которых я попрошу помочь здесь. Пользователи любят выискивать дыры в вашем продукте.
  2. Пройдите через процесс исследования, экспериментирования и внедрения решения.
  3. Протестируйте вопросы из части (1) еще раз. Попросите тестовых пользователей сделать то же самое.
  4. Бонус: найдите результаты моей программной оценки, чтобы увидеть, есть ли какие-либо примеры этой проблемы, которые ранее получили НЕТ, а теперь получают ДА.

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

Заключение

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