Перевод статьи GPT for People Analytics: Four concepts you need to know 

Автор Андрю Марритт, один из лучших аналитиков в HR, кого я знаю

GPT для People Analytics: четыре концепции, которые вам нужно знать

Использование GPT или больших языковых моделей (LLM) для проектов People Analytics является привлекательным вариантом, особенно для прототипов решений. Однако, чтобы получить максимальную отдачу от LLM всех типов, стоит понять несколько ключевых концепций.

Что такое LLM?

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

4 ключевые концепции

По нашему опыту, лучший способ использовать LLM в контексте типичной проблемы People Analytics — это разложить проблему на небольшие отдельные компоненты, а затем объединить модели в цепочку. Таким образом, вместо того, чтобы пытаться решить всю проблему на одном большом этапе, вы пытаетесь решить очень сфокусированные, более мелкие проблемы.

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

1. Подсказка / Prompting
2. Контекстные окна / Context Windows
3. Тонкая настройка / Fine Tuning
4. Вложения / Embeddings

Подсказка

Подсказка — это то, как вы взаимодействуете с LLM. Это искусство и мастерство создания объяснений того, что вы хотите, чтобы модель делала, и чего вы не хотите, чтобы она делала.

Что так привлекательно в LLM, так это то, что вы создаете эти подсказки, используя естественный язык. Хотя это резко увеличивает доступность использования LLM, это может создать ложное ощущение легкости — вы очень быстро получите достойный результат. Однако со временем, практикой и обучением вы можете значительно улучшить свои подсказки.

Мы думаем о подсказках как о «n выстрелах». Например, подсказка вопрос-ответ, которую мы все, вероятно, использовали в качестве первой подсказки в LLM, не имеет примеров. Мы называем это «нулевой подсказкой». Отсюда мы переходим к «одноразовой подсказке», где приводится пример, а затем к «несколько подсказок». Теоретически количество примеров, которые вы предоставляете, не ограничено, хотя мы видим уменьшение предельного значения по мере использования большего количества примеров. [Стоит взглянуть на мою предыдущую статью о тренировочных наборах, так как я считаю, что применимы те же критерии.]

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

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

Есть несколько хороших практик, которые мы изучили для создания хороших подсказок:

• подсказки должны быть краткими
• подсказки должны быть конкретными и иметь четкое определение
• разбивать (декомпозировать) сложные подсказки на ряд простых подсказок «одной задачи»
• Задайте задачу классификации вместо того, чтобы задавать генеративные задачи
• Добавьте в приглашение примеры того, что вы хотите вернуть.

В конечном счете, лучший способ найти хорошую подсказку — это экспериментировать.

Контекстные окна

Для многих задач People Analytics вам понадобится создать подсказку, в которой вы замените части подсказки данными из вашего набора данных. Таким образом, длина вашей подсказки (которая часто является ключевым фактором в том, как поставщик API взимает с вас плату) должна включать текст запроса и длину данных.

Как вы можете себе представить, когда вы начнете комбинировать подсказку большой длины (четко определенную, с несколькими примерами) с набором данных, которые вы хотите «запросить», вы быстро увидите, что длина подсказки становится большой.

На данный момент (23 июня) одной из ключевых областей конкуренции для компаний, предоставляющих LLM, является продолжительность запроса, которую может принять каждая модель. Обычная длина на данный момент составляет 2000 токенов, но доступны модели, которые могут обрабатывать 100 000 токенов.

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

Тонкая настройка

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

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

#темы * #примеров по теме

Мы считаем, что минимальное количество примеров для каждой темы — 100. В нашей текущей «базовой» модели у нас 260 тем. Вы можете видеть, как предоставление этого для каждой подсказки (вы, вероятно, захотите вызывать API один раз для каждого предоставленного ответа) приводит к большому набору очень больших подсказок, т. е. вызов потенциально тысячи раз будет очень дорогим. (Вы также можете столкнуться с ограничениями контекстного окна).

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

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

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

Вложения

С тех пор как мы начали фокусироваться на анализе текста в People Analytics около 8 лет назад, большинство наших моделей и подходов были основаны на встраиваниях. Ранние модели (Word2Vec, Glove, FastText….) создавали вложения слов (или их частей). По мере улучшения текстовых моделей — от ранних моделей преобразования до LLM — точность вложений повысилась, и вложения начали включать все более и более длинные контексты.

Что такое вложение? Проще говоря, это многомерные координаты карты, которые «помещают» каждый встроенный элемент (слово, предложение, полный текст…) в определенную позицию. Они обладают определенными полезными свойствами. Семантически похожие слова (или более длинные тексты) имеют встроенные «координаты», которые помещают их близко друг к другу. Направление, которое ведет вас от слова А к слову Б, обеспечивает смысл.

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

В то время как более ранние вложения имели около 300 измерений, вложения LLM часто имеют большую величину. Если вы имеете дело с небольшим количеством вложений, вы можете найти ближайшего соседа в памяти. Когда вы начнете работать с большими наборами данных, вы можете захотеть использовать базы данных, предназначенные для хранения вложений и поиска ближайших соседей — так называемые векторные базы данных.

Резюме

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

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

LLM обеспечивают очень простую отправную точку для анализа текста. В зависимости от ряда факторов вы можете или не можете получить модель, которая соответствует вашим потребностям. Перевернув известное выражение — «если все, что у вас есть, — это LLM, каждая проблема выглядит как задача LLM». Реальность такова, что сообщество текстового анализа не прекратило работу над решениями, не относящимися к LLM. По сути, все они в настоящее время являются общими моделями, и модели для конкретных задач все еще могут их превзойти.