Новое руководство предлагает практическую архитектуру production‑ready RAG‑пайплайна: эмбеддинги и LLM‑инференс выполняются через Model Studio, а векторный поиск и хранение — в Hologres. Это важно для корпоративных сценариев — поиска по документам, внутренних копилотов и Q&A по документации — поскольку сочетание управляемого инференса и SQL‑совместимого хранилища упрощает интеграцию с существующими BI и доступами. Авторы разбивают архитектуру на четыре ключевых слоя: инжест документов (PDF, Markdown, веб‑страницы, базы знаний), разбиение на чанки, генерация эмбеддингов с последующим хранением векторов и метаданных, и извлечение top‑k релевантных чанков для передачи в чат‑модель. В примере демонстрируется оркестрация рабочих потоков с помощью n8n; этапы явно перечислены от инжеста и чанкинга до возврата ответа с указанием источников.
Hologres в материале представлен как хранилище, поддерживающее векторный поиск при сохранении совместимости с SQL/Postgres‑подобными workflow. Такое сочетание делает возможным объединять ретривал и аналитические запросы в одной системе, что упрощает исполнение гибридных задач — например, фильтрацию результатов по бизнес‑метрикам одновременно с поиском по семантике. Отдельно авторы отмечают практические преимущества хранения эмбеддингов в Hologres: векторы можно хранить вместе с ID документов, тегами доступа и бизнес‑атрибутами, а затем фильтровать поиск по арендаторам, департаментам или типам документов. Это облегчает реализацию многоарендных решений и централизованный контроль доступа, делая возвращаемые контексты закономерно фильтруемыми по корпоративным условиям.
Роль Model Studio в описанном пайплайне — генерация эмбеддингов и запуск LLM‑инференса без необходимости самим управлять инфраструктурой моделей. Авторы подчёркивают критическую важность качества эмбеддингов: от этого напрямую зависит точность извлечения релевантных фрагментов и, следовательно, качество ответов, включая способность привязывать ответы к источникам и снижать число «галлюцинаций».
В руководстве также упоминаются Vector Retrieval Service и Milvus для тех случаев, когда предпочтительнее отдельный управляемый векторный движок. Авторы предлагают архитектурный выбор: Hologres, если приоритет — унификация SQL‑операций и аналитики вместе с векторным поиском; Milvus/Vector Retrieval Service, если нужен отдельный управляемый движок. В заключении приводятся основные практики для надёжного RAG‑пайплайна: чанкинг с сохранением контекста, генерация качественных эмбеддингов, хранение векторов с метаданными, retrieval top‑k и возврат ответа с указанием источников.
Источники
Ответы (0)
Пока нет ответов в этой теме.