Перейти к содержанию

Архитектура ИИ-агента и векторной базы данных

Дата: 2026-04-02 Статус: Проектирование

Этот документ подробно описывает устройство векторной базы данных, сервиса векторизации, архитектуру взаимодействия с ИИ-агентом и рекомендации по выбору LLM для проекта Arkhyz.CLUB.

1. Векторная база данных (Vector DB)

В качестве векторного хранилища используется Supabase (PostgreSQL) с расширением pgvector. Это позволяет хранить векторы в той же базе, где лежат реляционные данные, избегая проблем с синхронизацией между разными хранилищами (например, между Postgres и Pinecone/Milvus).

1.1. Структура хранения

Создается таблица (или несколько таблиц) для хранения векторизованных "чанков" (кусков текста). Пример структуры document_embeddings: - id (uuid, primary key) - content (text) — исходный текст (описание отеля, текст правила, отзыв). - metadata (jsonb) — метаданные для фильтрации (например, {"type": "hotel", "item_id": "uuid", "tags": ["family", "spa"]}). - embedding (vector(1536)) — векторное представление текста (размерность 1536 для OpenAI text-embedding-3-small).

1.2. Индексация

Для быстрого поиска по миллионам записей используется индекс HNSW (Hierarchical Navigable Small World). Он обеспечивает высокую скорость (O(log N)) и точность (Recall) при косинусном поиске. 

CREATE INDEX ON document_embeddings USING hnsw (embedding vector_cosine_ops);

2. Взаимодействие с векторным сервисом (Vector Service)

Векторный сервис — это модуль внутри нашего Backend API (FastAPI), который отвечает за два основных процесса: Ingestion (загрузка данных) и Retrieval (поиск).

2.1. Процесс векторизации (Ingestion Pipeline)

Срабатывает при добавлении или обновлении контента (отелей, туров, статей базы знаний). 1. Событие: Срабатывает триггер в Postgres или отправляется задача в Celery Worker при сохранении сущности. 2. Chunking (Разбиение): Длинный текст (например, статья на 5000 символов) разбивается на логические куски (чанки) по 500-1000 токенов с небольшим перекрытием (overlap), чтобы не терять контекст на стыках. 3. Embedding (Векторизация): Сервис отправляет текст чанков в Embedding API (например, OpenAI) и получает массив чисел (вектор). 4. Storage (Сохранение): Векторы вместе с метаданными записываются в таблицу document_embeddings в Supabase.

2.2. Процесс семантического поиска (Retrieval Pipeline)

Срабатывает, когда пользователь задает абстрактный вопрос (например, "Где тихо и есть вид на горы?"). 1. Запрос пользователя векторизуется через ту же Embedding-модель. 2. FastAPI сервис выполняет SQL-запрос к pgvector: 

SELECT content, metadata, 1 - (embedding <=> '[0.01, 0.02, ...]') AS similarity
FROM document_embeddings
WHERE metadata->>'type' = 'hotel' -- pre-filtering (Hybrid Search)
ORDER BY embedding <=> '[0.01, 0.02, ...]'
LIMIT 5;
3. Сервис возвращает найденные текстовые фрагменты (Context), которые затем передаются LLM.

3. Архитектура внедрения ИИ-агента (Agentic RAG)

Простой RAG (поиск + ответ) не подходит для туристической платформы, так как он не может проверять наличие мест, бронировать или фильтровать по строгим датам. Поэтому применяется паттерн Agent with Tool Calling (Function Calling).

3.1. Компоненты системы

  1. Frontend (Chat UI): Виджет чата, поддерживающий Streaming (потоковый вывод текста) и рендеринг кастомных React-компонентов (карточек отелей/туров).
  2. AI Orchestrator (FastAPI / LangGraph / LlamaIndex): Ядро агента на бэкенде. Управляет историей диалога, вызывает LLM и выполняет инструменты (Tools).
  3. Memory (Redis / Postgres): Хранилище контекста сессии (чтобы агент помнил даты и предпочтения пользователя из предыдущих сообщений).
  4. Tools (Инструменты):
  5. search_knowledge — поиск по векторной базе (для абстрактных вопросов и FAQ).
  6. check_availability — прямой SQL/API запрос в БД для проверки наличия мест на конкретные даты (без векторов!).
  7. book_service — инструмент для создания драфта бронирования.

