Предварительные требования: сбор требований

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

См. репозиторий GitHub для примера кода в этом разделе. Вы также можете использовать код репозитория в качестве шаблона, с помощью которого можно создавать собственные приложения ИИ.

Подходит ли вариант использования для RAG?

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

RAG хорошо подходит, когда:

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

RAG может быть не лучшим вариантом, когда:

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

Требования к обнаружению

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

🟢 P0. Перед запуском POC необходимо определить это требование.

🟡 P1: необходимо определить перед переходом на производство, но может итеративно уточнить во время POC.

⚪ P2: Ницца, чтобы иметь требование.

Это не исчерпывающий список вопросов. Однако он должен обеспечить надежную основу для сбора ключевых требований к решению RAG.

Взаимодействие с пользователем

Определение способа взаимодействия пользователей с системой RAG и ожидаемых ответов

🟢 [P0] Как будет выглядеть типичный запрос к цепочке RAG? Попросите заинтересованных лиц примеры потенциальных запросов пользователей.

🟢 [P0] Какие ответы будут ожидать пользователи (короткие ответы, объяснения длинной формы, сочетание или что-то другое)?

🟡 [P1] Как пользователи взаимодействуют с системой? Через интерфейс чата, панель поиска или другую модальность?

🟡 [P1] тон или стиль шляпы должны принимать ответы? (формальный, разговорный, технический?)

🟡 [P1] Как приложение должно обрабатывать неоднозначные, неполные или неуместные запросы? Должны ли в таких случаях предоставляться какие-либо формы отзывов или рекомендаций?

⚪ [P2] Существуют ли определенные требования к форматированию или презентации для созданных выходных данных? Должны ли выходные данные включать любые метаданные в дополнение к ответу цепочки?

Data

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

🟢 [P0] Какие доступные источники для использования?

Для каждого источника данных:

• 🟢 [P0] Структурированы ли данные или неструктурируются?
• 🟢 [P0] Что такое исходный формат данных извлечения (например, PDF-файлы, документация с изображениями и таблицами, структурированные ответы API)?
• 🟢 [P0] Где находятся эти данные?
• 🟢 [P0] Сколько доступных данных?
• 🟡 [P1] Как часто обновляются данные? Как обрабатывать эти обновления?
• 🟡 [P1] Существуют ли известные проблемы с качеством данных или несоответствия для каждого источника данных?

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

Источник данных	Исходный код	Тип файла	Размер	Периодичность обновления
Источник данных 1	Том каталога Unity	JSON	10 ГБ	Ежедневно
Источник данных 2	Общедоступный API	XML	NA (API)	Реальное время
Источник данных 3	SharePoint	PDF, .docx	500 МБ	Ежемесячно

Ограничения производительности

Захват требований к производительности и ресурсам для приложения RAG.

🟡 [P1] Какова максимальная допустимая задержка для создания ответов?

🟡 [P1] Что такое максимально допустимое время для первого маркера?

🟡 [P1] Если выходные данные передаются, допускается более высокая общая задержка?

🟡 [P1] Существуют ли ограничения затрат на вычислительные ресурсы, доступные для вывода?

🟡 [P1] Каковы ожидаемые шаблоны использования и пиковые нагрузки?

🟡 [P1] Сколько одновременных пользователей или запросов может обрабатывать система? Databricks изначально обрабатывает такие требования к масштабируемости с помощью возможности автоматического масштабирования с помощью службы моделей.

Оценка

Определите, как решение RAG будет оцениваться и улучшаться с течением времени.

🟢 [P0] Что такое бизнес-цель / ключевой показатель эффективности, который вы хотите повлиять? Что такое базовое значение и что такое целевой объект?

🟢 [P0] Какие пользователи или заинтересованные лица будут предоставлять первоначальные и текущие отзывы?

🟢 [P0] Какие метрики следует использовать для оценки качества созданных ответов? Оценка агента ИИ мозаики предоставляет рекомендуемый набор метрик для использования.

