doc rag harness

Защита для поиска документов (RAG)

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

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

Жгут предназначен для того, чтобы быть несколько похожим на набор для совместной технологии технологий (TCK) - для предоставления:

• Java/EMF Ecore Model/API для хранения и поиска документов, включая «Интерфейс поставщика дизайна», который будет реализован с помощью кандидатов
• Структура тестирования для оценки того, как различные конструкции выполняют определенную задачу.

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

• Загрузить/хранить модели из/до YAML, XMI и двоичных файлов, а также базы данных
• Генерировать HTML -документацию из моделей и метамоделей
• Поддержка инструментов для зрителей и редакторов зданий - Дерево, Диаграмма, Текст; Eclipse IDE и веб -браузер

На этой странице представлено введение в основные концепции и описывает несколько вариантов использования (задачи) и проектов (альтернативы).

Концепции

Приведенная ниже диаграмма описывает структуру и контекст жгута:

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

Документ

Документ - это увековеченное представление мысли или информации. Для целей этих документов жгута:

• Хранятся в источнике/репозитории документа (например, книги в библиотеке)
• Можно классифицировать, и категории могут быть вложены (например, жанр книги - художественная литература / научная фантастика)
• Может иметь внутреннюю структуру (например, объем, глава, раздел, абзац, слово)
• Может содержать различные типы содержимого - текст, изображение, видео, аудио, структуры, такие как списки и таблицы
• Может ссылаться на другие документы или внешние объекты

«Физические» реализации:

• Текстовый файл
• PDF. В Java можно загрузить с помощью Apache PDFBox
• Ocr приводит к, скажем, json
• Офисные документы MS - в Java можно загрузить Apache Poi. Файлы MS Excel могут быть загружены как модель Ecore с моделью Nasdanika Excel
• HTML документы/страницы (подтип текста)

«Логические» реализации:

• Для PDF/OCR - сканирование бизнес -документа. Например, факс быстрого сообщения. В этом случае:
  • Заголовок и нижний колонтитул, добавленные факсом, могут быть удалены как нерелевантные
  • Тела страниц могут быть проанализированы в специфическую структуру, например, MT 700
  • Внедрения могут быть созданы для тел или параграфов или предложений для некоторых элементов, номера пунктов могут быть исключены из текста. Несколько похожи на вставки в Википедии, где встраиваемые рассчитываются для отрывков, исключая заголовки.
• Для HTML - страница документации. Скажем, язык выражения пружин (SPEL) в этом случае заголовок, левая навигация, правая боковая панель и нижний колонтитул могут быть отброшены как не соответствующие или проанализированы в соответствующие функции логического документа, которые можно игнорировать. Хлебная крошка может быть использована для категоризации.
• Для текстовых файлов - в зависимости от типа контента. Например, pom.xml может быть загружен в модель объекта проекта, файл Java может быть загружен в синтаксисное дерево или график с разрешенным типом/полевым/методом ссылок.

Документ погрузчик

Конвертирует одно представление документа в другой. Например, PDF или OCR JSON для объектной модели сообщения Swift MT 700.

Документы источник

Хранение документов в определенном формате или форматах. Например, файловая система с PDF -документами. Документы источники могут быть преобразованы/адаптированы. Одним из примеров источника документа является коммит GIT. Модель Nasdanika Gitlab может использоваться для реализации загрузки документов из Gitlab.

Документ репозиторий

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

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

Может быть несколько методов поиска, таких как:

• Поиск ключевых слов
• Семантический поиск
• Суммизация - Поиск и суммирование результатов Top X

Репозитории могут быть собраны из других репозиториев и погрузчиков данных. Например, репозиторий PDF может быть собран из загрузчика данных данных PDF -> модели объекта и репозитория объектной модели. Также документируют репозитории, возможно, не придется хранить/воссоздать исходный документ - они могут ссылаться на его и извлекать из хранилища документов - оригинал, из которого был загружен документ, или хранилище документов, специфичных для репозитория.

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

Пользователь / веб -интерфейс

