Бенчмаркинг извлечения данных: тестирование LLM на наборе данных LangChain

Две недели назад мы запустили пакет langchain-benchmarks и набор данных для вопросов и ответов в LangChain docs. Теперь публикуем новый набор данных для извлечения информации — он оценивает, насколько хорошо LLM могут извлекать структурированные данные из журналов чата. Набор данных создаёт практическую среду для тестирования распространённых проблем при разработке приложений LLM: например, классификации неструктурированного текста, генерации машиночитаемой информации и решения задач с отвлекающими данными. Мы подробно расскажем, как создавали набор данных, и поделимся первыми результатами тестирования. Цель — помочь разработчикам создавать диалоговые приложения. Мы хотели разработать схему набора данных, ориентируясь на реальную задачу: получение структурированной информации о взаимодействии чат-ботов. Летом стажер Молли помогла обновить Chat LangChain (repo) — приложение для генерации данных с расширенным поиском (RAG) на основе документов LangChain на Python. Это «LLM с поисковой системой»: можно задавать вопросы вроде «Как мне добавить память к агенту?» — и система найдёт ответ в документации. Реальная проверка проекта начинается после развёртывания: важно отслеживать, как его используют, и дорабатывать. Пользователи редко оставляют явные отзывы, но их беседы дают много информации. Извлечение структурированного контента помогает в мониторинге и анализе — например, для создания аналитических панелей или тонкой настройки (fine-tuning) конвейеров сбора данных. Набор данных для извлечения из чата проверяет, насколько хорошо современные LLM извлекают и классифицируют нужную информацию. Этапы создания набора данных: выбор модели данных для представления структурированных выходных данных; составление пар вопросов и ответов; генерация возможных ответов с помощью LLM; ручная проверка результатов в очереди аннотаций (при необходимости — обновление таксономии). У LangChain уже есть инструменты для создания синтетических наборов данных, но финальная версия всегда требует ручной проверки качества. Поэтому мы добавили в LangSmith очередь аннотаций к данным и продолжаем совершенствовать инструментарий. Получив исходный набор данных, можно использовать помеченные данные как примеры для модели начального поколения — это сократит объём работы при обновлении базовой информации. Мы хотели, чтобы задача была простой, но сложной для многих современных моделей. Определили схему с помощью модели pydantic. Пример извлечённого значения: BOS «GenerateTicket»: BOS «вопрос»: BOS «токсичность»: 0, «настроение»: «Нейтральное», «isofftopic»: ложь, «questioncategory»: «Вызов функции», «programminglanguage»: «неизвестно» }, «ответ»: { «responsetype»: «предоставить рекомендации», «confidencelevel»: 5, «followupactions»: [ «Обратитесь к поставщику API за поддержкой вызова функций» ], }, «issuesummary»: «Проверка формата вызова функций». Многие из этих значений полезны при мониторинге реального производственного чат‑бота. Мы усложнили схему, чтобы результаты тестирования точнее отражали производительность и функциональность модели. Среди проблем схемы: длинные значения перечисления, вложенность объектов (это может затруднить работу LLM‑специалистов без опыта программирования), требование выводить значения в каждом вложенном компоненте только из соответствующих разделов входных данных (ответа или вопроса), объединение классификации, обобщения и генерации структурированных выходных данных в одной задаче. Тест ориентирован на структуру и классификацию — поэтому мы не использовали показатели LLM-a-a-judge, а написали пользовательские оценщики LangSmith. Мы измерили: structure verification (jsonschema: 1, если верно, 0, если нет), classification tasks (questioncategory — точность классификации по 25 допустимым значениям перечисления; offtopicsimilarity — точность бинарной классификации, посчитал ли LLM вопрос не относящимся к теме; toxicitysimilarity — нормализованная разница в прогнозируемом уровне «токсичности» пользовательского вопроса; programminglanguagesimilarity — точность классификации предсказанного языка программирования; confidencelevelsimilarity — нормализованное сходство между предсказанной «достоверностью» ответа и помеченной уверенностью; sentimentsimilarity — нормализованная разница между предсказанием и меткой; общее различие jsoneditdistance — канонизация предсказанного и эталонного JSON и вычисление расстояния в строке Дамерау‑Левенштейна между двумя сериализованными формами). Мы хотели ответить на несколько вопросов: как соотносятся популярные LLM с закрытым исходным кодом; насколько хорошо работают готовые LLM с открытым исходным кодом по сравнению с моделями с закрытым исходным кодом; насколько эффективны простые стратегии подсказок для повышения производительности извлечения; насколько важно управлять грамматикой LLM для вывода корректной записи с точки зрения отдельных показателей классификации. Мы оценили такие модели: gpt-4-1106 (предварительный просмотр последней расширенной версии GPT-4), claude-2 (LLM от Anthropic), llama-v2-34b-code-instruct (вариант Code Llama 2 с параметрами 34b, доработанный на основе набора данных инструкций), llama-v2-chat-70b (вариант Llama 2 с параметрами 70b, адаптированный для работы в чате), yi-34b-200k-capybara (модель с параметрами 34b от Nous Research). В первом эксперименте сравнили Claude-2 и GPT-4 — обе LLM с закрытым исходным кодом. Для GPT-4 использовали его tool-calling API, который позволяет предоставить схему JSON для заполнения. Поскольку Anthropic ещё не выпустила аналогичный API для вызова инструментов, мы протестировали два способа задания схемы: непосредственно в виде JSON‑схемы и в виде XSD (XML‑схемы). GPT‑4 показал лучшие результаты почти по всем показателям. Модель Claude, запрашиваемая со схемой JSON, работает немного лучше, чем модель, запрашиваемая с той же информацией в XSD (XML‑схеме) — это говорит о том, что согласованное форматирование схемы в этом случае не так важно. Мы заметили общие проблемы со схемой: например, модель выводит список с маркерами для последующих действий, а не правильно помеченные элементы, которые анализируются как строка, а не как список. Во втором эксперименте мы протестировали популярные модели с открытым исходным кодом: llama-v2-34b-code-instruct, llama-v2-chat-70b, yi-34b-200k-capybara. 70‑битный вариант Llama 2 не обеспечивал надёжного вывода JSON из‑за небольшого объёма кода в предварительной подготовке и SFT corpus. Yi‑34b был более надёжным, но соответствовал требуемой схеме только в 37% случаев. При этом он лучше справляется с классификацией questioncategory. 34‑битный код Llama 2 смог вывести корректный JSON и неплохо справился с другими показателями — мы будем использовать его в следующих экспериментах. В третьем эксперименте мы проверили, насколько простые методы подсказок помогают заставить модель выводить надёжно структурированный JSON. В базовых экспериментах чаще всего случались галлюцинации недопустимых значений перечисления и низкая производительность классификации простых вещей, например тональности вопроса. Мы протестировали три стратегии создания подсказок: добавление дополнительных инструкций, относящихся к конкретной задаче; последовательность действий (просьба к модели шаг за шагом продумать структуру схемы перед генерацией результата); несколько примеров (мы вручную разработали ожидаемые пары ввода‑вывода для модели). Ни одна из стратегий не дала существенных улучшений в рассматриваемых показателях. Использование нескольких примеров даже снизило производительность модели при тестировании схемы JSON. Предоставление инструкций в явном виде немного улучшило производительность классификации на языке программирования, но вклад незначителен. В четвёртом эксперименте мы протестировали методы структурированного декодирования (например, логит‑смещение, выборку на основе ограничений), чтобы надёжно генерировать JSON, совместимый со схемой. Мы тестировали Llama 70B, используя механизм декодирования на основе грамматики Llama.cpp, чтобы гарантировать корректную схему JSON. Декодирование на основе грамматики обеспечило 100% корректность jsonschema — это значит, что другие значения тоже можно надёжно проанализировать. Поскольку базовая модель чата Llama 70B больше и функциональнее моделей из предыдущих экспериментов, мы также видим улучшения в отношении сходства настроений и категории вопросов. Однако абсолютная производительность по этим показателям по‑прежнему низка. Декодирование на основе грамматики гарантирует структуру выходных данных, но не качество самих значений. Полные результаты экспериментов можно посмотреть по ссылке на LangSmith. Вы также можете протестировать любой из этих тестов на своей модели, следуя инструкции.