Kaggle intensive day 1 Prompt Engineering

Привет, завершим первый день интесива.

Вторая папира не такая плотная. Тут у нас про промпт-инжиниринг, рассказывают основные техники промптирования и важные параметры выхлопа моделей.

Ну про температуру вы точно знаете – чем выше температура, тем рандомнее будет ответ.

Че говоришь???

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

Чем выше температура – тем рандомнее мы будем выбирать эти токены, и наоборот – чем ниже температура, тем более детерминированным будет выхлоп на один и тот же промпт.

Детерминизм здесь – понятие с оговорками. ЛЛМ не может нам гарантировать аутентичный детерминизм, потому что даже с температурой, выкрученной в ноль, может быть предсказано больше одного токена с одинаковой вероятностью. Какой из них будет выбран, зависит от реализации tiebreaking в каждой конкретной модели и других параметров.

Что за другие параметры?

Top-K и Top-P параметры с пафосным названием nucleus sampling.

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

Top-P сэмплирование работает так – мы выбираем только те токены, чья общая (суммарная) вероятность не превышает параметр P. Логика такая же - 0 будет жадным декодированием, 1 – разрешаем все токены из словаря модели.

Температура применяется после top-k и top-p параметров.

Единого рецепта нет. Ну и не все модели все три настройки поддерживают, например, в OpenAI вроде как до сих пор нет top-k. Так что настраивается вся эта красота методом тыка.

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

Как отправную точку для экспериментов нам рекомендуют:

As a general starting point, a temperature of .2, top-P of .95, and top-K of 30 will give you relatively coherent results that can be creative but not excessively so. If you want especially creative results, try starting with a temperature of .9, top-P of .99, and top-K of 40. And if you want less creative results, try starting with a temperature of .1, top-P of .9, and top-K of 20. Finally, if your task always has a single correct answer (e.g., answering a math problem), start with a temperature of 0.

Про техники промптирования

Во-первых, одна из самых важных идей в документе – "документируйте все промпты и результаты!"

Это может показаться очень скучным и муторным, но вот то-то и оно! Помните по системной инженерии – собирать метрики всегда скучно :)

Если мы очень активно ведем разработку AI-систем, то лучше вести историю промптов хоть в каком-то виде и начать с какой-нибудь стабильной MVP версии. Логировать все промпты до этого – предприятие сомнительное... на худой конец, конечно, история гита есть. Но в истории сломаешься ковыряться. Гугл предлагает такой формат:

Выглядит неплохо, нужно еще поле с agent-name добавить, если компонентов много.

С подходами промптирования тоже бегом по базе:

• Zero-Shot - просто описываешь задачу и пуляешь в модель
• One-Shot - описываешь задачу и один хороший пример ожидаемого ответа
• Few-Shot - несколько примеров. Тут они пишут, что надо 3-5 примеров делать, а иногда и больше... Конкретики никакой, ну вы понимаете. Вот вам палец – тыкайте сюда.

Дальше про системный, контекстный и ролевой промптинг, и снова без особых деталей (разметка у моделей-то разная).

Роль – это когда "Ты супер полезный помощник по генерации гетеросексуальных и только гетеросексуальных романтических фанфиков" и так далее. Про контекст тоже не интересно – просто добавь воды.

Доставайте вашу джинжу и f-strings

А вот дальше чуток интереснее! Начинается "thEnKeng!" мой любимый.

Step-Back Prompting – это когда мы сначала задаем довольно общий вопрос и просим модель нам нагенерировать с температуркой около единицы хорошие варианты решений. А потом кормим результат в следующий уточняющий промпт.

Step-back промптинг происходит "автоматически", когда вы ведете вменяемый диалог с любым чатботом, поддерживающим историю диалога – мы задаем один общий вопрос, потом уточняющий и так далее. Но техника на этом не заканчивается конечно же, потому что в большинстве клиентов у нас нет возможности твикать температуру, ну и мы тут вообще про строительство АИ-систем в коде...

Далее – Chain of Thoughts. Тоже не ново – просим модель "think step by step".

Элементарный CoT – это действительно просто добавить в промпт – "ну подумай, пожалуйста, по порядку!!!11!!!!11 😭"

Такое мы называем Zero-shot CoT! Из чего следует, что можно делать One и Few Shots СoT, но если честно, меня этот подход пока совсем не прельщает, особенно там, где нужны точные цифры.

Помимо бОльшей сложности обеспечить тут какой-то детерминизм (в смысле доверия в сложном домене, температуры мы в CoT итак всегда ставим в ноль), другой минус в том, что любой CoT будет генерировать больше токенов на выход –> платим больше денег.

Следующий, еще более неэкономный метод – Self Consistency. Если в обычном CoT мы не хотим задирать температуру и целимся в "точные рассуждения" (greedy decoding), то в Self Consistency мы температуру вроде как чуток поднимаем и кидаем один и тот же промпт несколько раз, потом забираем средний, наиболее "популярный" в предсказании результат.

Tree of Thoughts – следующий виток безумия.

Вообще без особых подробностей. И это кажется очень странным – для чего упоминать ToT в контексте prompt engineering, но без примеров?

Ну хорошо, дали два папируса, раз, два.

Ответ на вопрос выше – сложно, надо писать много кода, и нормальными проприетарными наработками с вами делиться никто не будет. Посмотрите какой хайп все еще вокруг этого theNkEng.

Концептуально там внутри вроде как ничего сверх сложного - нужны промпты для генерации мыслей, оценки каждой "мысли" и выбора, который будет сравнивать несколько ветвей (и связанных узлов где мысль <-> ответ) в дереве и выбирать лучший.

Сложность в общем то с тем чтобы это вообще работало вменяемо 🤣

Ну хрен с ними, вот есть библиотека, до которой я обязательно скоро доберусь – у меня как минимум пару проектов есть на уме, где потенциально может пригодиться ToT. Как минимум проверим-поиграемся!

В остатке документа выдают скомканную чухню про проклятый ReAct, без упоминания того насколько агентские системы могут быть сложны в построении. Очень вкратце, ReAct – это когда у нас есть условный "цикл", в котором мы заставляем LLM генерировать "Мысль" о текущей задаче/ситуации, Действие – дерни эту API, вызови этот тул, и Наблюдение – реакцию на результат выполнения действия.

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

В целом это все, что интересно в доке (самое интересное и ценное - набор папирусов в конце :)