Веб-контент для баз знаний Amazon Bedrock: подготовка через Crawl4AI

Как сообщает AWS Machine Learning, качество ответов в приложениях генерации с поиском по базе знаний (RAG) зависит от данных, которые в них загружаются. Amazon Bedrock Knowledge Bases — полностью управляемая RAG-возможность Amazon Bedrock. Пользователь подключает источники данных, а Amazon Bedrock сам управляет загрузкой, хранением, индексацией и поиском. Не нужно настраивать или масштабировать векторное хранилище, а эмбеддинги и переранжирование по умолчанию используют модели, которыми управляет сервис. Для веб-контента в качестве отправной точки предлагается коннектор источника Amazon Bedrock Web Crawler для управляемых баз знаний. Ему передаются стартовые URL или карты сайта, которые пользователь имеет право индексировать, а краулер обходит их в заданных границах и с заданной частотой запросов. Плановая синхронизация поддерживает базу знаний в актуальном состоянии по мере изменения страниц, а коннектор умеет дожидаться контента, который загружается с помощью JavaScript. Создавать, размещать и обслуживать собственный краулер не нужно, поэтому для большинства публичных сайтов именно этот коннектор является лучшим стартом. Некоторым источникам нужен больший контроль над тем, что попадает в базу знаний. Может понадобиться индексировать только основную область каждой страницы, удалять навигацию и другие шаблонные элементы или присваивать каждому документу собственные метаданные. Для таких случаев авторы предлагают шаг подготовки на основе Crawl4AI, открытого краулера на Python. Этот шаг записывает для каждой страницы файл Markdown и сопроводительный файл метаданных в Amazon Simple Storage Service (Amazon S3), откуда база знаний загружает оба файла через свой источник данных Amazon S3. Путь Crawl4AI предусматривает несколько видов обработки. Во-первых, структурированная подготовка Markdown: генератор DefaultMarkdownGenerator с фильтром обрезки уменьшает навигацию и шаблонные элементы, сохраняя заголовки, списки и таблицы. Поскольку обрезка основана на эвристике, авторы советуют проверять результат на типичных страницах своих сайтов. Во-вторых, ограниченное целевое извлечение: берётся только та область страницы, которую выбирает необязательный CSS-селектор. Обход в ширину ограничивается исходным адресом, рамками по домену, пути или хосту, глубиной, максимальным числом страниц и шаблонами URL. В-третьих, пользовательские метаданные: исходный URL, время обхода, тип контента и собственные атрибуты прикрепляются к каждому документу, чтобы результаты поиска можно было фильтровать. Управляемые и пользовательские базы знаний поддерживают источники Amazon S3, поэтому путь Crawl4AI работает с обоими типами. В этом материале используется управляемая база знаний, а отличия пользовательской базы оговариваются отдельно. Архитектура и настройки примера из репозитория aws-samples рассматриваются как отправная точка, а не как обязательные требования Amazon Bedrock Knowledge Bases. По умолчанию задача AWS Fargate работает в публичной подсети и через интернет-шлюз обращается к указанным сайтам. Роль Crawl4AI заканчивается, когда исходные документы и файлы метаданных подготовлены. Дальше разбор, разбиение на фрагменты, создание эмбеддингов, индексация и поиск выполняет Amazon Bedrock Knowledge Bases. Рабочий процесс запускается по расписанию Amazon EventBridge, которое стартует задачу Amazon Elastic Container Service (Amazon ECS) на AWS Fargate. Задача обходит настроенные сайты и готовит Markdown с файлом метаданных для каждой страницы, затем загружает файлы в bucket Amazon S3, на котором основан источник данных базы знаний, и запускает задание загрузки в Amazon Bedrock Knowledge Bases. Та читает новые и изменённые объекты, разбирает их, применяет выбранную стратегию разбиения, создаёт эмбеддинги и индексирует их в векторном хранилище, которым для управляемой базы знаний управляет Amazon Bedrock. Генеративное приложение затем запрашивает базу и получает релевантные фрагменты или готовый ответ с цитатами. Неконфиденциальные настройки конвейера задача читает из AWS Systems Manager Parameter Store при запуске. Рабочий процесс обрабатывает только публичные страницы и не реализует аутентифицированные сессии. Для сайтов, где нужен вход, сначала следует рассмотреть варианты аутентификации Amazon Bedrock Web Crawler: базовую, по форме и SAML. Расширение примера аутентификацией потребует работы с сессиями, учётными данными в AWS Secrets Manager и проверки безопасности. Во время развёртывания приложение AWS Cloud Development Kit (AWS CDK) упаковывает реализацию в образ контейнера. Когда срабатывает расписание, контейнер запускает скрипт container_entrypoint.py и последовательно выполняет обход, загрузку и запуск загрузки в базу знаний. Основная логика состоит из трёх шагов. Первый шаг — обход и извлечение контента. Модуль crawl.py ограничивает обход, фильтрует и ограничивает URL, проверяет перенаправления и записывает Markdown с файлом метаданных для каждой успешно подготовленной страницы. Метаданные включают исходный адрес, заголовок, время обхода, тип контента и заданные пользователем атрибуты. Amazon Bedrock Knowledge Bases принимает для источников Amazon S3 несколько форматов, включая обычный текст, HTML, Markdown, PDF и DOCX. Markdown выбран потому, что сохраняет заголовки, списки и таблицы и не переносит в загрузку весь исходный HTML. Второй шаг — загрузка в Amazon S3. Каждый Markdown-документ и соответствующий файл метаданных отправляются в настроенный bucket с префиксом s3Prefix. Для файла page.md сопроводительный файл называется page.md.metadata.json. Размер файла метаданных ограничен 10 КБ, и если он превышает лимит, запуск завершается ошибкой до записи любых файлов. Атрибуты записываются в типизированном формате, который принимают оба типа баз знаний. Например, атрибут source_url имеет тип STRING, crawled_at_epoch — тип NUMBER, а content_category — значение web. Загружаются только файлы, созданные текущим обходом, поэтому устаревшие локальные файлы не отправляются. Третий шаг — разбиение, эмбеддинги и индексация. Задание загрузки передаёт каждый документ конвейеру источника данных. По умолчанию управляемая база разбирает файлы своим парсером, который сам выбирает подход к содержимому. Стратегию разбиения выбирают при подключении источника данных, и изменить её позже нельзя, поэтому варианты стоит оценить до создания производственного источника. Доступны три стратегии: стандартная, с фрагментами фиксированного размера в 300 токенов и перекрытием 20 процентов; фиксированного размера, где задаются максимальное число токенов и процент перекрытия; и без разбиения, когда каждый файл становится одним фрагментом. Для смены стратегии нужно создать новый источник данных. Пользовательские базы знаний дополнительно поддерживают семантическое и иерархическое разбиение и другие варианты парсинга. Затем запускается задание загрузки через вызов StartIngestionJob, который работает одинаково для обоих типов баз знаний. Для развёртывания нужны учётная запись AWS, база знаний в регионе, где доступны управляемые базы, источник данных Amazon S3 в статусе AVAILABLE с тем же bucket и префиксом, а также право на обход указанных сайтов. Для пользовательской базы нужно проверить, что векторное хранилище умеет хранить и фильтровать метаданные. Например, индекс Amazon OpenSearch Serverless должен использовать движок faiss, а Amazon Aurora требует колонки под метаданные. В Amazon S3 Vectors на каждый вектор можно прикрепить до 1 КБ метаданных, поэтому атрибуты следует делать короткими. Также нужны база знаний, bucket и стек в одном регионе, рабочая станция с Git, Python 3.10 или новее, Node.js, AWS CLI версии 2, AWS CDK CLI v2 и запущенный Docker-совместимый движок контейнеров. Развёртывание выполняется клонированием репозитория, установкой зависимостей и командой cdk bootstrap, если окружение ещё не подготовлено. Переменной AWS_DEFAULT_REGION нужно задать регион базы знаний, поскольку cdk deploy берёт регион из окружения или профиля. Затем команда cdk deploy получает идентификатор базы знаний, идентификатор источника данных, имя bucket и список разрешённых стартовых адресов, а также ограничения maxDepth и maxPages. Примеры в документации синтаксически корректны, но без замены на свои значения команда укажет на чужой bucket. По умолчанию ограничения позволяют обойти один уровень ссылок и 25 страниц, и их можно повысить после проверки результата. Перед загрузкой можно запустить конвейер локально с флагом --dry-run и посмотреть, какие страницы будут подготовлены. Имя стека фиксировано, поэтому повторный cdk deploy в той же учётной записи и регионе обновит тот же стек. Образ контейнера по умолчанию собирается для ARM64, а если Docker на x86_64 не может собрать такой образ, добавляется параметр cpuArchitecture=X86_64. Если в учётной записи включена блокировка публичного доступа к VPC, задача не сможет выйти в интернет, и тогда нужен режим egressMode=nat с почасовой оплатой шлюза NAT. Стек не создаёт и не меняет базу знаний или её источник данных. При расписании rate(24 hours) первый запуск начинается сразу после создания правила EventBridge. Ход выполнения можно отслеживать командой из вывода TailLogsCommand, а успешный запуск фиксируется в логе записью job_status: COMPLETE. Внеплановый запуск выполняется командой RunTaskCommand после завершения текущего. Список выходных значений стека доступен через aws cloudformation describe-stacks. Остальные настройки, включая границы обхода, расписание, сеть, архитектуру контейнера, мониторинг и запуски по требованию, описаны в руководстве по развёртыванию. После загрузки качество поиска проверяется запросами Retrieve до подключения генерации. Управляемая база использует гибридный поиск, а при модели эмбеддингов по умолчанию результаты дополнительно переранжируются управляемым переранжировщиком. Результаты сужаются фильтрами по метаданным из файлов. По умолчанию пример добавляет к каждой странице атрибут content_category со значением web. Пример запроса через boto3 версии 1.43.32 или новее возвращает до пяти фрагментов со страниц, обойдённых за последние семь дней, с фильтрами равенства и больше по времени обхода. Управляемая база не поддерживает фильтры startsWith и stringContains. Для пользовательской базы тот же фильтр передаётся в vectorSearchConfiguration. Фильтрация по метаданным повышает точность поиска, но не является границей доступа. Если разным пользователям нужны разные страницы, коннектор Amazon S3 для управляемых баз поддерживает контроль доступа на уровне документов через файлы ACL, которые пользователь готовит сам. Пример эти файлы не создаёт. Для генерации ответов с управляемой базой используется операция AgenticRetrieveStream, которая возвращает найденные результаты и ответ с цитатами, а для пользовательской базы — RetrieveAndGenerate. В обоих случаях каждая цитата содержит source_url из файла метаданных, который приложение может показать пользователю как источник. Качество релевантности, покрытия страниц-источников и цитат стоит оценивать при каждом изменении подготовки контента, разбиения или настроек поиска. Каждый плановый запуск создаёт отдельную задачу Fargate, поэтому пересечение запусков ничем не предотвращается и интервал нужно выбирать длиннее ожидаемого времени обхода и загрузки. Сбой не сообщается автоматически, так как в примере нет политики повтора, очереди недоставленных сообщений или сигнала тревоги. Задание загрузки может завершиться со статусом COMPLETE, даже если часть документов не загрузилась, и тогда задача выходит с кодом 0, а причины сбоев попадают в лог. Перед тем как полагаться на расписание, стоит добавить мониторинг, включая сигнал тревоги на эти причины. Каждый запуск оплачивается по ресурсам задачи Fargate, которые по умолчанию составляют 2 vCPU и 4 ГБ памяти. Материал подготовлен нейросетью на основе оригинальной публикации. ИИ может ошибаться в деталях (цифры, имена, даты, цитаты) — для важной информации сверяйтесь с первоисточником.