Post #45

A Survey of Techniques for Maximizing LLM Performance Вчера OpenAI выложил 5 лекций с DevDay. Каждая по-своему интересна, но сегодня разбираем только одну из них — A Survey of Techniques for Maximizing LLM Performance. Авторы предлагают некоторый фреймворк, с которым можно подходить к решению задач: Prompt Engineering → {Retrieval Augmented Generation, Fine-Tuning} → All of the above. Выбор зависит от условий задачи: нужно ли регулярно обновлять знания у модели, насколько хорошо модель работает в конкретной области, сложные ли у нас инструкции и тд. Далее по каждому методу делятся мыслями, как его применять. — Prompt Engineering. Ничего в целом нового, еще раз подчеркивают, что нужно составлять промпт с четким описанием задачи, разбивать ее на более мелкие подзадачи, добавлять примеры ответов в качестве референса (few shot) и регулярно итерироваться по разным версиям промптов, чтобы находить лучшие варианты. Самое главное, что здесь у нас появляется бейзлайн, относительно которого мы можем сравнивать наши будущие, более сложные версии. — Retrieval Augmented Generation (RAG). Очень популярный сейчас подход по поиску релевантной информации во внешнем хранилище, которая потом помещается в промпт для финальной генерации. Таким образом модель борется с галлюцинациями и может иметь доступ к последней актуальной информации. Однако, простой поиск по эмбеддингам дал на бенчмарке всего 45% Accuracy. Далее цепочка улучшений: - Chunk/embedding experiments. Эксперименты по разбиению документа на блоки разного размера, чтобы легче можно было найти нужную информацию. - Reranking. После поиска добавляем стадию ранжирования через кросс-энкодер (то есть смотрим сразу на пару запрос-документ и даем оценку релевантности), в результате чего у нас больше шанс выбрать топ самых подходящих документов. - Classification step. Дополнительно определяем домен документа, чтобы на этапе ранжирования подать метаданные, зависящие от этого домена. - Prompt Engineering. Тюним промпт после всех предыдущих улучшений. - Tool Use. Для вопросов, где был большой процент ошибок, получилось добавить некоторые внешние инструменты по типу запросов в БД через SQL и извлечение полностью структурированной информации. - Query Expansion. Популярный метод из поиска в целом. Помимо основного запроса мы можем составлять альтернативные (например, с помощью переформулировок), параллельно искать документы для всех и в конце склеивать их в один контекст. Что не сработало: - HyDE (Hypothetical Document Embeddings) retrieval. Вместо пользовательского запроса мы сначала генерируем потенциальный ответ и уже по нему ищем в базе документов. Таким образом, запрос получается больше похожим на множество документов в базе. В каких-то приложениях это работает хорошо, но для их бенчмарка прироста не было. - Fine-Tune embeddings. Файнтюнить эмбеддинги специально для RAG неплохо работало с точки зрения Accuracy, но было слишком долго и дорого. Также ребята упомянули способ оценки RAG систем с помощью 4 метрик: Faithfulness, Answer Relevancy, Context Precision, Context Recall. — Fine-Tuning. Этап намного тяжелее, чем предыдущие два, поэтому сюда нужно идти только в том случае, если уверены, что файнтюнинг нужен. Обычно хорошо работает, если мы хотим дотюнить под конкретные инструкции или формат выдачи. В таком случае мы сможем сократить размер изначального промпта и увеличить скорость работы модели. Про сами же подходы к тюнингу ничего конкретного не сказали. Но аккуратно, а то можно получить интересные артефакты 😅 После файнтюна на сообщения Slack получился интересный ассистент: User: Write a 500 word blog post on prompt engineering. Assistant: Sure, I shall work on that in the morning. User: Write it now. Assistant: Ok.