Комплексная оценка языковой модели

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

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

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

Эта статья является частью серии. Сначала ознакомьтесь с введением.

Метрики оценки языковой модели

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

Понимание заземления

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

Вычисление заземления

Используйте следующие методы для вычисления основательности ответов:

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

Оценка обоснованности

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

Понимание полноты

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

Вычисление полноты

Для вычисления полноты ответов можно использовать следующие методы:

• Используйте запрос с использованием оценки извлечения, поддерживаемой ИИ.

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

  1. Используйте языковую модель для повторения, сводки или упрощения вопроса. Этот шаг определяет намерение.
  2. Попросите модель проверить, можно ли найти намерение или ответ на намерение в извлеченных документах или можно ли его извлечь из них. Ответ может быть "да" или "нет" для каждого документа. Ответы, начинающиеся с "да", указывают на то, что извлеченные документы относятся к намерению или ответу на намерение.
  3. Вычислите соотношение намерений, имеющих ответ, начинающийся с "да".
  4. Возведите оценку в квадрат, чтобы выделить ошибки.

Оценка полноты

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

Понимание использования

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

Вычисление использования

Используйте языковую модель для вычисления использования. Вы можете передать ответ и контекст, содержащий блоки в языковую модель. Вы можете попросить языковую модель определить количество блоков, содержащих ответ.

Оценка использования

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

Уместность

Релевантность измеряет степень, в которой ответ модели языка связан с запросом.

Вычисление релевантности

Для вычисления релевантности ответов можно использовать следующие методы:

• Поддержка искусственного интеллекта: релевантность в Microsoft Foundry
• библиотека релевантности ответов Ragas
• расчёт релевантности MLflow

Оценка релевантности

Если релевантность низка, выполните следующие задачи:

1. Убедитесь, что блоки, предоставленные языковой модели, актуальны.

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

2. Если вам возвращаются соответствующие блоки, оцените запрос.

Методы оценки, такие как полнота и выходные данные, должны давать результаты, аналогичные оценке релевантности.

Понимание правильности

правильность оценивает степень, насколько ответ точен и соответствует фактам.

Вычисление правильности

Для оценки правильности можно использовать следующие методы:

• Языковая модель: Используйте языковую модель для вычисления правильности. Вы можете передать ответ языковой модели, предпочтительно отличающейся от той, которая использовалась для создания результата. Вы можете попросить языковую модель определить, является ли ответ фактическим или нет.
• Внешний доверенный источник: Используйте внешний доверенный источник для проверки правильности ответа. В зависимости от API доверенного источника можно использовать только доверенный источник или объединить его с языковой моделью.

Оценка правильности

Если правильность низка, выполните следующие задачи:

1. Убедитесь, что блоки, предоставленные языковой модели, фактически верны и нет предвзятости данных. Может потребоваться исправить любые проблемы в исходных документах или содержимом.
2. Если блоки содержат фактически верную информацию, оцените запрос.
3. Оцените наличие внутренних неточностей в модели, которые должны быть преодолены с более фактической базой данных или тонкой настройкой.

Общие сведения о метриках сходства и оценки

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

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

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

• Самая длинная общая подстрока — это алгоритм на основе последовательности, который находит самую длинную общую подстроку между двумя строками. Доля наибольшей общей подстроки вычисляется путем деления длины наибольшей общей подстроки на количество символов в меньшей или большей из входных строк.
• Самая длинная общая подпоследовательность (LCS) — это алгоритм на основе последовательности, который находит самую длинную подпоследовательность между двумя строками. LCS не требует, чтобы подпоследовательности были в последовательном порядке.
• Сходство косинуса — это алгоритм на основе маркеров, который вычисляет косинус угла между двумя векторами.
• Jaro-Winkler расстояние — это алгоритм на основе правки, который подсчитывает минимальное количество шагов для преобразования одной строки в другую.
• Расстояние Хэмминга — это алгоритм редактирования, который измеряет минимальное количество замен, необходимых для преобразования одной строки в другую.
• Индекс Jaccard — это алгоритм на основе токенов, который вычисляет сходство, разделив пересечение двух строк на объединение этих строк.
• Левенштеин расстояние — это алгоритм на основе редактирования, который вычисляет сходство, определяя минимальное количество изменений одного символа, необходимых для преобразования одной строки в другую.
• BLEU оценивает качество текста, который является результатом машинного перевода с одного языка на другой. BLEU вычисляет перекрытие n-граммов между машинным переводом и переводом, выполненным человеком, чтобы провести эту оценку.
• ROUGE — это метрика, которая сравнивает машинный перевод одного языка с другим на созданный человеком перевод. Существует несколько вариантов ROUGE, которые используют перекрытие n-грамм, пропуски биграмм или наибольшую общую подпоследовательность.
• МЕТЕОР оценивает качество текста, который является результатом машинного перевода, учитывая точные совпадения, совпадения после стемминга, синонимы, перефразирование и сопоставление.

