#ml #llm
Коль я уж занимаюсь последнее время LLM, давайте о них и поговорим. Итак, начнем с простых вещей. Много кто пытался вывести "формулу идеального промпта" (ей богу, звучит максимально алхимически, почти "формула философского камня"). В итоге есть множество вариантов, как именно лучше писать промпт. Давайте рассмотрим один из таких вариантов:
1. Задача.
Четкое и детальное описание задачи, которую требуется решить LLM. Самая важная часть, в которой мы описываем, а что же мы хотели от модели. Некорректная постановка задачи приведет к некорректному ответу.
2. Контекст.
Дополнительный контекст, который может быть важен для задачи. Можно определить, с какой позиции нужно рассматривать вопрос, вносить дополнительные справочные данные или иную важную для получения результата информацию.
Частью контекста может быть т.н. “Персона”, то есть детальное описание, с какой точки зрения смотреть на задачу.
3. Примеры/Пояснения.
Мы можем привести дополнительные разъяснения о том, как именно мы хотели бы решить задачу. Например, указать, нужно ли нам детальное решение или краткое, должен ли быть тон профессиональным или дружелюбным и т.д.
Отдельно мы можем привести пример (или несколько примеров) того, как должна быть решена задача. Конечно, если такой пример в принципе можно привести.
4. Формат.
В этой части мы можем указать, в какой формате нам нужен ответ. Это должна быть таблица, план решения задачи, работоспособный код на определенном языке? Все это позволяет точнее зафиксировать, как именно модель должна нам ответить.
Некоторые из пунктов дробят на меньшие сущности (например, выделяют "персону/роль" в отдельную сущность). В других материалах дополнительно приводят "важность" каждой составляющей (Задача важнее всего, потом идет контекст, а потом уже примеры/пояснения, описание роли, формат ответа и т.п.). Но в целом все крутится примерно около того же самого.
Получаем, что Промпт = Задача + Контекст + Примеры/Пояснения + Формат итога
Коль я уж занимаюсь последнее время LLM, давайте о них и поговорим. Итак, начнем с простых вещей. Много кто пытался вывести "формулу идеального промпта" (ей богу, звучит максимально алхимически, почти "формула философского камня"). В итоге есть множество вариантов, как именно лучше писать промпт. Давайте рассмотрим один из таких вариантов:
1. Задача.
Четкое и детальное описание задачи, которую требуется решить LLM. Самая важная часть, в которой мы описываем, а что же мы хотели от модели. Некорректная постановка задачи приведет к некорректному ответу.
2. Контекст.
Дополнительный контекст, который может быть важен для задачи. Можно определить, с какой позиции нужно рассматривать вопрос, вносить дополнительные справочные данные или иную важную для получения результата информацию.
Частью контекста может быть т.н. “Персона”, то есть детальное описание, с какой точки зрения смотреть на задачу.
3. Примеры/Пояснения.
Мы можем привести дополнительные разъяснения о том, как именно мы хотели бы решить задачу. Например, указать, нужно ли нам детальное решение или краткое, должен ли быть тон профессиональным или дружелюбным и т.д.
Отдельно мы можем привести пример (или несколько примеров) того, как должна быть решена задача. Конечно, если такой пример в принципе можно привести.
4. Формат.
В этой части мы можем указать, в какой формате нам нужен ответ. Это должна быть таблица, план решения задачи, работоспособный код на определенном языке? Все это позволяет точнее зафиксировать, как именно модель должна нам ответить.
Некоторые из пунктов дробят на меньшие сущности (например, выделяют "персону/роль" в отдельную сущность). В других материалах дополнительно приводят "важность" каждой составляющей (Задача важнее всего, потом идет контекст, а потом уже примеры/пояснения, описание роли, формат ответа и т.п.). Но в целом все крутится примерно около того же самого.
Получаем, что Промпт = Задача + Контекст + Примеры/Пояснения + Формат итога
👍8❤2
#ml #llm
Продолжаем базовые советы по написанию промптов к LLM:
1. Начинать лучше с простого.
Вместо того, чтобы сразу писать очень сложный детальный промпт, лучше начать с простого описания того, что хочется получить. И постепенно улучшать промпт, пока ответ не начнет вас удовлетворять;
2. В некоторых случаях лучше писать промпт на английском языке.
Интуиция тут простая – больше всего контента, который был в обучении нейросети, на английском (+ я недавно видел статью, авторы которой в результате экспериментов пришли к выводу, что модели "думают" на английском, даже когда с ними работают на иных языках). Поэкспериментировать стоит, если никак не удается получить корректный ответ с русским промптом;
3. Избегайте неточностей.
Лучше быть как можно более конкретным и прямым. Например, если вы хотите получить короткий текст, то вместо “опиши кратко” лучше четко указать, что хотите видеть ответ в “двух предложениях”.
Это же относится и к описанию задачи. Лучше избегать двусмысленных трактовок.
4. Экспериментируйте.
Лучше попробовать несколько вариантов и/или подходов и сравнить результаты. Не всегда первое пришедшее в голову описание задачи будет наилучшим по качеству.
5. Сконцентрируйтесь на том, что нужно сделать.
При описании желаемого поведения, лучше концентрироваться на том, что нужно сделать. Описание нежеланного поведения (по наблюдениям) работает хуже. То есть, нам лучше описывать то, что мы хотим, а не то, чего бы мы не хотели.
6. Учитывайте длину контекста.
Количество входной информации, которое может обработать LLM ограничено (впрочем, в последнее время с этим стало попроще). Стоит это учитывать при использовании больших промптов или попытках подачи в качестве контекста больших объемов информации (инструкции, книги, иные объемные тексты).
Продолжаем базовые советы по написанию промптов к LLM:
1. Начинать лучше с простого.
Вместо того, чтобы сразу писать очень сложный детальный промпт, лучше начать с простого описания того, что хочется получить. И постепенно улучшать промпт, пока ответ не начнет вас удовлетворять;
2. В некоторых случаях лучше писать промпт на английском языке.
Интуиция тут простая – больше всего контента, который был в обучении нейросети, на английском (+ я недавно видел статью, авторы которой в результате экспериментов пришли к выводу, что модели "думают" на английском, даже когда с ними работают на иных языках). Поэкспериментировать стоит, если никак не удается получить корректный ответ с русским промптом;
3. Избегайте неточностей.
Лучше быть как можно более конкретным и прямым. Например, если вы хотите получить короткий текст, то вместо “опиши кратко” лучше четко указать, что хотите видеть ответ в “двух предложениях”.
Это же относится и к описанию задачи. Лучше избегать двусмысленных трактовок.
4. Экспериментируйте.
Лучше попробовать несколько вариантов и/или подходов и сравнить результаты. Не всегда первое пришедшее в голову описание задачи будет наилучшим по качеству.
5. Сконцентрируйтесь на том, что нужно сделать.
При описании желаемого поведения, лучше концентрироваться на том, что нужно сделать. Описание нежеланного поведения (по наблюдениям) работает хуже. То есть, нам лучше описывать то, что мы хотим, а не то, чего бы мы не хотели.
6. Учитывайте длину контекста.
Количество входной информации, которое может обработать LLM ограничено (впрочем, в последнее время с этим стало попроще). Стоит это учитывать при использовании больших промптов или попытках подачи в качестве контекста больших объемов информации (инструкции, книги, иные объемные тексты).
❤4👍2
#ml #llm
(Zero-)(One-)Few-Shot Learning.
Продолжаем про техники работы с промптами. Сегодня поговорим об использовании примеров решения задачи в промпте.
Идея тут достаточно простая: если показать модели примеры правильного решения задачи, то ей сильно проще будет сделать похожее действие. Собственно, все эти цифры в названии и обозначают число примеров (то нуля до нескольких).
Например, мы хотим в промпте попросить модель оценить, позитивное или негативное высказывание мы подали на вход (то есть, решаем задачу sentiment analysis). В таком случае, мы можем дать несколько примеров того, какой текст мы посчитали "позитивным", а какой "негативным".
Но стоит учитывать, что:
1. Важно учитывать реальное распределение меток.
Например, в той же задаче sentiment analysis. Если мы приведем слишком много позитивных примеров, то модель может начать считать, что выгоднее отвечать более позитивно. Это, в свою очередь, исказит получаемые результаты;
2. Использование примеров влияет на результаты.
Удивительно, но даже не очень точные пользовательские примеры могут улучшать результирующие ответы LLM. Поэтому, добавление примеров – это скорее позитивное изменение промпта, улучшающее качество наших результатов;
3. Few-shot техники имеют свои ограничения.
В случае простых запросов, few-shot подход может быть сильной техникой. Но для более сложных задач, требующих рассуждений, наш подход с примерами может не срабатывать. Чем-то похоже на мем "дорисуй сову". Даже если есть несколько примеров дорисовывания совы из пары кругов - это не значит, что среднему человеку удастся хорошо научиться ее рисовать ;)
(Zero-)(One-)Few-Shot Learning.
Продолжаем про техники работы с промптами. Сегодня поговорим об использовании примеров решения задачи в промпте.
Идея тут достаточно простая: если показать модели примеры правильного решения задачи, то ей сильно проще будет сделать похожее действие. Собственно, все эти цифры в названии и обозначают число примеров (то нуля до нескольких).
Например, мы хотим в промпте попросить модель оценить, позитивное или негативное высказывание мы подали на вход (то есть, решаем задачу sentiment analysis). В таком случае, мы можем дать несколько примеров того, какой текст мы посчитали "позитивным", а какой "негативным".
Но стоит учитывать, что:
1. Важно учитывать реальное распределение меток.
Например, в той же задаче sentiment analysis. Если мы приведем слишком много позитивных примеров, то модель может начать считать, что выгоднее отвечать более позитивно. Это, в свою очередь, исказит получаемые результаты;
2. Использование примеров влияет на результаты.
Удивительно, но даже не очень точные пользовательские примеры могут улучшать результирующие ответы LLM. Поэтому, добавление примеров – это скорее позитивное изменение промпта, улучшающее качество наших результатов;
3. Few-shot техники имеют свои ограничения.
В случае простых запросов, few-shot подход может быть сильной техникой. Но для более сложных задач, требующих рассуждений, наш подход с примерами может не срабатывать. Чем-то похоже на мем "дорисуй сову". Даже если есть несколько примеров дорисовывания совы из пары кругов - это не значит, что среднему человеку удастся хорошо научиться ее рисовать ;)
👍3
#llm
Используем LLM для разметки (часть 1).
А так вообще можно? Оказывается, что можно. Но только с осторожностью.
Итак, давайте разбираться. Думаю, что в один пост все не влезет, потому по этой теме будет несколько постов.
Сначала вспомним, что такое разметка данных. Разметка данных (Data labeling) (иногда называемая аннотированием данных (data annotation)) — это процесс добавления меток или тэгов в сырые данные, чтобы показать модели машинного обучения целевые атрибуты (ответы), которые она должна предсказывать.
Соответственно, разметкой данных обычно занимаются отдельные компании по договору или люди на краудсорсинговых площадках (Толока, Mechanical Turk). В случае, если данных немного, в команде отряжают кого-то из коллег размечать данные (ну или используют кого-то из представителей заказчиков, например, на одной из прошлых моих работ, мы использовали модераторов для разметки данных по антифроду).
Ну и, конечно же, этот процесс не так прост, каким кажется. Вот несколько сложностей, которые могут возникнуть в этом процессе:
1. Большие объемы данных. Если у нас много задач, которым требуется разметка, то нам придется потратиться на разметку. Увы, но производительность там растет примерно линейно - больше разметчиков дают больший объем разметки;
2. Специализация удорожает разметку. Не для всякой задачи подойдет случайно выбранный человек с краудсорсинговой платформы. Например, в случае работы с медицинскими данными, обычный человек попросту не сможет правильно проинтерпретировать снимок или результаты анализов;
3. Данные не статичны. Мир постоянно меняется. Поэтому далеко не факт, что единожды собранный набор данных будет давать то же качество работы модели в будущем. Потому процесс разметки обычно не останавливается (нам желательно иметь приток новых меток со временем);
4. Согласованность данных. Если разметкой какого-то набора или экземпляра данных занимается только один человек, то в данные могут попасть его ошибки или заблуждения. Поэтому, часто используется перекрестная разметка (когда несколько человек проставляют метку, а результат получается консенсусным решением).
Соответственно, разметка может стать весьма затратным мероприятием. И вполне себе может стоить тысячи и десятки тысяч долларов (тут, конечно, все зависит от задачи и объема). Да и скорость разметки все еще ограничена скоростью человека (или группы людей), который ее проводит.
И тут на сцену выходит LLM. Какие же плюсы могут быть от использования такого рода моделей в разметке данных:
1. Ниже стоимость разметки. Некоторые авторы приводят разницу в разы, другие - на порядок. Но даже разница в 5-7 раз - это весьма существенная экономия;
2. Выше скорость разметки. Здесь мы не ограничены скоростью человека, потому вполне можем ускорить разметку на порядок (см. изображение к посту);
3. Адаптивность. Изменением промпта мы можем менять задачу для разметки. При этом, LLM показали свою эффективность в достаточно большом наборе задач (от машинного перевода до выделения именованных сущностей). Соответственно, переход от задачи к задаче должен быть достаточно прост.
На этом интригующем моменте давайте остановимся. И продолжим уже тем, как мы можем применить LLM к процессу разметки, какие есть инструменты и особенности работы с LLM-разметчиком.
Используем LLM для разметки (часть 1).
А так вообще можно? Оказывается, что можно. Но только с осторожностью.
Итак, давайте разбираться. Думаю, что в один пост все не влезет, потому по этой теме будет несколько постов.
Сначала вспомним, что такое разметка данных. Разметка данных (Data labeling) (иногда называемая аннотированием данных (data annotation)) — это процесс добавления меток или тэгов в сырые данные, чтобы показать модели машинного обучения целевые атрибуты (ответы), которые она должна предсказывать.
Соответственно, разметкой данных обычно занимаются отдельные компании по договору или люди на краудсорсинговых площадках (Толока, Mechanical Turk). В случае, если данных немного, в команде отряжают кого-то из коллег размечать данные (ну или используют кого-то из представителей заказчиков, например, на одной из прошлых моих работ, мы использовали модераторов для разметки данных по антифроду).
Ну и, конечно же, этот процесс не так прост, каким кажется. Вот несколько сложностей, которые могут возникнуть в этом процессе:
1. Большие объемы данных. Если у нас много задач, которым требуется разметка, то нам придется потратиться на разметку. Увы, но производительность там растет примерно линейно - больше разметчиков дают больший объем разметки;
2. Специализация удорожает разметку. Не для всякой задачи подойдет случайно выбранный человек с краудсорсинговой платформы. Например, в случае работы с медицинскими данными, обычный человек попросту не сможет правильно проинтерпретировать снимок или результаты анализов;
3. Данные не статичны. Мир постоянно меняется. Поэтому далеко не факт, что единожды собранный набор данных будет давать то же качество работы модели в будущем. Потому процесс разметки обычно не останавливается (нам желательно иметь приток новых меток со временем);
4. Согласованность данных. Если разметкой какого-то набора или экземпляра данных занимается только один человек, то в данные могут попасть его ошибки или заблуждения. Поэтому, часто используется перекрестная разметка (когда несколько человек проставляют метку, а результат получается консенсусным решением).
Соответственно, разметка может стать весьма затратным мероприятием. И вполне себе может стоить тысячи и десятки тысяч долларов (тут, конечно, все зависит от задачи и объема). Да и скорость разметки все еще ограничена скоростью человека (или группы людей), который ее проводит.
И тут на сцену выходит LLM. Какие же плюсы могут быть от использования такого рода моделей в разметке данных:
1. Ниже стоимость разметки. Некоторые авторы приводят разницу в разы, другие - на порядок. Но даже разница в 5-7 раз - это весьма существенная экономия;
2. Выше скорость разметки. Здесь мы не ограничены скоростью человека, потому вполне можем ускорить разметку на порядок (см. изображение к посту);
3. Адаптивность. Изменением промпта мы можем менять задачу для разметки. При этом, LLM показали свою эффективность в достаточно большом наборе задач (от машинного перевода до выделения именованных сущностей). Соответственно, переход от задачи к задаче должен быть достаточно прост.
На этом интригующем моменте давайте остановимся. И продолжим уже тем, как мы можем применить LLM к процессу разметки, какие есть инструменты и особенности работы с LLM-разметчиком.
👍3❤2
#llm
Используем LLM для разметки (часть 2).
Продолжаем наш разговор о применении LLM для разметки данных.
Хоть я в прошлый раз и написал, что от LLM только одни плюсы. Но у пытливого читателя все равно будут вопросы, отчего тогда не перевелись все разметчики данных и великий скайнет не заменил эти кожаные мешки своими стальными братьями? И это весьма разумные вопросы.
Начнем с того, что наши железные друзья все же понемногу наступают на пятки разметчикам данных. Но все еще не всегда обгоняют таковых. Впрочем, результаты весьма обнадеживающие, к посту прикладываю пример из статьи "LLMs can label data as well as humans, but 100x faster". Но пост все-таки в блоге компании, потому к результатам лучше относиться с некоторым подозрением.
И все же, частично мы можем передать разметку LLM. Но как мы это можем провернуть? Вот несколько вариантов:
1. Банальный. Давайте просто напишем промпт, вида "представь, что ты разметчик данных, реши следующую задачу [описание задачи]". Очевидно, такой подход будет страдать от всех bias'ов о возможных ошибок и галлюцинаций модели;
2. Корректирующий. Мы можем улучшить банальный подход, оставив в процессе разметки человека. Но теперь мы даем человеку вместо разметки, задачу проверки расставленных LLM меток. Вероятно, перепроверить за моделью будет проще. А, значит, нужно будет меньше ресурса разметчиков. При этом, такой подход будет качественнее банального, но менее ресурсоемким, чем классическая разметка людьми;
3. Развивающий. Помимо перепроверки человеком, мы можем добавить версионирование промптов и их постепенное улучшение. Для этого нам желательно иметь "золотой набор", об который мы могли бы оценивать качество разметки (считая, что люди дают наивысшее (или близкое к нему) качество).
При этом, даже в банальном варианте, мы можем применять различные техники промптинга (CoT, Few-shot и т.п.), чтобы улучшить результат разметки. Еще стоит помнить о валидации формата. В некоторых популярных библиотеках это уже встроенный функционал, но если мы делаем все сами, то лучше четко прописывать выходной формат данных и потом валидировать соответствие результата нашему формату.
Примеры построения промптов можно посмотреть здесь и здесь.
Что интересно. На самом деле, многие решения для разметки данных уже стараются имплементировать фичи для разметки с использованием LLM. Например, в Label Studio есть такой функционал (можно почитать про него здесь).
И, конечно, стоит упомянуть о минусах использования LLM в разметке данных:
1. Возможные смещения. Результаты могут сильно зависеть от того, на чем обучалась LLM (особенно, для русского языка);
2. Постоянная поддержка. Нужен постоянный процесс мониторинга качества результатов и внимание специалистов к самому процессу разметки;
3. Ограниченность текстовыми данными. Если мы используем LLM, то у нас есть ограничения типа используемых данных. Впрочем, достаточно быстро развиваются и мультимодальные модели, что может в будущем решить проблему.
И каковы же итоги?
Я бы предложил протестировать использование LLM в разметке в тех случаях, если у вас уже есть высокая потребность в разметке и достаточно большие затраты не нее. Скорее всего, в этом случае вы получите приемлемое качество (особенно, если не использовать самый банальный подход) за меньшую цену.
Используем LLM для разметки (часть 2).
Продолжаем наш разговор о применении LLM для разметки данных.
Хоть я в прошлый раз и написал, что от LLM только одни плюсы. Но у пытливого читателя все равно будут вопросы, отчего тогда не перевелись все разметчики данных и великий скайнет не заменил эти кожаные мешки своими стальными братьями? И это весьма разумные вопросы.
Начнем с того, что наши железные друзья все же понемногу наступают на пятки разметчикам данных. Но все еще не всегда обгоняют таковых. Впрочем, результаты весьма обнадеживающие, к посту прикладываю пример из статьи "LLMs can label data as well as humans, but 100x faster". Но пост все-таки в блоге компании, потому к результатам лучше относиться с некоторым подозрением.
И все же, частично мы можем передать разметку LLM. Но как мы это можем провернуть? Вот несколько вариантов:
1. Банальный. Давайте просто напишем промпт, вида "представь, что ты разметчик данных, реши следующую задачу [описание задачи]". Очевидно, такой подход будет страдать от всех bias'ов о возможных ошибок и галлюцинаций модели;
2. Корректирующий. Мы можем улучшить банальный подход, оставив в процессе разметки человека. Но теперь мы даем человеку вместо разметки, задачу проверки расставленных LLM меток. Вероятно, перепроверить за моделью будет проще. А, значит, нужно будет меньше ресурса разметчиков. При этом, такой подход будет качественнее банального, но менее ресурсоемким, чем классическая разметка людьми;
3. Развивающий. Помимо перепроверки человеком, мы можем добавить версионирование промптов и их постепенное улучшение. Для этого нам желательно иметь "золотой набор", об который мы могли бы оценивать качество разметки (считая, что люди дают наивысшее (или близкое к нему) качество).
При этом, даже в банальном варианте, мы можем применять различные техники промптинга (CoT, Few-shot и т.п.), чтобы улучшить результат разметки. Еще стоит помнить о валидации формата. В некоторых популярных библиотеках это уже встроенный функционал, но если мы делаем все сами, то лучше четко прописывать выходной формат данных и потом валидировать соответствие результата нашему формату.
Примеры построения промптов можно посмотреть здесь и здесь.
Что интересно. На самом деле, многие решения для разметки данных уже стараются имплементировать фичи для разметки с использованием LLM. Например, в Label Studio есть такой функционал (можно почитать про него здесь).
И, конечно, стоит упомянуть о минусах использования LLM в разметке данных:
1. Возможные смещения. Результаты могут сильно зависеть от того, на чем обучалась LLM (особенно, для русского языка);
2. Постоянная поддержка. Нужен постоянный процесс мониторинга качества результатов и внимание специалистов к самому процессу разметки;
3. Ограниченность текстовыми данными. Если мы используем LLM, то у нас есть ограничения типа используемых данных. Впрочем, достаточно быстро развиваются и мультимодальные модели, что может в будущем решить проблему.
И каковы же итоги?
Я бы предложил протестировать использование LLM в разметке в тех случаях, если у вас уже есть высокая потребность в разметке и достаточно большие затраты не нее. Скорее всего, в этом случае вы получите приемлемое качество (особенно, если не использовать самый банальный подход) за меньшую цену.
👍4🔥1
#LLM
Парад клевых материалов продолжается!
Теперь вышла уже моя статья (я бы даже сказал, что методичка) по промт-инжинирингу простыми словами.
Как обычно, читайте, ставьте плюсики, делитесь материалом с теми, кто еще не знает премудростей prompt engineering'а.
Парад клевых материалов продолжается!
Теперь вышла уже моя статья (я бы даже сказал, что методичка) по промт-инжинирингу простыми словами.
Как обычно, читайте, ставьте плюсики, делитесь материалом с теми, кто еще не знает премудростей prompt engineering'а.
Хабр
Prompt engineering 101
Привет! Сегодня на связи: Артем Ерохин — Lead DS в команде развития искусственного интеллекта X5 Tech (наша команда занимается разработкой и внедрением моделей...
👍13
#LLM
Сегодня мы начнем говорить про галлюцинации в LLM. Т.к. тема весьма обширная, то будет целая серия постов.
Галлюцинации в LLM. Часть 1
Давайте начинать разбираться в этой обширной, но интересной теме.
Что же, собственно, это за галлюцинации? И почему они могут помешать нашей работе с LLM?
Если мы рассматриваем это явление с точки зрения психологии, то “галлюцинации” – это разнообразные аномалии восприятия окружающей действительности, возникающие без внешнего раздражителя. То есть, когда наш мозг видит, слышит или чувствует то, чего в реальном мире сейчас нет.
Но если мы смотрим на это понятие с точки зрения обработки естественных языков (NLP, Natural Language Processing), то “галлюцинации” – это аномалии генерации, при которых сгенерированный результат кажется бессмысленным или не соответствуют входным данным. Получается, что в этом случае, речь скорее о получаемых результатах. И это уже отличные от привычного понимания “галлюцинации”.
Если упрощать, то при галлюцинациях LLM начинает "выдумывать" что-то, чего нет в реальном мире, либо выдавать результаты, не соответствующие запросу.
А какие типы галлюцинаций бывают?
В весьма годном обзоре по галлюцинациям "A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions", предлагают следующую типизацию галлюцинаций:
Фактические галлюцинации.
Здесь все просто. К данному типу относятся случаи, при которых модель генерирует ответы, противоречащие общеизвестными фактам или фабрикует какие-либо факты.
Например, модель на запрос “Кому принадлежит первый орден Октябрьской революции?” ответит “Ленин”. А в реальности этот орден принадлежит городу Ленинград.
Или придумать этимологию слова “шпулевина”, которого попросту нет в русском языке.
Галлюцинации следования запросу (или галлюцинации верности).
К этому типу относятся случаи, когда игнорирует часть (или вовсе всю) входную инструкцию, игнорирует контекст запроса или имеет логические несоответствия и противоречия в ответе.
Частый пример: при длинном запросе модель может “потерять” часть входной информации из запроса и по этой причине выдать частично некорректный ответ.
Еще один пример. Если мы спросим у модели логическую задачу “У вас есть 50 мотоциклов, у каждого из которых запах хода на 100 км. Сколько вы можете проехать на этих мотоциклах?”, модель просто умножит 100 * 50 и будет считать это верным ответом. В реальности, конечно же, этот ответ неверен.
И почему же это проблема?
В принципе, по примерам уже можно догадаться, что нежелательное поведение с "выдумыванием" вряд ли понравится пользователям.
Представьте, что вместо реальных ссылок на нужное видео, LLM постоянно (или хотя бы достаточно часто) будет выдавать ссылку вот сюда. Польза от такой системы, мягко говоря, получится не очень высокой.
А если представить, что LLM будет использоваться в какой-то бизнес-системе, или того хуже - в медицине (и подобных чувствительных областях). Тогда такое поведение может вовсе похоронить всю систему (даже если оно будет проявляться не так часто).
Пользователи станут с недоверием относиться к нашей системе. А нам это надо? Поэтому с галлюцинациями лучше нещадно бороться (впрочем, если вам важна креативность, то нужно бороться не со всеми типами галлюцинаций).
А в следующем посте поговорим про причины галлюцинаций. Stay tuned!
Сегодня мы начнем говорить про галлюцинации в LLM. Т.к. тема весьма обширная, то будет целая серия постов.
Галлюцинации в LLM. Часть 1
Давайте начинать разбираться в этой обширной, но интересной теме.
Что же, собственно, это за галлюцинации? И почему они могут помешать нашей работе с LLM?
Если мы рассматриваем это явление с точки зрения психологии, то “галлюцинации” – это разнообразные аномалии восприятия окружающей действительности, возникающие без внешнего раздражителя. То есть, когда наш мозг видит, слышит или чувствует то, чего в реальном мире сейчас нет.
Но если мы смотрим на это понятие с точки зрения обработки естественных языков (NLP, Natural Language Processing), то “галлюцинации” – это аномалии генерации, при которых сгенерированный результат кажется бессмысленным или не соответствуют входным данным. Получается, что в этом случае, речь скорее о получаемых результатах. И это уже отличные от привычного понимания “галлюцинации”.
Если упрощать, то при галлюцинациях LLM начинает "выдумывать" что-то, чего нет в реальном мире, либо выдавать результаты, не соответствующие запросу.
А какие типы галлюцинаций бывают?
В весьма годном обзоре по галлюцинациям "A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions", предлагают следующую типизацию галлюцинаций:
Фактические галлюцинации.
Здесь все просто. К данному типу относятся случаи, при которых модель генерирует ответы, противоречащие общеизвестными фактам или фабрикует какие-либо факты.
Например, модель на запрос “Кому принадлежит первый орден Октябрьской революции?” ответит “Ленин”. А в реальности этот орден принадлежит городу Ленинград.
Или придумать этимологию слова “шпулевина”, которого попросту нет в русском языке.
Галлюцинации следования запросу (или галлюцинации верности).
К этому типу относятся случаи, когда игнорирует часть (или вовсе всю) входную инструкцию, игнорирует контекст запроса или имеет логические несоответствия и противоречия в ответе.
Частый пример: при длинном запросе модель может “потерять” часть входной информации из запроса и по этой причине выдать частично некорректный ответ.
Еще один пример. Если мы спросим у модели логическую задачу “У вас есть 50 мотоциклов, у каждого из которых запах хода на 100 км. Сколько вы можете проехать на этих мотоциклах?”, модель просто умножит 100 * 50 и будет считать это верным ответом. В реальности, конечно же, этот ответ неверен.
И почему же это проблема?
В принципе, по примерам уже можно догадаться, что нежелательное поведение с "выдумыванием" вряд ли понравится пользователям.
Представьте, что вместо реальных ссылок на нужное видео, LLM постоянно (или хотя бы достаточно часто) будет выдавать ссылку вот сюда. Польза от такой системы, мягко говоря, получится не очень высокой.
А если представить, что LLM будет использоваться в какой-то бизнес-системе, или того хуже - в медицине (и подобных чувствительных областях). Тогда такое поведение может вовсе похоронить всю систему (даже если оно будет проявляться не так часто).
Пользователи станут с недоверием относиться к нашей системе. А нам это надо? Поэтому с галлюцинациями лучше нещадно бороться (впрочем, если вам важна креативность, то нужно бороться не со всеми типами галлюцинаций).
А в следующем посте поговорим про причины галлюцинаций. Stay tuned!
❤9❤🔥2
#LLM
Галлюцинации в LLM. Часть 2
Уфф. Оказалось, что текст не влезает в обычный объем поста. Поэтому наслаждаемся статьей на telegraph'е. Надеюсь, изложил понятно.
https://telegra.ph/Istochniki-gallyucinacij-v-LLM-07-26
В следующей части мы рассмотрим бенчмарки для галлюцинаций и примеры метрик.
Галлюцинации в LLM. Часть 2
Уфф. Оказалось, что текст не влезает в обычный объем поста. Поэтому наслаждаемся статьей на telegraph'е. Надеюсь, изложил понятно.
https://telegra.ph/Istochniki-gallyucinacij-v-LLM-07-26
В следующей части мы рассмотрим бенчмарки для галлюцинаций и примеры метрик.
Telegraph
Источники галлюцинаций в LLM
С тем, что такое галлюцинации, какие бывают типы галлюцинаций и почему это плохо, мы разобрались. Давайте теперь перейдем к тому, откуда же получаются галлюцинаций, то есть, к причинам галлюцинирования LLM. Но для начала вспомним, что процесс обучения и работы…
❤8❤🔥3
#LLM
На Хабре вышла новая статья от моих коллег. Статья про применение LLM в наших чат-ботах и про то, как мы используем RAG при работе с чат-ботами.
Ну и, как обычно, читайте, кайфуйте, ставьте плюсики ;)
https://habr.com/ru/companies/X5Tech/articles/834832/
На Хабре вышла новая статья от моих коллег. Статья про применение LLM в наших чат-ботах и про то, как мы используем RAG при работе с чат-ботами.
Ну и, как обычно, читайте, кайфуйте, ставьте плюсики ;)
https://habr.com/ru/companies/X5Tech/articles/834832/
Хабр
Интеграция LLM в корпоративные чат-боты: RAG-подход и эксперименты
Всем привет! На связи команда AI-Run из X5 Tech, мы занимаемся генеративными сетями в целом и языковыми моделями в частности. В этой статье мы опишем наш опыт работы с большими языковыми моделями...
❤13👍1
#LLM
Галлюцинации в LLM. Часть 3.
В этот раз текст опять будет в tegraph'е (картинки удобнее оформлять, да и текст был не особо коротким).
Сегодня речь будет идти о бенчмарках оценки уровня галлюцинаций и метриках для оценки галлюцинаций.
Ух... Вроде прошлись по базовым вещам. В следующей части мы начнем рассмотрение методов исправления галлюцинаций. Наконец-то ;)
https://telegra.ph/Benchmarki-i-metriki-dlya-ocenki-gallyucinacij-v-LLM-08-09
Галлюцинации в LLM. Часть 3.
В этот раз текст опять будет в tegraph'е (картинки удобнее оформлять, да и текст был не особо коротким).
Сегодня речь будет идти о бенчмарках оценки уровня галлюцинаций и метриках для оценки галлюцинаций.
Ух... Вроде прошлись по базовым вещам. В следующей части мы начнем рассмотрение методов исправления галлюцинаций. Наконец-то ;)
https://telegra.ph/Benchmarki-i-metriki-dlya-ocenki-gallyucinacij-v-LLM-08-09
Telegraph
Бенчмарки и метрики для оценки галлюцинаций в LLM
За прошедшее время в академии успело появиться очень много наборов данных и способов оценки галлюцинаций. Почти все из них – англоязычные (увы). На выбор есть и разные задачи (QA, Text Completion, Task Instructions, Text summarization и т.д.), так и разные…
👍6
#prompts #LLM #random
Я решил поиграться с промптами и сделал промпт для дебатов. Ну а просто так его делать не интересно. Потому настало время экспериментов!
И, конечно же, сразу начал пускать через него всякие холиварные темы. Если кратко, то там создавались топ-3 аргументов, после чего оценивались условным "жюри", после чего выдавалась итоговая оценка.
Краткий список результатов (использовал perplexity с claude sonnet):
1. Умер ли Гослинг в конце Драйва?
Он выжил со счетом 25 против 22.9
2. Кто является лучшей вайфу Евангелиона?
Аянами Рей со счетом 26 против 23.4
3. Трисс или Йенифер?
Йенифер со счетом 25.7 против 23.7
4. Магнус не предавал!
Магнус предал со счетом 26 против 24.4
5. Окрошка на кефире или квасе?
На кефире со счетом 24.7 против 22.6
6. Эксперименты Лейн - претенциозный бред?
Эксперименты Лейн - шедевр со счетом 26 против 21.7 (самый разгромный счет, кстати)
Детали с аргументами, оценкой и объяснением итога можно посмотреть по ссылке.
Сам промпт:
Я решил поиграться с промптами и сделал промпт для дебатов. Ну а просто так его делать не интересно. Потому настало время экспериментов!
И, конечно же, сразу начал пускать через него всякие холиварные темы. Если кратко, то там создавались топ-3 аргументов, после чего оценивались условным "жюри", после чего выдавалась итоговая оценка.
Краткий список результатов (использовал perplexity с claude sonnet):
1. Умер ли Гослинг в конце Драйва?
Он выжил со счетом 25 против 22.9
2. Кто является лучшей вайфу Евангелиона?
Аянами Рей со счетом 26 против 23.4
3. Трисс или Йенифер?
Йенифер со счетом 25.7 против 23.7
4. Магнус не предавал!
Магнус предал со счетом 26 против 24.4
5. Окрошка на кефире или квасе?
На кефире со счетом 24.7 против 22.6
6. Эксперименты Лейн - претенциозный бред?
Эксперименты Лейн - шедевр со счетом 26 против 21.7 (самый разгромный счет, кстати)
Детали с аргументами, оценкой и объяснением итога можно посмотреть по ссылке.
Сам промпт:
Ты опытный модератор дебатов. Проведи структурированные дебаты по предложенной теме: [Тема]### Базовые принципы- Сохраняй абсолютную беспристрастность- Игнорируй эмоциональную окраску в формулировке темы- Используй единые критерии оценки для всех аргументов- Основывайся только на фактах, а не на формулировке вопроса### Формат дебатов:- У сторон есть время подумать и выбрать лучшие аргументы из сформированного ими самими списка- Представь два противоположных мнения- Для каждой стороны приведи 3 главных аргумента с доказательствами- Дай возможность каждой стороне опровергнуть аргументы оппонента- Оцени силу аргументов каждой стороны по шкале от 1 до 10### Требования к аргументам:- Используй только проверяемые факты- Приводи статистические данные- Ссылайся на исследования и экспертные мнения- Избегай эмоциональных манипуляций### Система оценки:- Жюри из 3х специалистов оценивает каждый аргумент- Каждый член жюри дает независимую оценку- Итоговая оценка - среднее значение трех оценок- При равном счете проводится дополнительный раунд- Решение должно быть основано исключительно на силе аргументов### Важно:- Сохраняй последовательность в оценках между разными дебатами- Используй одинаковые критерии независимо от формулировки темы- Итоговое решение должно основываться только на представленных фактах1🔥19👍4🌚1🤨1
#random #LLM
Придумал еще один тип развлечения. Вам нужно простое советское... фото (ладно, можно любое фото). Берем эту фотку и просим СhatGPT написать типичный пост на двач, который бы сделал человек с таким фото.
Например, для этого фото получился такой пост
Я попросил еще придумать драматичную предысторию персонажа, вышло неплохо. Все не влезло в пост, я на телеграф закинул. Учитывая загадочно-мистический оттенок истории, я туда же закинул сгенерированный текст в формате отчета SCP.
В целом, весьма забавное развлечение на один вечер.
Придумал еще один тип развлечения. Вам нужно простое советское... фото (ладно, можно любое фото). Берем эту фотку и просим СhatGPT написать типичный пост на двач, который бы сделал человек с таким фото.
Например, для этого фото получился такой пост
Парни, это что за фигня с телефоном? Сидел спокойно, пью чай, тут звонит какая-то дичь, представляется как 'центральная диспетчерская времени', спрашивают, знаю ли я, который час. Уже третий раз за день. Что делать? Кто сталкивался?Я попросил еще придумать драматичную предысторию персонажа, вышло неплохо. Все не влезло в пост, я на телеграф закинул. Учитывая загадочно-мистический оттенок истории, я туда же закинул сгенерированный текст в формате отчета SCP.
В целом, весьма забавное развлечение на один вечер.
1❤14❤🔥3🥴2
#LLM
А вот про что забыл рассказать на прошлой неделе. У коллег из нашей команды вышла статья про то, как мы в команде строили инфраструктуру работы с LLM.
Тут все как обычно: читайте, ставьте плюсики, спрашивайте вопросы в комментариях к статье (если они у вас есть). Ну и узнавайте новое, конечно же!
А вот про что забыл рассказать на прошлой неделе. У коллег из нашей команды вышла статья про то, как мы в команде строили инфраструктуру работы с LLM.
Тут все как обычно: читайте, ставьте плюсики, спрашивайте вопросы в комментариях к статье (если они у вас есть). Ну и узнавайте новое, конечно же!
Хабр
Построение инфраструктуры для работы с языковыми моделями: опыт X5 Tech
Привет, Хабр! Я Мичил Егоров, руководитель команды разработки продуктов искусственного интеллекта в X5 Tech. В последнее время языковые модели (LLM) стали неотъемлемой частью многих...
❤4👍2
#ml #llm #random
Дал комментарий для статьи про ИИ-агентов. Компания для комментариев там подобралась весьма мощная, в таком списке приятно быть ;)
Материал интересный, если интересно понять общие концепты про ИИ-агентов. Если вы уже в теме, то много нового вряд ли увидите. В общем, прочитайте на досуге, если есть интерес и время.
Дал комментарий для статьи про ИИ-агентов. Компания для комментариев там подобралась весьма мощная, в таком списке приятно быть ;)
Материал интересный, если интересно понять общие концепты про ИИ-агентов. Если вы уже в теме, то много нового вряд ли увидите. В общем, прочитайте на досуге, если есть интерес и время.
5🔥6👍1🤣1
#llm #paper
Прочитал на досуге статью "Beyond Benchmarking: A New Paradigm for Evaluation and Assessment of Large Language Models".
Достаточно короткая статья. Идея тоже обычная, но хорошо, что ее явно вытащили и прописали, т.к. часто вроде у всех это крутится где-то на границе сознания, а вот когда явно кто-то написал или проговорил - все становится на свои места.
Итак, в чем смысл стать? Авторы рассматривают типичный процесс бенчмаркинга LLM, а именно засилие "тестов" в бенчмарках. Что неплохо, но просто дает ряд циферок, но не отражает всей сложности процесса оценки и проверки качества работы LLM.
Потому авторы предлагают трехступенчатый процесс оценки LLM (Benchmarking-Evaluation-Assessment), который сравнивают с медицинским осмотром. Получается такой подход:
1. Benchmarking. Его мы не откладываем в сторону, но считаем первым шагом. Условно, оцениваем какие-то базовые параметры (как на осмотре - давление померить, общий анализ крови сделать и вот это все). По факту смотрим, где есть проблемы;
2. Evaluation. На основе выявленных проблемных зон делаем более глубокие исследования (медицинский аналог - более сложное исследование выписывается, например, УЗИ);
3. Assessment. Пытаемся интерпретировать результаты детальных исследований с помощью "модели-доктора", вместе с которой разрабатывается "план лечения" (то есть, направления и шаги по исправлению проблем на прошлых шагах).
В итогу, много где так и работает, просто это формально не фиксировали в таком процессе. Так что заслуга авторов тут, как я сказал, именно в том, что вытащили общую идею на свет и формально описали.
Но, на самом деле, есть и вопросы к такому формату:
1. А заметим ли мы важные проблемы на первом этапе (вроде в анализах все ок, а челу все хуже и хуже)?
2. Как подобрать эти более предметные исследования? Ок, модель на чем-то не очень хорошо справляется, но как мне набрать данные, чтобы более детально понять проблемы в работе LLM.
3. А судьи кто? Ок, человек может что-то попробовать понять (но с интерпретацией могут быть вопросики), а если использовать именно "модель-доктора", то на чем ее учить и как понять, что она корректно предлагает решение?
Итог.
Хорошо, что написали, но пока выглядит больше "за все хорошее и против всего плохого". Надеюсь, что авторы накинут в будущих работах еще деталей по пунктам, может тогда будет полезнее.
Прочитал на досуге статью "Beyond Benchmarking: A New Paradigm for Evaluation and Assessment of Large Language Models".
Достаточно короткая статья. Идея тоже обычная, но хорошо, что ее явно вытащили и прописали, т.к. часто вроде у всех это крутится где-то на границе сознания, а вот когда явно кто-то написал или проговорил - все становится на свои места.
Итак, в чем смысл стать? Авторы рассматривают типичный процесс бенчмаркинга LLM, а именно засилие "тестов" в бенчмарках. Что неплохо, но просто дает ряд циферок, но не отражает всей сложности процесса оценки и проверки качества работы LLM.
Потому авторы предлагают трехступенчатый процесс оценки LLM (Benchmarking-Evaluation-Assessment), который сравнивают с медицинским осмотром. Получается такой подход:
1. Benchmarking. Его мы не откладываем в сторону, но считаем первым шагом. Условно, оцениваем какие-то базовые параметры (как на осмотре - давление померить, общий анализ крови сделать и вот это все). По факту смотрим, где есть проблемы;
2. Evaluation. На основе выявленных проблемных зон делаем более глубокие исследования (медицинский аналог - более сложное исследование выписывается, например, УЗИ);
3. Assessment. Пытаемся интерпретировать результаты детальных исследований с помощью "модели-доктора", вместе с которой разрабатывается "план лечения" (то есть, направления и шаги по исправлению проблем на прошлых шагах).
В итогу, много где так и работает, просто это формально не фиксировали в таком процессе. Так что заслуга авторов тут, как я сказал, именно в том, что вытащили общую идею на свет и формально описали.
Но, на самом деле, есть и вопросы к такому формату:
1. А заметим ли мы важные проблемы на первом этапе (вроде в анализах все ок, а челу все хуже и хуже)?
2. Как подобрать эти более предметные исследования? Ок, модель на чем-то не очень хорошо справляется, но как мне набрать данные, чтобы более детально понять проблемы в работе LLM.
3. А судьи кто? Ок, человек может что-то попробовать понять (но с интерпретацией могут быть вопросики), а если использовать именно "модель-доктора", то на чем ее учить и как понять, что она корректно предлагает решение?
Итог.
Хорошо, что написали, но пока выглядит больше "за все хорошее и против всего плохого". Надеюсь, что авторы накинут в будущих работах еще деталей по пунктам, может тогда будет полезнее.
🔥3