Личный покемон карманный, твой..
UPRISE: Universal Prompt Retrieval для улучшения оценки с нулевым результатом.
Предыстория. В целом я уже говорил, и всё ещё топлю за это, что будущее небольших команд состоит не в том, чтобы повторить успех OpenAI с instruct/chat GPT или GPT-4. А в том, чтобы делать свои прокси модельки которые улучшают выдачу с GPT-like.
В таком случае у вас останется лишь три пути:
1. Улучшить ретривер для in context (не забывайте RAG)
2. Улучшить ретривер для out context (помните о RETRO)
3. Делать прокси маленький декодер, который также может генерить более интересные инструкции ( да да инструктор будет улучшать инструктор) .
При этом, о каждом подходе и их миксте я уже рассуждал тут.
И вот теперь, ребятки из Microsoft выкатили как раз концепцию прокси тюнинга легкого ретривера. Который в zero-shot режиме может апать свои поисковые свойства, которые коррелируют с выхлопом LLM.
Как это происходит?
1. Используем датасет FLAN. Из него берём инструкции для каждой таски и создаём условные шаблоны: p+x, где X описание таски и Р затравка инструкции к ней.
2. Далее учим ретривер на contrastive таске сводить релевантные p и x (шаблоны и описания из одной таски) и разводить нерелевантные.
3. Обстукиваем это end2end об прокси "small" LM класса GPT-Neo-2.7B. Ведь мы уже умеем её запускать в инференс режиме даже наутюге вашей игровой пекарне.
4. При обращении к proxy LM мы закидываем в неё тройки : prompt, input task caption и label of task. Т.е. ретривер по входу таски Xi вытаскивает лучшую для описания таски затравку Pji, к таски знаем лейбл таски Yi и далее отправляет Хi+Рji в LM-ку с конкатенкцией условно через "\n". Сравниваем её Y(Xi+Pji) с реальным Yi.
5. Далее proxy LM возвращает оценку качества каждой таски с учётом такого инпута, а так же мы можем посчитать ошибку. Эта ошибка end2end передаётся в contrastive таску ретривера, заставляя его лучше искать пару к описанию таски.
В качестве базовой модели для ретривера берут модель класса BERT-base и обучают это в режиме bi-encoder. Учат всю эту красоту end2end на протяжении 3 эпох, ориентируясь на конечную точность поиска в этом пайпе.
Важно proxy GPT зафрижена и учится только ретривер!
Вопрос для чего нужна proxy-LM?
Всё просто - она помогает оценить "читаемость" и понимание decoder-like моделями таких шаблонов, а если уж "маленькая" GPT поняла, то и LLM тем более поймёт, что от неё хотят.
Какие плюшки получаем:
1. Быстрый тюн и трансфер знаний на мультитаске для ретривера.
2. Возможность через прокси LM оценивать понимания декодер like моделями таких шаблонов, которые порождает ретривер. Но тратить на это меньше времени и ресурсов, тк обе модели легче чем downstream.
3. Возможность отбросить прокси LM-ку и быть уверенным, что и на LLM наш ретривер не подведёт. По крайней мере, исследования в статье указывают на это.
Статья arxiv, код github
UPRISE: Universal Prompt Retrieval для улучшения оценки с нулевым результатом.
Предыстория. В целом я уже говорил, и всё ещё топлю за это, что будущее небольших команд состоит не в том, чтобы повторить успех OpenAI с instruct/chat GPT или GPT-4. А в том, чтобы делать свои прокси модельки которые улучшают выдачу с GPT-like.
В таком случае у вас останется лишь три пути:
1. Улучшить ретривер для in context (не забывайте RAG)
2. Улучшить ретривер для out context (помните о RETRO)
3. Делать прокси маленький декодер, который также может генерить более интересные инструкции ( да да инструктор будет улучшать инструктор) .
При этом, о каждом подходе и их миксте я уже рассуждал тут.
И вот теперь, ребятки из Microsoft выкатили как раз концепцию прокси тюнинга легкого ретривера. Который в zero-shot режиме может апать свои поисковые свойства, которые коррелируют с выхлопом LLM.
Как это происходит?
1. Используем датасет FLAN. Из него берём инструкции для каждой таски и создаём условные шаблоны: p+x, где X описание таски и Р затравка инструкции к ней.
2. Далее учим ретривер на contrastive таске сводить релевантные p и x (шаблоны и описания из одной таски) и разводить нерелевантные.
3. Обстукиваем это end2end об прокси "small" LM класса GPT-Neo-2.7B. Ведь мы уже умеем её запускать в инференс режиме даже на
4. При обращении к proxy LM мы закидываем в неё тройки : prompt, input task caption и label of task. Т.е. ретривер по входу таски Xi вытаскивает лучшую для описания таски затравку Pji, к таски знаем лейбл таски Yi и далее отправляет Хi+Рji в LM-ку с конкатенкцией условно через "\n". Сравниваем её Y(Xi+Pji) с реальным Yi.
5. Далее proxy LM возвращает оценку качества каждой таски с учётом такого инпута, а так же мы можем посчитать ошибку. Эта ошибка end2end передаётся в contrastive таску ретривера, заставляя его лучше искать пару к описанию таски.
В качестве базовой модели для ретривера берут модель класса BERT-base и обучают это в режиме bi-encoder. Учат всю эту красоту end2end на протяжении 3 эпох, ориентируясь на конечную точность поиска в этом пайпе.
Важно proxy GPT зафрижена и учится только ретривер!
Вопрос для чего нужна proxy-LM?
Всё просто - она помогает оценить "читаемость" и понимание decoder-like моделями таких шаблонов, а если уж "маленькая" GPT поняла, то и LLM тем более поймёт, что от неё хотят.
Какие плюшки получаем:
1. Быстрый тюн и трансфер знаний на мультитаске для ретривера.
2. Возможность через прокси LM оценивать понимания декодер like моделями таких шаблонов, которые порождает ретривер. Но тратить на это меньше времени и ресурсов, тк обе модели легче чем downstream.
3. Возможность отбросить прокси LM-ку и быть уверенным, что и на LLM наш ретривер не подведёт. По крайней мере, исследования в статье указывают на это.
Статья arxiv, код github