Основные понятия и рекомендации по созданию решений сгенерируемым ИИ

Большие языковые модели (LLM) удивительны, но у них есть ограничения. Разработчику необходимо понять эти ограничения, на что способны ЯМЯ "из коробки", а также как адаптировать их, чтобы получить наилучшие результаты для разрабатываемых решений генеративного ИИ. В этой статье описано несколько проблем и ограничения факторов LLM. В нем описываются распространенные способы преодоления проблем и управление процессом создания контента независимо от типа создаваемых функций ИИ, которые вы создаете в приложении.

Инженерные проблемы при работе с LLM

В следующем списке приведены наиболее важные проблемы или ограничения, которые следует учитывать при работе с LLM:

• Ограничение знаний: из-за высокой стоимости обучения LLM, объём знаний LLM ограничен тем, что он был обучен на определённый момент времени. Без подключаемых модулей или других средств LLM не имеет доступа к информации в режиме реального времени и не может получить доступ к частным данным.

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

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

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

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

Где LLM получают свои сведения

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

• Генерация без извлечения (ROG): традиционные LLM используют эту модель. Модель создает ответы исключительно на основе знаний, на которые она была обучена, без доступа или обращения к внешней информации во время генерации. Знания модели являются статическими и ограничены тем, что было включено в её обучающие данные до даты отсечения. Помимо творческого письма, он может ответить на вопросы о информации, которая легко доступна в Интернете.

• получения дополненного поколения (RAG): объединяет возможности создания LLM с возможностью получения информации из внешних баз данных или документов в режиме реального времени. Модель запрашивает внешний источник, чтобы найти соответствующие сведения. Затем она использует информацию для формирования ответа. Такой подход позволяет модели предоставлять более точные и up-toданные даты, чем они предоставляются только с помощью предварительно обученных знаний. Варианты использования включают проверку фактов, ответы на вопросы на основе данных в режиме реального времени или ответы на вопросы на основе частных, доменных данных.

• генерация, ориентированная на извлечение (RCG): уделяет еще больше внимания извлеченному из внешних источников контенту, часто структурируя ответы на основе информации из внешних источников. Модель может напрямую включать большие сегменты полученного текста в выходные данные, редактирование или аннотирование, чтобы они соответствовали запросу пользователя. Этот подход можно рассматривать как гибрид между методами на основе извлечения и генеративными методами, где баланс может сильно склоняться в сторону извлекаемой информации по сравнению с собственными возможностями генерации модели. Варианты использования включают обобщение более длинного документа, помощь в исследованиях для сравнения и тематических исследований в нескольких аналогичных документах, а также компиляция или сортировка различных источников материала в объединенный вывод.

Хорошим примером ROG является ChatGPT. Напротив, Copilot (через Bing) расширяет LLM с помощью внешних новостных источников (и предоставляет ссылки на них).

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

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

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

Механизмы внешнего получения данных, обеспечивающие работу RAG и RCG, рассматриваются в статьях о хранении векторизованных встраиваний документов и тонкой настройке LLM, двух распространенных подходах к дополнению знаний, которыми располагает LLM на основе его первоначального обучения.

Понимание различий между моделями извлечения поможет выбрать правильный подход для конкретных приложений. Это помогает сбалансировать потребность в творческом синтезе и точности и верности исходному материалу.

Факторы, влияющие на работу вывода

Так как вы, скорее всего, знакомы с веб-интерфейсом ChatGPT, понимание того, как оно работает, чтобы ответить на вопросы, помогут вам понять основные понятия, которые важны при создании созданных функций ИИ в собственных приложениях.

Когда пользователь общается с ChatGPT, дизайн пользовательского интерфейса создает иллюзию длительного сеанса чата, который сохраняет состояние в ходе нескольких обменов между вами и LLM. В действительности для данного сеанса чата все запросы и все ответы LLM (также называемые завершения) отправляются с каждым новым запросом. По мере роста беседы вы отправляете все больше текста в LLM для обработки. С каждым новым запросом вы отправляете все предыдущие запросы и ответы. ChatGPT использует весь контекст сеанса чата, а не только текущий запрос, когда он создает ответ на текущий запрос. Весь сеанс чата называется окном контекста .