3.2. Флоу взаимодействия (Пайплайн)

  1. User: "Найди тихое место на 10-15 мая для двоих" -> отправляется на Backend.
  2. Orchestrator загружает историю сессии и отправляет запрос в LLM вместе с описанием доступных Tools.
  3. LLM (Thought Process): Понимает, что нужно найти "тихое место" (семантика) и проверить доступность на 10-15 мая.
  4. LLM вызывает Tool 1: search_knowledge(query="тихое место для двоих", type="hotel").
  5. Orchestrator выполняет векторный поиск в pgvector, находит отели A и B, возвращает их LLM.
  6. LLM вызывает Tool 2: check_availability(hotel_ids=[A, B], check_in="2026-05-10", check_out="2026-05-15").
  7. Orchestrator делает классический SQL-запрос к таблице бронирований. Отель A занят, отель B свободен. Возвращает данные в LLM.
  8. LLM генерирует финальный ответ: Формирует приветливый текст и JSON со ссылкой на Отель B.
  9. Frontend показывает текст и рендерит карточку Отеля B.

4. Рекомендуемые LLM и модели

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

4.1. Модели для векторизации (Embeddings)

  • OpenAI text-embedding-3-small (Рекомендуется):
    • Плюсы: Очень дешевая (~$0.02 за 1 млн токенов), быстрая, поддерживает размерность до 1536, отлично понимает русский язык.
    • Минусы: Vendor lock-in (при смене модели придется перевекторизовать всю базу).
  • BGE-m3 / Nomic-Embed-Text (Локальные / HuggingFace):
    • Плюсы: Бесплатно, данные не покидают контур серверов.
    • Минусы: Требует GPU на сервере или потребляет много CPU, сложнее в поддержке.

4.2. Модели для ИИ-Агента (Reasoning & Function Calling)

Агенту требуется высочайший уровень логики и строгое следование JSON-схемам для вызова инструментов.

  • OpenAI GPT-4o-mini (Основная "рабочая лошадка"):
    • Плюсы: Идеальное соотношение цена/качество. Очень быстрая, отлично справляется с Function Calling. Подходит для 90% пользовательских запросов.
    • Стоимость: ~$0.15 за 1 млн токенов (вход) / ~$0.60 за 1 млн токенов (выход).
  • OpenAI GPT-4o или Anthropic Claude 3.5 Sonnet (Для сложных задач):
    • Плюсы: Способны распутывать самые сложные и запутанные запросы туристов (например, многодневные составные туры). Минимальный процент галлюцинаций.
    • Минусы: В 10-20 раз дороже, чем mini-версии. Медленнее (до 5-10 секунд на генерацию ответа с тулзами).
    • Применение: Динамическое переключение (Routing) — простые вопросы решает 4o-mini, сложные планировки маршрутов передаются в 4o или Claude.
  • Локальные LLM (Llama 3 8B-Instruct / Qwen 2.5 7B):
    • Плюсы: Полный контроль над данными, отсутствие оплаты за токены.
    • Минусы: Гораздо хуже справляются с Function Calling на русском языке. Требуют мощных GPU-серверов (например, RTX 3090/4090 или A10G), что нивелирует экономию на API для малых проектов. Не рекомендуются на текущем этапе.

Вывод

Оптимальный стартовый стек для Arkhyz.CLUB: Supabase pgvector + FastAPI + LangChain + OpenAI text-embedding-3-small + GPT-4o-mini. Эта связка обеспечит быстрый Time-to-Market, надежную работу Function Calling и низкие эксплуатационные расходы.