Создание расширенных систем создания дополненных данных

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

• Получение дополненного поколения (RAG), которое дополняет обучение крупной языковой модели (LLM) базой данных доступных для поиска статей, которые можно получить на основе сходства запросов пользователей и передачи в LLM для завершения.
• Настройка, которая расширяет обучение LLM, чтобы понять больше о проблемной области.

В предыдущей статье также рассматривается, когда следует использовать каждый подход, про и минусы каждого подхода и некоторые другие аспекты.

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

В предыдущей статье показаны шаги или этапы RAG с помощью следующей схемы.

Это изображение называется "наивным RAG" и является полезным способом первого понимания механизмов, ролей и обязанностей, необходимых для реализации системы чата на основе RAG.

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

В этой статье представлена концептуальная платформа для понимания типов проблем предварительной и последующей обработки в реальной системе чата на основе RAG, упорядоченной следующим образом:

• Этап приема
• Этап конвейера вывода
• Этап оценки

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

Прием (Ingestion)

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

Для этого разработчикам необходимо рассмотреть следующее:

• Предварительная обработка и извлечение содержимого
• Стратегия фрагментирования
• Организация блокирования
• Стратегия обновления

Предварительная обработка и извлечение содержимого

Чистое и точное содержимое является одним из лучших способов улучшить общее качество системы чата на основе RAG. Для этого разработчикам необходимо начать с анализа фигуры и формы документов, которые необходимо индексировать. Соответствуют ли документы указанным шаблонам содержимого, таким как документация? Если нет, какие типы вопросов могут ответить на документы?

По крайней мере разработчики должны создавать шаги в конвейере приема:

• Стандартизация текстовых форматов
• Обработка специальных символов
• Удаление несвязанного, устаревшего содержимого
• Учетная запись для содержимого с версиями
• Учетная запись взаимодействия с контентом (вкладки, изображения, таблицы)
• Извлечение метаданных

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

Стратегия фрагментирования

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

Разработчики должны учитывать следующее:

• Оптимизация размера блока— определение идеального размера блока и назначение блока. По разделу? По абзацу? По предложению?
• Перекрывающиеся и скользящие блоки окна. Определите, как разделить содержимое на дискретные блоки. Или будут ли блоки перекрываться? Или оба (скользящее окно)?
• Small2Big - Когда фрагментирование на гранулярном уровне, как один предложение, будет организовано содержимое таким образом, чтобы легко найти соседние предложения или содержащий абзац? (См. раздел "Блокирование организации".) Получение дополнительных сведений и предоставление его LLM может предоставить ему больше контекста при ответе на запрос пользователя.

Организация блокирования

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

• Иерархические индексы . Этот подход включает создание нескольких слоев индексов, где индекс верхнего уровня (сводный индекс) быстро сужает пространство поиска до подмножества потенциально релевантных блоков, а индекс второго уровня (индекс блоков) предоставляет более подробные указатели на фактические данные. Этот метод может значительно ускорить процесс извлечения, так как он сокращает количество записей для сканирования в подробном индексе путем фильтрации по сводной индексу сначала.
• Специализированные индексы — специализированные индексы , такие как графовые или реляционные базы данных, можно использовать в зависимости от характера данных и связей между блоками. Например:
  • Индексы на основе графов полезны, если блоки имеют взаимосвязанные сведения или связи, которые могут улучшить получение, такие как сети ссылок или графы знаний.
  • Реляционные базы данных могут быть эффективными, если блоки структурированы в табличном формате, где запросы SQL могут использоваться для фильтрации и извлечения данных на основе определенных атрибутов или связей.
• Гибридные индексы — гибридный подход объединяет несколько стратегий индексирования для использования сильных сторон каждого. Например, разработчики могут использовать иерархический индекс для начальной фильтрации и графового индекса для динамического изучения связей между блоками во время извлечения.

Оптимизация выравнивания

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

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

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

Стратегии обновления

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

• Добавочные обновления:
  • Регулярные интервалы: планирование обновлений с регулярными интервалами (например, ежедневно, еженедельно) в зависимости от частоты изменений документа. Этот метод гарантирует, что база данных периодически обновляется.
  • Обновления на основе триггеров: реализуйте систему, в которой обновления активируют повторное индексирование. Например, любое изменение или добавление документа может автоматически инициировать переиндексирование затронутых разделов.