Пользователи запрашивают хранилище документа через веб -интерфейс. Они могут сделать это как часть своей функции работы или оценить функциональность запроса конкретного дизайна и обеспечить обратную связь. Эти две модальности могут быть объединены - пользователи могут выбрать только «Чемпионский» двигатель/дизайн запроса, например, поиск ключевых слов или также выбрать двигатели/проекты «Challenger».

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

Спонсор

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

Спонсоры должны сбалансировать несколько критериев, чтобы минимизировать «функцию потери»:

• Скорость поиска
• Точность
• Полнота
• Расходы, такие как эксплуатационные расходы, затраты на лицензию и т. Д.

Дизайн

Дизайн - это экземпляр/воплощение технологий и их параметры конфигурации.

Размеры дизайна

Точки вариации дизайна - что можно изменить в различных вариантах осуществления/экземпляров и источника значений. Например:

• Количество встроенных измерений
• ML модель
• Модель температура
• Векторная база данных
• Версия векторной базы данных

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

Интерфейс поставщика дизайна

Интерфейс поставщика дизайна (DPI) абстрагирует жгут из конкретной реализации дизайна. Это набор интерфейсов и абстрактных классов, которые Design должен реализовать. Например, интерфейс DocumentRepository . DPI определяется в Java/Ecore и может предоставлять адаптеры для различных технологий. В частности:

• REST API
• Языковые привязки и бегун, который реализует API REST и вызывает компоненты, которые реализуют интерфейс привязки языка. Например, привязка Python может быть реализована с помощью колбы
• Структурные привязки/реализации под языковыми привязками или непосредственно под DPI в Java. Например, при связывании Python может быть связывание Langchain, и при Java может быть связывание OpenNLP

Задача

Задача - это конкретное использование поиска документа. Например, семантический поиск в технической документации по конкретной организации «Как мне развернуть пружинный микросервис в AKS?».

Набор данных тестирования

Коллекция тестовых документов, запросов и оценщиков ответов.

Входы бегуна

Коллекция набора тестовых данных / комбинаций проектирования, выполненных тестовым бегуном.

Тестовый бегун

• Читает входы
• Устанавливает наборы и конструкции тестовых данных
• Загружает документы из набора тестовых данных в дизайн
• Выполняет запросы и оценивает ответы. Оценки ответов могут предоставить обратную связь с дизайном
• Результаты испытаний хранят для дальнейшего анализа и генерации отчетов

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

• Уже может быть дизайн с предварительно загруженными документами, и тестовый бегун выполнит только запросную часть
• Или набор тестовых данных может содержать только документы, но не запросы и оценки ответов, поскольку запросы и ответы должны быть предоставлены пользователями через веб -интерфейс
• Test Runner может загружать документы в дизайн и сохранить его в качестве нового дизайна. Например, создайте контейнер из изображения, загрузите документы, а затем остановите контейнер и создайте изображение из контейнера.
• Аналогичным образом, тестовый бегун может принимать тестовый набор данных, объединить его с полученной обратной связью и создать и создать новый набор тестовых данных.

Тестовые прогоны могут быть распределены по нескольким агентам/машинах.

Результаты теста и отзывы пользователей

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

Отчет Генератор

Генерирует отчет. Отчет может быть в формате HTML с визуализацией. Возможный формат отчета:

• Левая панель с деревом проектов, деревом задач и наборами тестовых данных для задач. Он также может включать в себя «Tech Stack Tree» - категоризированные проектные строительные блоки. Например, дерево векторных баз данных, их версии и конфигурации. Если левая панель становится слишком шумной, некоторые предметы могут быть перемещены в панель навигации.
• Панель контента - Документация для выбранного элемента. Например
  • Главная страница - Сводка выполненных тестов: фильтруемая сортируемая таблица с дизайнерскими/тестовыми перестановками (для относительно небольших пространств), визуализации, например, 3D -рассеяние Egharts. Он также может содержать мастер дизайна для создания проектов, отвечая на вопросы и выбирая тестируемый дизайн, который наилучшим образом соответствует ответам.
  • Страница дизайна - конфигурация, тесты и результаты - Таблица, Визуализация
  • Страница задачи - Описание, тесты, проекты, визуализация. Он может размещать веб -интерфейс агрегации, который собирает ответы от всех проектов для этой задачи и позволяет пользователям сравнивать ответы из альтернативных проектов. Одним из вариантов сравнения является парное сравнение, возможно, без ущерба, из какого дизайна данный ответ поступает.
  • Строительный блок (например, векторная база данных, ее версия, конфигурация) - Описание, проекты, которые его используют.

