Перемещение больших языковых моделей (LLM) в реальные бизнес-приложения

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

Большие языковые модели и основные сильные стороны

LLM хорошо подходят для понимания языка, это их сильная сторона. Наиболее распространенная закономерность, которую мы наблюдаем в приложениях, – это генерация с помощью внешних данных (RAG), когда знания компилируются из внешних источников и предоставляются в контексте как подсказка для LLM, чтобы сформулировать ответ. В этом случае сверхбыстрые механизмы поиска, такие как векторные базы данных и движки на основе Elasticsearch, служат первой линией поиска. Затем результаты поиска компилируются в подсказку и отправляются в LLM, в основном как вызов API.

Другой закономерностью является генерация запроса на структурированные данные путем подачи LLM данных модели как подсказки и конкретного запроса пользователя. Эта закономерность может быть использована для разработки продвинутого интерфейса “говори со своими данными” для SQL-баз данных, таких как Snowflake, а также для графических баз данных, таких как Neo4j.

Использование закономерностей LLM для реальных прозрений

Компания Persistent Systems недавно рассмотрела закономерность для Blast Motion, компании спортивной телеметрии (анализ ударов в бейсболе, гольфе и т. д.), где мы проанализировали временные ряды данных об игроках, чтобы получить рекомендации.

Для более сложных приложений нам часто необходимо объединять запросы LLM с обработкой между вызовами. Для фармацевтической компании мы разработали умное приложение для фильтрации пациентов для клинических испытаний на основе критериев, извлеченных из документов клинических испытаний. Здесь мы использовали подход с цепочкой LLM. Сначала мы разработали LLM для чтения документов испытаний и использования закономерности RAG для извлечения критериев включения и исключения.

Для этого был использован относительно простой LLM, такой как GPT-3.5-Turbo (ChatGPT). Затем мы объединили эти извлеченные сущности с моделью данных базы данных пациентов SQL в Snowflake, чтобы создать подсказку. Эта подсказка была подана в более мощный LLM, такой как GPT4, который дал нам запрос SQL для фильтрации пациентов, готовый к запуску на Snowflake. Поскольку мы используем цепочку LLM, мы можем использовать несколько LLM для каждого шага цепочки, что позволяет нам управлять затратами.

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

Возможность более продвинутых случаев использования

Для более продвинутого случая мы могли бы использовать агенты, такие как ReAct, чтобы подсказать LLM создать пошаговые инструкции для конкретного запроса пользователя. Это, конечно, потребовало бы высококлассный LLM, такой как GPT4 или Cohere, или Claude 2. Однако, тогда существует риск того, что модель совершит неправильный шаг, который потребует проверки с помощью ограничений. Это компромисс между передачей интеллекта в управляемые звенья цепочки или созданием всей цепочки автономной.

Сегодня, когда мы привыкаем к эпохе генеративного ИИ для языка, отрасль начинает принимать приложения LLM с предсказуемыми цепочками. По мере роста этого принятия мы скоро начнем экспериментировать с большей автономией для этих цепочек посредством агентов. Это то, о чем идет дискуссия об AGI, и мы заинтересованы в том, чтобы увидеть, как все это будет развиваться со временем.