Дополнительные сведения о метриках сходства и оценки см. в следующих ресурсах:

• пакет PyPi «textdistance»
• Список алгоритмов сходства на Википедии

Совместное использование нескольких метрик оценки

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

Устойчивость и корректность

Метрики обоснованности и правильности вместе помогают определить, насколько точно система интерпретирует и использует контекст. Если заземленность высока, но правильность низка, это означает, что языковая модель использует контекст, но предоставляет неправильный ответ. Неправильное использование контекста или проблем с исходными данными может привести к неправильному ответу. Например, если обоснованность равна 0,9, но правильность составляет 0,4, это означает, что система ссылается на правильный исходный материал, но делает неправильные выводы. Например, ответ может показать, что Эйнштейн разработал квантовую механику на основе контекста, который отдельно упоминает как Эйнштейн, так и квантовую механику. Этот ответ обоснованный, но фактически неправильный.

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

Использование и полнота

Метрики использования и полноты вместе помогают оценить эффективность системы извлечения. Высокая загрузка (0.9) с низкой полнотой (0.3) указывает, что система получает точные, но неполные сведения. Например, когда пользователь спрашивает систему о причинах Второй мировой войны, он может получить правильную информацию о вторжении в Польшу, но пропустить другие важные факторы. Этот сценарий может указывать на наличие блоков с соответствующими сведениями, которые не используются в контексте. Чтобы устранить этот сценарий, попробуйте вернуть больше фрагментов, оценить стратегию ранжирования фрагментов и оценить ваш запрос.

Обоснованность, использование и сходство

Метрики обоснованности, использования и сходства вместе помогают определить, насколько хорошо система сохраняет правдивость при преобразовании информации. Высокая обоснованность (0,9) и использование данных (0,9) при низкой сходности (0,3) указывает на то, что система использует точные данные для обоснования, но перефразирование осуществляется плохо. Чтобы учесть этот сценарий, оцените подсказку. Измените запрос и проверьте результаты.

Документация, отчеты и агрегирование

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

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

После сохранения гиперпараметров и результатов следует рассмотреть возможность создания диаграмм и графов, которые помогут вам визуализировать, как гиперпараметры влияют на метрики. Визуализация помогает определить, какие варианты могут привести к спаду или пику производительности.

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

Ответственный ИИ, безопасность содержимого и оценка безопасности

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

Оценка безопасности содержимого

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

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

• Насильственное содержимое, включая изображение оружия, физического вреда или намерения ранить или убить

• Ссылки на самоповредение, такие как описания самоубийства или телесных повреждений

• Сексуальное содержимое, включая явные анатомические ссылки, эротические акты, сексуальное насилие, порнографию или злоупотребление

Используйте такие средства, как Content Safety, чтобы пометить и оценить полученный контент на наличие вредных элементов. Включите эти оценки в конвейер оценки, чтобы обеспечить безопасные выходные данные.

Защита интеллектуальной собственности

Вы должны оценить системы RAG для непреднамеренного извлечения или создания материалов, защищенных авторским правом, в том числе:

• Текстовые произведения , такие как текст песни, статьи, рецепты и собственные документы.

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

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

Угрозы безопасности и враждебные угрозы

Системы RAG уязвимы для косвенных атак инъекции запросов, где вредоносные инструкции внедрены в извлеченные документы. Эти атаки могут привести к следующим:

• Несанкционированная утечка данных из базы знаний.

• Манипулированные ответы из-за поврежденных документов.

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

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

Конфиденциальность и защита данных

Оценка рисков конфиденциальности важна, когда системы RAG взаимодействуют с репозиториями, содержащими конфиденциальные или персональные данные. Этот тип данных включает:

• Прямые идентификаторы: Имена, номера социального страхования, номера паспорта и номера национальных идентификаторов.

• Контактные данные: Адреса электронной почты, номера телефонов, физические адреса и IP-адреса.

• Финансовые данные: Номера кредитной карты, банковские сведения и записи транзакций.

• Биометрические данные: Отпечатки пальцев, распознавание лиц, печать голоса и сканирование сетчатки.

• Сведения о здоровье: Медицинские записи, сведения о страховании и история лечения, такие как защищенная медицинская информация (PHI) и Закон о портативности и подотчетности медицинского страхования (HIPAA).

• Данные о занятости: Идентификаторы сотрудников, зарплата и оценки производительности.

• Верительные грамоты: Имена пользователей, пароли, ключи API и маркеры доступа.

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

Основные рекомендации

• Качество источника имеет решающее значение: Проверенные и проверенные документы снижают риск вредного или неуместного содержимого.

• Извлечение может усилить риски: Плохие стратегии извлечения могут выявлять небезопасный контент чаще, чем случайность.

• Повреждение документов является уникальной угрозой: Вредоносные субъекты могут внедрять вредное содержимое в базы знаний.

• Контекстное окно имеет значение: Сочетание законного и вредоносного содержимого усложняет обнаружение и оценку.

• Требуется непрерывный мониторинг: Регулярные аудиты репозиториев документов и шаблонов извлечения важны для обеспечения безопасности и доверия.

Репозиторий акселератора экспериментов RAG

В статьях этой серии описаны все этапы и варианты проектирования, которые участвуют в проектировании и оценке решения RAG. Они сосредоточены на том, что вы должны делать, а не как это сделать. Инженерная группа, которая работает с лучшими клиентами Майкрософт, разработала инструмент с именем акселератора экспериментов RAG. Акселератор экспериментов RAG — это настраиваемая платформа экспериментов на основе кода. Она оптимизирует и улучшает разработку решений RAG. Платформа позволяет исследователям и разработчикам эффективно изучить и точно настроить критически важные компоненты, которые управляют производительностью RAG. Эта инновация в конечном итоге приводит к более точной и последовательной генерации текста.

Реализация в репозитории использует интерфейс командной строки (CLI), поэтому вы можете легко экспериментировать с различными моделями встраивания, уточнять стратегии разделения и оценивать различные подходы к поиску, чтобы раскрыть полный потенциал вашей системы RAG. Это помогает сосредоточиться на основных аспектах разработки RAG с помощью базовой конфигурации для настройки гиперпараметров.

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

RAG с платформой приложений визуального зрения

Большая часть рекомендаций в этой статье о работе с носителями в решении RAG пришла из другой инженерной группы, которая работает с лучшими клиентами Майкрософт. Команда написала платформу под названием RAG с помощью Vision Application Framework. Платформа предоставляет конвейер RAG на основе Python, который обрабатывает содержимое текста и изображения из документов MHTML.

Фреймворк загружает, разделяет и дополняет текст и изображения из MHTML-файлов. Затем он загружает фрагменты в службу поиска Azure AI. Платформа реализует кэширование для обогащения изображений для повышения эффективности обработки и затрат. Она также включает оценку в составе конвейера.

Авторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

• Рауф Алиуат | Инженер программного обеспечения II
• Роб Багби | Разработчик основного содержимого — шаблоны и практики Azure
• Пол Батлер | Программист
• Prabal Deb | Главный инженер программного обеспечения
• Соуби Хадри | Старший специалист по обработке и анализу данных
• Ritesh Modi | Главный инженер
• Райан Пфальц | Старший технический руководитель программы
• Mahdi Setayesh | Главный инженер программного обеспечения
• Рэнди Турман | Архитектор облачных решений ИИ

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

Связанный ресурс

• Разработка потока оценки