Приготовление специализированного зелья LLM для определенной области

Специализированное зелье LLM для области.

 

Артур Кларк знаменито заметил, что любая достаточно сложная технология неотличима от магии. Искусственный интеллект перешел эту черту с появлением моделей Vision and Language (V&L) и языковых моделей обучения (LLMs). Проекты, такие как Promptbase, на самом деле сплетают правильные слова в правильной последовательности, чтобы вызвать видимо случайные результаты. Если “инженерия запросов” не отвечает критериям колдовства, трудно сказать, что это. Кроме того, важно качество запросов. Лучшие “заклинания” приводят к лучшим результатам!

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

Давайте отправимся в путешествие, раскрывая рецепт создания мощного зелья – LLM с определенной областью знаний. В качестве интересного примера мы разработаем LLM, владеющую навыками в Civilization 6, концепции, которая достаточно гиковская, чтобы нас заинтриговать, обладает фантастическим WikiFandom под лицензией CC-BY-SA и не является слишком сложной, чтобы даже не фанаты могли следовать нашим примерам.

• Революционизация реального времени синтеза новых видов 1080p прорыв с помощью 3D-гауссиан и видимостно-ориентированной отрисовки
• Использование XGBoost для прогнозирования временных рядов
• «Together AI представляет Llama-2-7B-32K-Instruct прорыв в обработке языка с расширенным контекстом»

 

Шаг 1: Разберитесь с документацией

 

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

 

Шаг 2: Разделите свои запросы

 

Чтобы сделать ваше областное знание доступным для LLM, разделите свою документацию на более мелкие, усвояемые части. Это разделение улучшает понимание и облегчает поиск соответствующей информации. Для нас это означает разделение файлов разметки Fandom Wiki на секции. Разные LLM могут обрабатывать запросы разной длины. Разумно разделить ваши документы на части, которые будут значительно короче (скажем, на 10% или меньше) максимальной длины ввода LLM.

 

Шаг 3: Создайте знание эликсиров и варите ваш векторный базу данных

 

Кодируйте каждый разделенный текстовый элемент с соответствующим вложением, используя, например, Sentence Transformers.

Сохраните полученные вложения и соответствующие тексты в векторной базе данных. Вы можете сделать это самостоятельно, используя Numpy и KNN из SKlearn, но опытные практики часто рекомендуют использовать векторные базы данных.

 

Шаг 4: Создайте завораживающие запросы

 

Когда пользователь задает LLM вопрос о Civilization 6, вы можете искать векторную базу данных элементов, вложение которых близко соответствует вложению вопроса. Вы можете использовать эти тексты в создаваемом вами запросе.

 

Шаг 5: Управляйте котлом контекста

 

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

 

Шаг 6: Выберите свой магический ингредиент

 

Независимо от выбранного LLM для вашего конечного решения, эти шаги применимы. Мир LLM меняется быстро, поэтому, когда ваша конвейерная система готова, выберите свою метрику успеха и проведите параллельные сравнения разных моделей. Например, мы можем сравнить Vicuna-13b и GPT-3.5-turbo.

 

Шаг 7: Проверьте свое зелье

 

Тестирование работоспособности нашего “зелья” – следующий шаг. Легче сказать, чем сделать, так как нет научного согласия относительно оценки LLM. Некоторые исследователи разрабатывают новые бенчмарки, такие как HELM или BIG-bench, в то время как другие пропагандируют оценку с участием человека или оценку вывода модели с превосходной моделью для областного LLM. Каждый подход имеет свои плюсы и минусы. Для проблемы, связанной с областным знанием, вам необходимо создать оценочный конвейер, соответствующий вашим деловым потребностям. К сожалению, это обычно требует начать с нуля.

 

Шаг 8: Раскрыть оракула и вызвать ответы и оценку

 

Сначала соберите набор вопросов для оценки производительности специализированной модели языковой модели. Это может быть трудной задачей, но в нашем примере Civilization мы использовали Google Suggest. Мы использовали поисковые запросы вроде “Civilization 6 как …” и использовали предложения Google в качестве вопросов для оценки нашего решения. Затем, имея набор вопросов, связанных с предметной областью, запустите вашу систему вопрос-ответ. Сформируйте запрос и сгенерируйте ответ для каждого вопроса.

 

Шаг 9: Оценка качества через глаза пророка

 

После получения ответов и исходных запросов необходимо оценить их соответствие. В зависимости от желаемой точности, вы можете сравнить ответы вашей специализированной модели языковой модели с более качественной моделью или использовать сравнение в режиме “рядом”. Второй вариант имеет преимущество прямой оценки человеком, что, при правильном выполнении, защищает от неявного предвзятости, которую может иметь более качественная модель языковой модели (например, GPT-4, которая склонна оценивать свои ответы выше, чем люди). Это может быть важно для реальной бизнес-реализации, где такая неявная предвзятость может негативно сказаться на продукте. Поскольку мы имеем дело с игрушечным примером, мы можем следовать первому пути: сравнивать ответы Vicuna-13b и GPT-3.5-turbo с ответами GPT-4.

 

Шаг 10: Улучшение оценки качества

 

Специализированные модели языковых моделей часто используются в открытых средах, поэтому идеально, чтобы модель языковой модели могла отличать вопросы с ответами из вашей векторной базы данных от вопросов без ответов. Вот сравнение Vicuna-13b и GPT-3.5, оцененное людьми на Toloka (также известной как Tolokers) и GPT.

Метод	Tolokers	GPT-4
Модель	vicuna-13b	GPT-3.5
Вопросы с ответами, правильный ответ	46,3%	60,3%	80,9%
Вопросы без ответов, ИИ не дал ответа	20,9%	11,8%	17,7%
Вопросы с ответами, неправильный ответ	20,9%	20,6%	1,4%
Вопросы без ответов, ИИ дал какой-то ответ	11,9%	7,3%	0

 

Мы можем увидеть различия между оценками, проведенными более качественными моделями, и оценкой, проведенной людьми, если рассмотрим оценку Vicuna-13b Tolokers, как показано в первом столбце. Из этого сравнения вытекают несколько ключевых выводов. Во-первых, заметны расхождения между GPT-4 и Tolokers. Эти несоответствия в основном возникают, когда специализированная модель языковой модели правильно не отвечает, но GPT-4 оценивает такие отсутствующие ответы как правильные ответы на вопросы, на которые можно ответить. Это подчеркивает потенциальное искажение при оценке, которое может возникнуть, когда оценка модели языковой модели не сопоставляется с оценкой человека.

Во-вторых, как GPT-4, так и оценщики-люди демонстрируют согласие при оценке общей производительности. Это рассчитывается как сумма чисел в первых двух строках, сравниваемая с суммой в последних двух строках. Таким образом, сравнение двух специализированных моделей языковых моделей с более качественной моделью может быть эффективным DIY-подходом к предварительной оценке модели.

И вот у вас есть это! Вы овладели заклинательством, и ваша специализированная трубопроводная система LLM полностью функциональна. Иван Ямщиков является профессором по обработке семантических данных и когнитивным вычислениям в Центре искусственного интеллекта и робототехники Технического университета прикладных наук Вюрцбург-Швайнфурт. Он также руководит командой Data Advocates в Toloka AI. Его научные интересы включают вычислительное творчество, обработку семантических данных и генеративные модели.