Практическое руководство по оперативному проектированию, структурированным выводам, вызову инструментов и защитным барьерам для реальных приложений LLM.
Делиться
Самые известные примеры применения степеней магистра права (LLM) — это те, которые я люблю называть « степенями магистра права с вау-эффектом ». О них есть множество вирусных постов на LinkedIn, и все они звучат примерно так:
«Я построил [x], который делает [y] за [z] минут, используя ИИ».
Где:
- [x] обычно представляет собой что-то вроде веб-приложения/платформы
- [y] — довольно впечатляющая главная особенность [x]
- [z] обычно представляет собой целое число от 5 до 10.
- «ИИ» на самом деле, в большинстве случаев, представляет собой оболочку LLM (Cursor, Codex или что-то подобное)
Если вы внимательно обратите внимание, акцент в этом предложении делается не на качестве анализа, а на количестве сэкономленного времени. Это означает, что, работая над задачей, люди не в восторге от качества результатов LLM, но рады, что LLM быстро выдаёт что-то, что может показаться решением их проблемы.
Вот почему я называю их «вау-эффектными» магистерскими программами магистратуры (LLM) . Какими бы впечатляющими они ни были, эти магистерские программы магистратуры магистратуры (LLM) имеют ряд недостатков, которые мешают их внедрению в производственную среду. Вот некоторые из них:
- Подсказка обычно не оптимизирована : у вас нет времени протестировать все различные версии подсказок, оценить их и предоставить примеры за 5–10 минут.
- Они не рассчитаны на долгосрочную устойчивость : за это короткое время можно разработать красивую оболочку, готовую к использованию. По умолчанию вы игнорируете все вопросы стоимости, задержки, удобства поддержки и конфиденциальности.
- Им обычно не хватает контекста : LLM обладают силой, когда подключены к крупной инфраструктуре, имеют право принимать решения относительно используемых инструментов и располагают контекстными данными для дополнения своих ответов. Нет никаких шансов реализовать это за 10 минут.
Не поймите меня неправильно: программы магистратуры права (LLM) разработаны таким образом, чтобы быть интуитивно понятными и простыми в использовании. Это означает, что развитие LLM от уровня «вау-эффекта» до уровня производства — не высшая математика. Однако это требует определённой методологии, которую необходимо реализовать.
Целью этой записи в блоге является предоставление этой методологии.
Ниже перечислены моменты, которые мы рассмотрим для перехода от ошеломляющих LLM к LLM производственного уровня:
- Системные требования LLM . Когда этот проект будет запущен в эксплуатацию, нам нужно знать, как его поддерживать. Это делается на нулевом этапе, путём адекватного анализа системных требований.
- Проектирование подсказок . Мы оптимизируем структуру подсказок и предложим несколько передовых стратегий.
- Структурируйте данные с помощью схем и структурированного вывода . Мы перейдём от свободного текста к структурированным объектам, чтобы формат вашего ответа был фиксированным и надёжным.
- Используйте инструменты, чтобы LLM не работала изолированно . Мы позволим модели подключаться к данным и вызывать функции. Это даёт более содержательные ответы и уменьшает количество галлюцинаций.
- Добавьте ограничения и проверки для модели . Проверяйте входные и выходные данные, обеспечивайте соблюдение бизнес-правил и определяйте, что происходит, если модель дает сбой или выходит за пределы допустимого.
- Объедините всё в простой, проверяемый конвейер . Организуйте подсказки, инструменты, структурированные результаты и ограничения в единый поток, который можно регистрировать, отслеживать и улучшать с течением времени.
Мы рассмотрим очень простой пример: мы хотим, чтобы LLM судил тесты для специалистов по анализу данных. Это лишь конкретный пример, чтобы избежать излишней абстрактности и путаницы в статье. Процедура достаточно общая, чтобы её можно было адаптировать к другим требованиям LLM, обычно с минимальными изменениями.
Похоже, нам предстоит многое сделать. Давайте начнём!
Весь код и данные можно найти здесь.
Сложный выбор: стоимость, задержка, конфиденциальность
Прежде чем писать код, следует задать себе несколько важных вопросов:
- Насколько сложна ваша задача?
Вам действительно нужна последняя и самая дорогая модель или можно использовать модель поменьше или более старшую? - Как часто вы это запускаете и с какой задержкой?
Это веб-приложение, которое должно реагировать по запросу, или пакетное задание, которое выполняется один раз и сохраняет результаты? Ожидают ли пользователи немедленного ответа или приемлемо просто «мы напишем вам позже»? - Какой у вас бюджет?
У вас должно быть примерное представление о том, сколько денег можно потратить. Это 1000, 10000, 100000? И по сравнению с этим, имеет ли смысл обучать и размещать собственную модель, или это явно перебор? - Каковы ваши ограничения конфиденциальности?
Можно ли отправлять эти данные через внешний API? Видит ли LLM конфиденциальные данные? Одобрено ли это ответственным за юридические вопросы и соответствие требованиям?
Позвольте мне привести несколько примеров. Если говорить о OpenAI, то вот таблица цен:
Для простых задач, где бюджет ограничен и требуется низкая задержка, обычно лучше всего подойдут модели меньшего размера (например, семейство 4.x mini или 5 nano). Они оптимизированы по скорости и цене, и для многих базовых задач, таких как классификация, маркировка, преобразование света или простые помощники, вы практически не заметите разницы в качестве, заплатив при этом лишь малую часть стоимости.
Для более сложных задач, таких как генерация сложного кода, анализ контекста в длительной перспективе или высокоуровневые оценки, может быть целесообразно использовать более мощную модель из семейства 5.x, даже при более высокой стоимости за токен. В таких случаях вы явно жертвуете деньгами и задержкой ради повышения качества решений.
Если вы выполняете большие офлайн-нагрузки, например, переоцениваете или переоцениваете тысячи объектов за ночь, пакетные конечные точки могут значительно снизить затраты по сравнению с вызовами в режиме реального времени. Это часто влияет на выбор модели, которая подходит вашему бюджету, поскольку вы можете позволить себе более «крупную» модель, когда задержка не является ограничением.
С точки зрения конфиденциальности, рекомендуется отправлять своему провайдеру только неконфиденциальные или «очищенные от конфиденциальной информации» данные, то есть данные, очищенные от всего конфиденциального или личного. Если вам нужен ещё больший контроль, вы можете рассмотреть возможность использования локальных программ LLM.
Конкретный вариант использования
В этой статье мы разрабатываем автоматизированную систему оценки экзаменов по науке о данных . Студенты сдают тест, требующий анализа реальных наборов данных и ответов на вопросы на основе полученных результатов. Задача магистра права (LLM) — оценить эти работы по следующим параметрам:
- Понимание того, о чем идет речь в каждом вопросе
- Доступ к правильным ответам и критериям оценки
- Проверка расчетов студентов на соответствие фактическим данным
- Предоставление подробной обратной связи о том, что пошло не так
Это прекрасный пример того, почему LLM нужны инструменты и контекст. Видите ли, действительно можно использовать подход «plug-and-play». Если бы мы реализовали простую DS с помощью одного запроса и вызова API, это произвело бы ошеломляющий эффект, но в рабочей среде это было бы неэффективно. Без доступа к наборам данных и критериям оценки LLM не может выставлять точные оценки. Для проверки правильности ответа студента ему необходимо получить фактические данные.
Наш экзамен хранится в файле test.json и содержит 10 вопросов в трёх разделах. Студентам необходимо проанализировать три различных набора данных: данные о продажах в электронной коммерции, демографические данные клиентов и результаты A/B-тестирования. Рассмотрим несколько примеров вопросов:
Как видите, вопросы связаны с данными , поэтому магистрам права понадобится инструмент для их анализа. Мы ещё вернёмся к этому.
Создание подсказки
Когда я использую ChatGPT для решения небольших ежедневных вопросов, я ужасно ленив и совершенно не обращаю внимания на качество ответа, и это нормально. Представьте, что вам нужно узнать текущую ситуацию на рынке жилья в вашем городе, и вам приходится садиться за ноутбук и писать тысячи строк кода на Python. Не очень-то привлекательно, правда?
Однако чтобы получить действительно наилучшее предложение для вашего заявления на получение степени LLM производственного уровня, необходимо соблюдать несколько ключевых моментов:
- Четкое определение роли . КТО такой магистр права и КАКОЙ специализацией он обладает.
- Системные и пользовательские сообщения . Системные сообщения — это инструкции, специфичные для LLM. «Пользователь» представляет собой конкретное приглашение к выполнению, соответствующее текущему запросу пользователя.
- Явные правила с цепочкой мыслей . Это список шагов, которые должен выполнить магистр права для выполнения задания. Эти пошаговые рассуждения запускают цепочку мыслей, что повышает производительность и уменьшает галлюцинации.
- Примеры с небольшим количеством примеров . Это список примеров, наглядно показывающих, как LLM должен выполнять задание. Покажите примеры правильной оценки LLM.
Обычно рекомендуется создать файл prompt.py с параметрами SYSTEM_PROMPT, USER_PROMPT_TEMPLATE и FEW_SHOT_EXAMPLES. Вот пример для нашего варианта использования:
Таким образом, подсказки, которые мы будем использовать повторно, хранятся как константы, а те, которые изменяются в зависимости от ответа учащегося, извлекаются из get_grading_prompt.
Форматирование вывода
Если вы заметили, вывод в примере с несколькими кадрами уже имеет некую «структуру». В конечном счёте, саундтрек должен быть «упакован» в формат, подходящий для производства. Недопустимо, чтобы вывод был представлен в виде свободного текста или строки.
Для этого мы воспользуемся магическим Pydantic . Pydantic позволяет легко создать схему, которую затем можно передать в LLM, который сформирует вывод на основе этой схемы.
Это наш файл schemas.py:
Если вы сосредоточитесь на GradingResult, то увидите, что у вас есть следующие типы функций:
question_number: int = Field(…, ge=1, le=10, description=»Номер вопроса (1-10)») points_earned: float = Field(…, ge=0, le=10, description=»Начисленные баллы из 10″) points_possible: int = Field(default=10, description=»Максимум баллов за этот вопрос»)
Теперь представьте, что мы хотим добавить новую функцию (например, полноту_ответа). Это очень просто: достаточно добавить её в схему. Однако имейте в виду , что приглашение должно отражать то, как будет выглядеть ваш вывод.
Описание инструментов
В папке /data находятся:
- Список наборов данных , которые будут темой наших вопросов (например, Рассчитайте среднюю стоимость заказа (AOV) для клиентов, использовавших промокод «SAVE20». Какой процент от общего числа заказов был использован с этим промокодом? В этой папке находится набор таблиц, представляющих данные, которые студенты должны проанализировать при прохождении тестов.
- Набор данных рубрик оценки , который описывает, как мы будем оценивать каждый вопрос.
- Набор данных , содержащий истинные ответы на каждый вопрос.
Мы собираемся предоставить LLM полную свободу действий в этих наборах данных; мы позволяем ему исследовать каждый файл на основе конкретного вопроса.
Например, get_ground_truth_answer() позволяет LLM извлечь основную истину для заданного вопроса. query_dataset () позволяет выполнять некоторые операции с LLM, такие как вычисление среднего значения, максимального значения и количества.
Даже в этом случае стоит отметить, что инструменты, схема и подсказка полностью настраиваемы . Если ваш LLM имеет доступ к 10 инструментам, и вам нужно добавить ещё одну функцию, нет необходимости вносить структурные изменения в код: достаточно добавить функциональность в виде подсказки, схемы и инструмента.
Описание ограждений
В программной инженерии хорошую систему можно определить по тому, насколько корректно она сбоит. Это показывает объём работы, вложенной в решение задачи.
В этом случае некоторые «грациозные падения» таковы:
- Входные данные должны быть очищены : идентификатор вопроса должен существовать, текст ответа учащегося должен существовать и не быть слишком длинным.
- Вывод должен быть очищен : должен существовать идентификатор вопроса, оценка должна быть от 1 до 10, а вывод должен иметь правильный формат, определенный Pydantic.
- Вывод должен «иметь смысл» : вы не можете поставить наивысшую оценку, если есть ошибки, или поставить 0, если ошибок нет.
- Необходимо реализовать ограничение скорости : в рабочей среде вы не хотите случайно запускать тысячи потоков одновременно без причины. Лучше всего реализовать проверку RateLimit.
Эта часть немного скучновата, но очень нужна. Поскольку она необходима, я включил её в свою папку на Github. Поскольку она скучная, я не буду её сюда копировать. Не за что! 🙂
Весь трубопровод
Весь процесс реализован через CrewAI , построенный на основе LangChain. Логика проста:
- Экипаж — это основной объект, который используется для генерации выходных данных для заданных входных данных с помощью одной команды ( crew.kickoff() ).
- Определяется агент : он объединяет инструменты, подсказки и конкретный LLM (например, GPT 4 с заданной температурой). Он связан с командой.
- Задача определена: это конкретная задача, которую мы хотим, чтобы выполнил LLM. Она также связана с экипажем.
Теперь вся магия в том, что задача связана с инструментами, подсказками и схемой Pydantic. Это означает, что вся грязная работа выполняется в бэкенде. Псевдокод выглядит так:
агент = Агент(роль=»Эксперт по оценке науки о данных», цель=»Точно и справедливо оценивать работы студентов по науке о данных, сверяя ответы с реальными наборами данных», предыстория=SYSTEM_PROMPT, инструменты=список_инструментов, llm=llm, verbose=True, allow_delegation=False, max_iter=15 ) задача = Задача(описание=описание, ожидаемый_вывод=ожидаемый_вывод, агент=агент, вывод_json=результат_оценки # Обеспечить структурированный вывод ) экипаж = Экипаж(агенты=[self.grader_agent], задачи=[task], процесс=Process.sequential, verbose=self.verbose ) результат = экипаж.kickoff()
Теперь предположим, что у нас есть следующий вывод JSON с работой студента:
Для обработки этого мы можем использовать следующий файл main.py:
И проделайте это:
python main.py —submission ../data/test.json —limit 1 —output ../results/test_llm_output.json
Такая настройка полностью соответствует принципу работы кода на уровне производства: выходные данные передаются через API как структурированный фрагмент информации, и код должен выполняться с использованием этого фрагмента данных.
Вот как отобразится терминал:
Как видно из снимка экрана выше, входные данные обрабатываются через LLM , но перед созданием выходных данных запускается CoT , вызываются инструменты и считываются таблицы .
И вот как выглядит вывод ( test_llm_output.json ):
Это хороший пример того, как можно использовать весь потенциал LLM. В конечном счёте, главное преимущество LLM — это их способность эффективно читать контекст . Чем больше контекста мы предоставляем (инструменты, подсказки на основе правил, подсказки с небольшим количеством подсказок, форматирование вывода), тем меньше LLM придётся «заполнять пробелы» (обычно галлюцинируя), и тем лучше он в конечном итоге справится с задачей.
Выводы
Спасибо, что были со мной на протяжении всего этого длинного, но, надеюсь, не слишком болезненного поста. 🙂
Мы рассказываем много интересного. В частности, мы начали с эффектных LLM-программ, которые отлично смотрятся в постах на LinkedIn, но разваливаются, как только их запускаешь каждый день, в рамках бюджета и при реальных ограничениях.
Вместо того чтобы остановиться на демонстрации, мы рассмотрели, что на самом деле необходимо для превращения LLM в систему:
- Сначала мы определили системные требования , продумав их с точки зрения стоимости, задержки и конфиденциальности, а не просто выбрав самую большую доступную модель.
- Мы сформулировали конкретный вариант использования : автоматизированный оценщик экзаменов по науке о данных, который должен читать вопросы, просматривать реальные наборы данных и давать структурированную обратную связь студентам.
- Мы разработали подсказку как спецификацию с четкой ролью, явными правилами и несколькими примерами, чтобы направить модель к единообразному поведению.
- Мы реализовали структурированный вывод с помощью Pydantic, поэтому LLM возвращает типизированные объекты вместо свободного текста, который необходимо каждый раз анализировать и исправлять.
- Мы подключили инструменты , чтобы предоставить модели доступ к наборам данных, критериям оценки и реальным ответам, чтобы она могла проверять работы учащихся, а не искажать результаты.
- Мы добавили защитные барьеры и проверки для модели, чтобы убедиться, что входные и выходные данные разумны, оценки имеют смысл, а система корректно выходит из строя, если что-то идет не так.
- Наконец, мы объединяем все в простой конвейер , где подсказки, инструменты, схемы и защитные ограждения работают как единое целое, которое можно повторно использовать, тестировать и отслеживать.
Основная идея проста. LLM — это не волшебные оракулы. Это мощные компоненты, которым нужны контекст, структура и ограничения. Чем лучше вы контролируете подсказку, формат вывода, инструменты и виды сбоев, тем меньше модели приходится заполнять пробелы самостоятельно, и тем меньше у вас будет галлюцинаций.
Прежде чем отправиться в путь
Ещё раз спасибо за уделённое время. Это очень много значит ❤️
Меня зовут Пьеро Паялунга, и я вот этот парень:
Я родом из Италии, имею докторскую степень Университета Цинциннати и работаю специалистом по анализу данных в The Trade Desk в Нью-Йорке. Я пишу об искусственном интеллекте, машинном обучении и меняющейся роли специалистов по анализу данных как здесь, на TDS, так и на LinkedIn. Если вам понравилась статья и вы хотите узнать больше о машинном обучении и следить за моими исследованиями, вы можете:
А. Подписывайтесь на меня в Linkedin , где я публикую все свои истории.
B. Подпишитесь на меня на GitHub , где вы можете увидеть весь мой код.
C. Если у вас есть вопросы, вы можете написать мне по электронной почте.
Источник: towardsdatascience.com