Окно контекста имеет ограничение длины, которое зависит от версии ChatGPT, с которым вы работаете. Любая часть беседы чата, превышающая ограничение длины окна контекста, игнорируется, когда ChatGPT создает ответ на последний запрос.

Длинные беседы могут показаться хорошей идеей на первый взгляд, но длинные контекстные окна могут повлиять на объем вычислений, необходимых для обработки запроса и создания результата. Размер контекстных окон влияет на задержку ответа и сколько это стоит для OpenAI для обработки запроса.

Что такое ограничение контекстного окна ChatGPT? Сколько слов может обрабатывать ChatGPT?

Ограничение контекстного окна зависит от модели LLM, версии и выпуска, с которым вы работаете. Кроме того, длина контекста измеряется в токенах, а не в словах. Маркеры — это наименьшие единицы текста, которые модель может понять и создать. Эти единицы могут быть словами, частями слов (например, слогами или корнями), или даже отдельными символами. Маркеры находятся в основе обработки естественного языка (NLP).

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

• Максимальное ограничение окна контекста
• Цена за запрос и завершение

Что такое токенизация?

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

На странице токенизатора OpenAI рассказывается больше о токенизации. На странице есть даже калькулятор, иллюстрирующий, как предложение или абзац разбивается на токены.

Как отмечается в нижней части страницы OpenAI Tokenizer, в типичных английских текстах один токен эквивалентен примерно четырем символам. В среднем, 100 токенов примерно равны 75 словам или три четверти слова на токен.

Страница OpenAI Tokenizer также рассказывает о tiktoken, пакете для Python и JavaScript, который можно использовать, чтобы программистски оценить, сколько токенов требуется для отправки определённой подсказки в API OpenAI.

Использование маркеров влияет на выставление счетов

Каждый API OpenAI Azure имеет другую методологию выставления счетов. Для обработки и генерации текста с помощью API завершения чата вы оплачиваете на основе количества токенов, которые вы отправляете в виде запроса, и количества токенов, создаваемых в результате (в завершении).

Каждая модель LLM (например, GPT-3.5, GPT-3.5 Turbo или GPT-4) обычно стоит по-разному, что отражает объем вычислений, необходимых для обработки и генерации токенов. Во многих случаях цена представлена как "цена за 1000 токенов" или "цена за 1 миллион токенов".

Эта модель ценообразования оказывает значительное влияние на то, как вы разрабатываете взаимодействие с пользователем, а также объем предварительной обработки и последующей обработки, которую вы добавляете.

Системные запросы и запросы пользователей

До этого момента обсуждение сосредоточено исключительно на пользователей запрашивает. Запрос пользователя — это тип запроса, который создает обмен между пользователем и ChatGPT.

OpenAI представил системный запрос (также называемый пользовательских инструкций). Запрос системы — это общий набор инструкций, который вы определяете и добавляете ко всем чатам. Думайте об этом как о наборе мета-инструкций, которые вы хотите, чтобы LLM всегда следовал в каждый раз, когда вы начинаете новый сеанс чата. Например, можно задать системную подсказку "всегда отвечать в поэтической форме хайку". С этого времени каждый новый запрос к ChatGPT будет создавать хайку с ответом.

Хотя "ответ в форме хайку" не является полезным примером, он иллюстрирует идею о том, что вы можете повлиять на завершение ответа LLM, изменив сам запрос.

Почему вы хотите изменить запрос пользователя? Если вы создаете генеративную функцию ИИ или приложение для профессиональной аудитории, которая может включать сотрудников компании, клиентов и партнеров, вы, несомненно, хотите добавить гарантии, чтобы ограничить темы или области, на которые он может отвечать.

Однако изменение пользовательского запроса — это лишь один из способов улучшить работу с генерацией текста для пользователей.

Методы улучшения процесса создания текста для пользователей в ChatGPT

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

• Изменение пользовательских запросов программным способом.
• Реализуйте конвейер вывода.
• Retrieval-Augmented поколение (рассматривается в других статьях).
• Точная настройка (рассматривается в других статьях).

Программное изменение запросов пользователей

Чтобы добавить системный запрос в беседу пользователя, вы не используете специальный API. Вы просто добавляете инструкции к запросу по мере необходимости.