• Частичные обновления:
  • Выборочное повторное индексирование: вместо повторного индексирования всей базы данных выборочно обновите только части корпуса, которые изменились. Это может быть более эффективным, чем полная переиндексация, особенно для больших наборов данных.
  • Разностная кодировка: храните только различия между существующими документами и их обновленными версиями. Такой подход снижает нагрузку на обработку данных, избегая необходимости обработки без изменений данных.
• Управление версиями:
  • Моментальный снимок: обслуживание версий корпуса документа в разные моменты времени. Это позволяет системе вернуться или ссылаться на предыдущие версии при необходимости и предоставить механизм резервного копирования.
  • Управление версиями документов: система управления версиями используется для систематического отслеживания изменений в документах. Это помогает поддерживать журнал изменений и упростить процесс обновления.
• Обновления в режиме реального времени:
  • Потоковая обработка. Использование технологий потоковой обработки для обновления векторной базы данных в режиме реального времени при внесении изменений в документы. Это может быть важно для приложений, где своевременность информации является первостепенной.
  • Динамический запрос. Вместо того, чтобы полагаться исключительно на предварительно индексированные векторы, реализуйте механизм для запроса динамических данных для наиболее актуальных ответов, возможно, объединяя это с кэшируемыми результатами для повышения эффективности.
• Методы оптимизации:
  • Пакетная обработка: накапливать изменения и обрабатывать их в пакетах для оптимизации использования ресурсов и снижения затрат, вызванных частыми обновлениями.
  • Гибридные подходы. Объединение различных стратегий, таких как использование добавочных обновлений для незначительных изменений и полного переиндексирования для основных обновлений или структурных изменений в корпусе документа.

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

Конвейер вывода

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

• Выполняется ли запрос пользователя таким образом, чтобы получить результаты из системы, которую ищет пользователь?
• Нарушает ли запрос пользователя какие-либо из наших политик?
• Как перезаписать запрос пользователя, чтобы повысить шансы на поиск ближайших совпадений в векторной базе данных?
• Как оценить результаты запроса, чтобы убедиться, что блоки статьи выровнены по запросу?
• Как оценить и изменить результаты запроса перед их передачей в LLM, чтобы убедиться, что наиболее важные сведения включены в завершение LLM?
• Как оценить ответ LLM, чтобы убедиться, что завершение LLM отвечает на исходный запрос пользователя?
• Как обеспечить соответствие ответа LLM нашим политикам?

Как видите, существует множество задач, которые разработчики должны учитывать, в основном в виде:

• Предварительная обработка входных данных для оптимизации вероятности получения требуемых результатов
• Выходные данные после обработки, чтобы обеспечить требуемые результаты

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

Рассмотрим каждый этап, чтобы определить конкретные стратегии.

Шаги предварительной обработки запросов

Предварительная обработка запроса происходит сразу после отправки запроса пользователем, как показано на этой схеме:

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

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

Повторное написание запроса . Это может быть что-то от расширения акронимов и удаления сленга до повторного выражения вопроса, чтобы задать его более абстрактно, чтобы извлечь высокоуровневые понятия и принципы ("пошаговое предложение").

Вариантом запроса обратного шага является гипотетическая внедрение документов (HyDE), которая использует LLM для ответа на вопрос пользователя, создает внедрение для этого ответа (гипотетическое внедрение документа) и использует его для выполнения поиска в векторной базы данных.

Подзапросы

Этот шаг обработки касается исходного запроса. Если исходный запрос длинный и сложный, его можно программно разбить на несколько небольших запросов, а затем объединить все ответы.

Например, рассмотрим вопрос, связанный с научными открытиями, особенно в области физики. Запрос пользователя может быть: "Кто сделал более значительный вклад в современную физику, Альберт Эйнштейн или Нилс Бор?"

Этот запрос может быть сложным для обработки напрямую, поскольку "значительные вклады" могут быть субъективными и многомерными. Разбиение в вложенные запросы может сделать его более управляемым:

1. Подзапрос 1: "Каковы ключевые вклады Альберта Эйнштейна в современную физику?"
2. Подзапрос 2: "Каковы ключевые вклады Нилса Бора в современную физику?"

Результаты этих вложенных запросов подробно описывают основные теории и открытия каждого физика. Например:

• Для Эйнштейна взносы могут включать теорию относительности, фотоэлектрический эффект и E=mc^2.
• Для Бора, вклады могут включать свою модель водородного атома, его работу по квантовой механике, и его принцип взаимодополняемости.