🟡 [P1] Что такое набор вопросов, которые приложение RAG должно быть хорошим, чтобы перейти к рабочей среде?

🟡 [P1] Существует ли [оценочный набор]? Можно ли получить оценочный набор запросов пользователей, а также ответы на ответы на землю и (необязательно) правильные вспомогательные документы, которые должны быть получены?

🟡 [P1] Как будут собираться отзывы пользователей и включаться в систему?

Безопасность

Определите все вопросы безопасности и конфиденциальности.

🟢 [P0] Есть ли конфиденциальные или конфиденциальные данные, которые должны обрабатываться с осторожностью?

🟡 [P1] Необходимо ли реализовать элементы управления доступом в решении (например, пользователь может получить только из ограниченного набора документов)?

Развертывание

Общие сведения о том, как решение RAG будет интегрировано, развернуто и поддерживается.

🟡 Как решение RAG интегрируется с существующими системами и рабочими процессами?

🟡 Как следует развертывать, масштабировать и масштабировать модель? В этом руководстве описывается, как комплексный жизненный цикл можно обрабатывать в Databricks с помощью MLflow, каталога Unity, пакета SDK агента и обслуживания моделей.

Пример

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

Площадь	Рекомендации	Требования
Взаимодействие с пользователем	— модальность взаимодействия. — Типичные примеры запросов пользователей. — Ожидаемый формат отклика и стиль. — обработка неоднозначных или неуместных запросов.	— Интерфейс чата, интегрированный с Slack. — Примеры запросов: "Разделы справки сократить время запуска кластера?" "Какой план поддержки у меня есть?" — Очистка, технические ответы с фрагментами кода и ссылки на соответствующую документацию, если это необходимо. — Предоставьте контекстные предложения и переключите их на поддержку инженеров по мере необходимости.
Data	— число и тип источников данных. — Формат данных и расположение. — Размер данных и частота обновления. — Качество данных и согласованность.	— три источника данных. — Документация компании (HTML, PDF). — Разрешенные запросы в службу поддержки (JSON). - Публикации форума сообщества (таблица Delta). — Данные, хранящиеся в каталоге Unity и обновляемые еженедельно. — Общий размер данных: 5 ГБ. — Согласованная структура данных и качество, поддерживаемая выделенными документами и группами поддержки.
Производительность	— Максимальная допустимая задержка. — ограничения затрат. — ожидаемое использование и параллелизм.	— требование максимальной задержки. — ограничения затрат. — ожидаемая пиковая нагрузка.
Оценка	— Доступность набора данных оценки. — Метрики качества. — Сбор отзывов пользователей.	— Эксперты по темам из каждой области продукта помогают просматривать выходные данные и настраивать неправильные ответы на создание набора данных оценки. - Ключевые показатели эффективности бизнеса. — Увеличение скорости разрешения запросов в службу поддержки. — уменьшение времени пользователя, затраченного на запрос в службу поддержки. — Метрики качества. - LLM-судимый ответ правильности и релевантности. — точность извлечения судей LLM. — upvote или downvote пользователя. — коллекция отзывов. - Slack будет инструментирован для предоставления пальцем вверх /вниз.
Безопасность	— обработка конфиденциальных данных. — Требования к управлению доступом.	— Конфиденциальные данные клиента не должны находиться в источнике извлечения. — проверка подлинности пользователей с помощью единого входа в Databricks Community.
Развертывание	— интеграция с существующими системами. — Развертывание и управление версиями.	— Интеграция с системой запросов в службу поддержки. — цепочка, развернутая как конечная точка обслуживания модели Databricks.

Следующий шаг

Начало работы с шагом 1. Клонируйте репозиторий кода и создайте вычислительные ресурсы.

< Предыдущая статья: разработка на основе оценки

Далее: шаг 1. Клонирование репозитория и создание вычислений >