Отчет может содержать ссылки на веб -интерфейс или даже «Хости» веб -интерфейса, если он реализован как одно страница (SPA) с, скажем, React или Vue.js/Bootstrapvue

Сообщество

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

--- Работа в процессе ---

Задачи

В этом разделе описывается несколько задач (варианты использования) для получения добычи и поиска в целом.

Размеры:

• Количество документов
• Количество пользователей
• Частота изменений
• Конфиденциальность
• Риск - стоимость ошибки

Техническая документация

Пример - технологическая функция на крупном предприятии:

• Несколько уровней:
  • Корпоративный, привязывает технологические варианты общеобразовательных предприятий (например, Java/Spring, Maven Components), предоставляет общие строительные блоки по всей корпорации (например, библиотека компонентов начальной загрузки) и другие технологии (например, конвейер сборка)
  • Сегмент - Технологический выбор Narrows, например, версия Java, добавьте специфичные для сегмента способы ведения дел в дополнение к руководящим принципам предприятия (которые, в свою очередь, построены в соответствии с руководящими принципами и документацией по технологиям промышленности/поставщика). Может ввести строительные блоки на уровне сегмента.
  • Возможности/команда - технологический выбор созревает еще дальше и уточняет то, как они используются. Может ввести строительные блоки на уровне возможностей/команд, такие как библиотеки виджетов.

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

В такой среде пользователям необходимо для поиска решения, которое позволяет извлекать документы, специфичные для позиции и роли пользователя в предприятии, и усилия, которые они назначены. Например, разработчик Java, работающий над тем, что текущий релиз может понадобиться информация о Java 17. Если один и тот же разработчик будет назначен для работы над будущим выпуском, им может понадобиться информация, скажем, Java 20. Когда они работают с такими технологиями, как Kubernetes и Azure AKS, документация по поставщику может быть в значительной степени бесполезным и вызывают непрерывность, потому что он содержит общие вещи, которые они должны знать, что они должны знать, что они могут знать, что они могут знать, что они могут знать, что они могут понять, что они могут понять, что они могут понять, что они могут понять, что они могут понять, что они могут понять, что они могут понять, что в ней может быть в целях.

• Количество документов: десятки тысяч
• Количество пользователей: сотни до тысячи
• Частота изменений: низкий (например, месяц) до умеренной (несколько раз в месяц)
• Конфиденциальность: внутренняя
• Риск: низкий

Процедуры

Размеры:

• Количество документов: низкие тысячи
• Количество пользователей: сотни до тысячи
• Частота изменений: низкая (например, ежемесячно)
• Конфиденциальность: внутренняя, ограниченная, конфиденциальная
• Риск: средний и высокий

Операционные документы

Размеры:

• Количество документов: возможно миллионы
• Количество пользователей: сотни до тысячи
• Частота изменений: высокая (ежедневно)
• Конфиденциальность: конфиденциальная, личная информация - PII, PHI, PCI
• Риск: высокий

Дизайн

Entgeddings, Vector Databases, LLM

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

Графики

Тодо. Может быть лучше для меньшего количества документов (процедур) - все они могут соответствовать памяти, и поиск может быть выполнен на семантических графиках. В случае векторной базы данных одним из способов построения индексов является использование графиков - иерархический судоходной маленький мир (HNSW)

Полиморфные графики

Тодо. Может быть, подходит для технической документации:

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

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

Сноски

1. Пространство дизайна для нейронных сетей, лекционная часть Stanford CS224W: ML с графиками, слайды ↩