О практической пользе LLM, агентах и генерациях в структурированной формеПока что, из-за всеобщего хайпа LLM, очень редкие поставщики языковых моделей задумываются о том, как имено их творения будут использоваться на практике, можно ли с помощью их моделей,
автоматизировать реальные задачи и можно ли их сформулировать на человеческом языке так, чтобы модель их поняла. На мой взгляд, реальная ситуация такова, что из крупных компаний,
только OpenAI делал серьезные шаги, в будущее LLM -
Function Calling,
впервые представив его в моделях верссии 0613, в середине 2023 года, тем самым сделав возможным появление
LLM-агентов.
Не так давно, стало возникать большое количество публикаций и опен-сорс проектов на эту тему (Toolformer, ReACT,
guidance и тд). Согласно текущему, общепризнаному определению, для LLM агента характерно следующее:
1) Преобразование входящего запроса юзера, обычно, на несколько мелких
2) Наличие набора внешних "инструментов", условные внешние API вроде погоды, к которым модель умеет обращаться сама при надобности
3) Планирование выполнения запроса используя тулы (например, узнал адресс по координатам -> узнал погоду)
4) Наличие памяти о произошедшем общении, умение вести диалог.
К слову, RAG (Retrieval-Augmented Generation) так же является узкой формой агента - у него есть tool, который позволяет ему использовать внешнюю базу знаний.
Зачем все это нужно и почему это так важно? Представим, что мы живем в 21 веке и хотим построить ассистента с интентами, который умеет обращаться с некоторыми API. Обычным подходом, который практиковал все это время Яндекс в Алисе, Сбер и прочие, было бы использовать отдельный intent-классификатор, всякие пайплайны с NER, кучи пост и предобраток, все это с использованием 10+ разных NLP моделей, а качество всеравно было не очень. Сейчас же, имея мощных языковых агентов - LLM, мы, условно, можем попросить LLM сделать за нас классификацию интентов,
просто описав их словами, и в случае нужного, сходить в опреденный REST API,
сгенерировав запрос самостоятельно. Все что тут нужно - это уметь
парсить такие ответы и предоставлять модели информацию о структуре данных на входе. Это коллосальный потенциал для эффективной автоматизации многих процессов в бизнесе.
Почитать подробнее о том, как сейчас работают со структурироваными входами/выходами в фреймворке LlamaIndex, можно
тут, там еще и иллюстрации со схемой есть.
Наверное, у вас возникает вопрос -
в чем же сейчас проблема? К сожалению, многие появляющиеся модели, не обучены работать со структурированной информацией, их структурированым генерациям сложно доверять, так как они часто ошибаются, неверно интерпретируют описания инструментов, по сути единственными достаточно мощными LLM для агентного подхода являются GPT-3.5 и GPT-4.
Чтобы исправить эту ситуацию, несколько дней назад, LLMWare
выложила в опенсорс семейство SLIM -
Structured Language Instruction Models, моделей размером в 1B, специально зафайнтьюненых для генерации ответа в виде
питоновских словарей,
JSON и
SQL, их модели дообучены генерировать валидные SQL запросы, делать интент-классификацию, извлекать тэги и все это в машинно-читаемом формате. Но сами модели, на мой взгляд получились весьма ограниченными в применении.
Если вам интересно больше почитать о том, что из себя представляют агенты и бенчмарках использования инструментов, то вот список свежих материалов:
-
ControlLLM: Augment Language Models with Tools by Searching on Graphs (Paper)
-
AppAgent: Multimodal Agents as Smartphone Users (Paper)
-
Benchmarking Agent Tool Use (Langchain Blog)
-
API-Bank: Benchmarking Language Models’ Tool Use (Blogpost)
-
OpenAI Assistant Agent Tutorial (LlamaIndex Tutotrial)