После того как эти взносы будут описаны, их можно оценить, чтобы определить следующее:

3. Подзапрос 3: "Как теории Эйнштейна повлияли на развитие современной физики?"
4. Подзапрос 4: "Как теории Бора повлияли на развитие современной физики?"

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

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

Маршрутизатор запросов

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

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

1. Анализ запросов: LLM или другой компонент анализирует входящий запрос, чтобы понять его содержимое, контекст и тип информации, вероятно, необходимо.
2. Выбор индекса. На основе анализа маршрутизатор запросов выбирает один или несколько из потенциально доступных индексов. Каждый индекс может быть оптимизирован для различных типов данных или запросов, например, некоторые могут быть более подходящими для фактических запросов, а другие могут преуспеть в предоставлении мнений или субъективного содержимого.
3. Диспетчер запросов. Затем запрос отправляется в выбранный индекс.
4. Результаты агрегирования: ответы из выбранных индексов извлекаются и, возможно, агрегируются или обрабатываются для формирования комплексного ответа.
5. Создание ответов. Последний шаг включает создание последовательного ответа на основе полученной информации, возможно, интеграции или синтезирования содержимого из нескольких источников.

Ваша организация может использовать несколько обработчиков извлечения или индексов для следующих вариантов использования:

• Специализация типа данных: некоторые индексы могут специализируется на новостях, других в академических документах, а также другие в общем веб-контенте или конкретных базах данных, таких как медицинская или юридическая информация.
• Оптимизация типов запросов: некоторые индексы могут быть оптимизированы для быстрого поиска фактических данных (например, дат, событий), а другие могут быть лучше для сложных задач рассудка или запросов, требующих глубокого знания о домене.
• Алгоритмические различия. Различные алгоритмы извлечения могут использоваться в разных механизмах, таких как поиск сходства на основе векторов, традиционные поиски на основе ключевых слов или более сложные модели семантического понимания.

Представьте себе систему на основе RAG, используемую в контексте медицинских консультаций. Система имеет доступ к нескольким индексам:

• Индекс бумаги для медицинских исследований, оптимизированный для подробных и технических объяснений.
• Клинический индекс исследования, который предоставляет реальные примеры симптомов и лечения.
• Общий индекс сведений о работоспособности для основных запросов и сведений о здравоохранении.

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

Этапы обработки после извлечения

Обработка после получения происходит после того, как компонент извлекателя извлекает соответствующие фрагменты содержимого из векторной базы данных, как показано на схеме:

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

Разработчики должны учитывать несколько аспектов запроса. Запрос, содержащий слишком много дополнительных сведений и некоторые (возможно, наиболее важные сведения) можно игнорировать. Аналогичным образом, запрос, содержащий неуместные сведения, может оказать несоответственное влияние на ответ.

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

Наконец, максимальная длина окна контекста LLM и количество маркеров, необходимых для выполнения чрезвычайно длинных запросов (особенно при работе с запросами в масштабе), необходимо учитывать.

Для решения этих проблем конвейер обработки после извлечения может включать следующие действия:

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

Этапы обработки после завершения

Обработка после завершения происходит после запроса пользователя и отправки всех блоков содержимого в LLM, как показано на следующей схеме:

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

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

Оценка

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

• Удовлетворены ли пользователи результатами, которые они получают?
• Получают ли пользователи точные ответы на их вопросы?
• Как записывать отзывы пользователей? У нас есть какие-либо политики, ограничивающие, какие данные можно собирать о пользовательских данных?
• Для диагностики на неудовлетворительные ответы, у нас есть видимость всей работы, которая пошла на ответ на вопрос? Сохраняем ли мы журнал каждого этапа в конвейере вывода входных и выходных данных, чтобы мы могли выполнять анализ первопричин?
• Как можно вносить изменения в систему без регрессии или ухудшения результатов?

Запись и выполнение отзывов от пользователей

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

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

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

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

Золотой набор данных

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

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

Оценка вреда

Моделирование вреда — это методология, направленная на предвидение потенциального вреда, выявления недостатков в продукте, которые могут представлять риски для отдельных лиц, и разработки упреждающих стратегий для устранения таких рисков.

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

Ключевыми функциями средства оценки вреда могут быть:

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе:

• Основы оценки вреда
• Типы вреда

Тестирование и проверка гарантий

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

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

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

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

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

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