Но вы можете использовать несколько методов для улучшения запросов пользователей:

• Контекстное моделирование: формируйте системные подсказки, которые явно задают контекст беседы в соответствующей области. Этот подход включает в себя краткое описание или набор инструкций в начале каждого взаимодействия. Инструкции направляют ИИ оставаться в рамках задач.
• Примерное руководство: В начальном запросе приведены примеры типов вопросов и ответов, относящихся к вашей области. Этот подход помогает ИИ понять, какие ответы следует ожидать.

Вы можете использовать любую технику инженерии подсказок. Если это можно сделать программным способом, вы можете улучшить запрос пользователя от их имени.

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

Реализация конвейера вывода

Следующим шагом, помимо изменения запроса пользователя программным способом, является создание всего конвейера вывода.

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

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

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

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

Для получения информации о конкретных шагах по созданию инфраструктуры вывода, см. в статье Построение продвинутой системы генерации с усилением поиска.

Другие факторы, влияющие на завершение

Помимо программного изменения запроса, создания конвейера вывода и других методов, более подробные сведения рассматриваются в расширении возможностей крупной языковой модели с генерацией, дополненной обеспечением получения данных, и дополнительной настройкой. Кроме того, можно изменить параметры при вызове API Azure OpenAI.

Чтобы просмотреть обязательные и необязательные параметры передачи, которые могут повлиять на различные аспекты выполнения, см. документацию по конечной точки чата. Если вы используете пакет SDK, ознакомьтесь с документацией по пакету SDK для используемого языка. Вы можете поэкспериментировать с параметрами в детской площадке.

• Temperature. Управление случайностью выходных данных, генерируемых моделью. В нуле модель становится детерминированной, последовательно выбирая наиболее вероятный следующий маркер из обучающих данных. При температуре 1 модель балансирует между выбором маркеров высокой вероятности и введением случайности в выходные данные.

• Max Tokens: определяет максимальную длину ответа. Установка более высокого или нижнего предела может повлиять на сведения и область создаваемого содержимого.

• Top P (выборка ядра): используется с Temperature для управления случайностью ответа. Top P ограничивает ИИ рассматривать только верхний процент массы вероятности (P) при создании каждого маркера. Более низкие значения приводят к более ориентированному и предсказуемому тексту. Более высокие значения позволяют повысить разнообразие.

• Frequency Penalty: уменьшает вероятность повторения той же строки или фразы модели. Увеличение этого значения помогает избежать избыточности в созданном тексте.

• Presence Penalty: рекомендует модели вводить новые концепции и термины в завершении. Presence Penalty полезно для создания более разнообразных и творческих результатов.

• Stop Sequences. Можно указать одну или несколько последовательностей, чтобы указать API прекратить создание дополнительных маркеров. Store Sequences полезны для контроля структуры выходных данных, например, завершения в конце предложения или абзаца.

• Logit Bias. Позволяет изменить вероятность появления указанных маркеров в завершении. Logit Bias можно использовать для управления ходом завершения в определенном направлении или для подавления конкретного содержимого.

Меры защиты Microsoft OpenAI

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

Во-первых, вызовы API к Службам Microsoft OpenAI автоматически фильтруют содержимое, которое API находит потенциально оскорбительным и сообщает об этом вам во многих категориях фильтрации.

Вы можете непосредственно использовать API модерации OpenAI, чтобы проверить любое содержимое на потенциально вредное содержание.

Затем вы можете использовать Azure AI для защиты контента, чтобы помочь в модерации текста, модерации изображений, обнаружении рисков взлома и обнаружении защищенного материала. Это объединяет возможности настройки, настройки и создания отчетов портала с кодом, который можно добавить в приложение, чтобы определить вредное содержимое.

Окончательные рекомендации по проектированию приложений

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

Ниже приведен краткий список вещей, которые следует рассмотреть и другие варианты из этой статьи, которые могут повлиять на ваши решения по проектированию приложений:

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

Если вы хотите начать экспериментировать с созданием генеративного решения на базе искусственного интеллекта немедленно, рекомендуем ознакомиться с разделом , начиная работу с чатом, используя ваш собственный образец данных для Python. Это руководство также доступно в .NET, Javaи JavaScript.