Архитектура данных и знаний: базы знаний, векторные хранилища, индексирование
Добро пожаловать в главу о архитектуре данных и знаний в контексте разработки AI‑агентов для корпоративного использования. Здесь мы разберёмся, как структурировать данные и знания так, чтобы интеллектуальные агенты могли быстро и надёжно находить релевантную информацию, отвечать на запросы сотрудников, обслуживать клиентов и поддерживать бизнес‑процессы.
Ключевые концепции:
- База знаний (knowledge base, KB) — хранилище материалов: документы, схемы, правила, FAQ, статьи, записи чатов и т. п., снабжённое метаданными и структурой для поиска.
- Векторное хранилище — база, где хранятся эмбеддинги (векторы) документов или их фрагментов, предназначенные для близкого по смыслу поиска.
- Индексирование — организация быстрого доступа к данным: индексы для текстовых данных (инвертированные), индексы для векторных данных (HNSW, IVF, PQ и пр.), а также гибридные подходы.
- RAG (Retrieval-Augmented Generation) — подход, где генеративная модель дополняется внешними источниками знаний через поиск и пере‑ранжировку документов перед генерацией ответа.
Для корпоративных задач критично сочетать возможность быстрого поиска по большой массе документов с надёжностью, безопасностью и соответствием регуляторным требованиям. Мы рассмотрим как теорию, так и практику: какие архитектурные решения выбрать, какие инструменты применить, какие сложности учесть и как минимизировать риски.
Архитектура данных и знаний: что и зачем
Архитектура данных и архитектура знаний — это две связанные, но разные перспективы на одну и ту же проблему: как собрать данные так, чтобы их можно эффективно преобразовывать в знания и знания — эффективно использовать агентами.
- Архитектура данных сосредоточена на потоках, моделях данных, хранении, согласованности и доступе к данным. Она определяет, где лежат файлы, как структурированы таблицы, какие процессы очистки и трансформации проходят данные.
- Архитектура знаний акцентирует внимание на смысловом уровне: какие знания должны быть извлечены из данных, как организовать понятия, связи между документами, правила и онтологии, как поддерживать две вещи одновременно: актуальность и объяснимость.
Для AI‑агентов важно знать две вещи:
- где искать источник истины (база знаний и её контент);
- как получить удобный вид для модели: текст, структурированные поля, эмбеддинги.
Базы знаний: типы и проектирование
Базы знаний можно условно разделить на несколько типов:
- Документная база знаний: набор документов, мануалов, регламентов, инструкций. Часто сопровождается извлечением ключевых сущностей и фрагментов, метаданными (дата, автор, источник).
- Знаниевая база/граф знаний: концепции и связи между ними (понятия, правила, зависимые сущности). Часто реализуется как граф данных.
- FAQ и сценарии обслуживания: вопросы‑ответы, типовые случаи обращения к поддержке, сценарии решений.
- Метаданные и контекст: информация о документах (язык, источник, уровень секретности, дата публикации), которая помогает фильтровать и ранжировать.
Проектирование KB начинается с задач:
- какие запросы будут к агенту часто и какие источники он должен охватывать;
- какие уровни доступа и безопасность;
- какие требования к обновлениям и версии;
- как обеспечить полноту и точность знаний.
Векторные хранилища: зачем они нужны и как работают
Традиционный полнотекстовый поиск хорошо работает для словесных совпадений, но современные AI‑агенты зачастую требуют большего смысла: умение находить близкие по смыслу фрагменты, даже если в них нет точного соответствия слов.
Векторное хранилище хранит эмбеддинги документов или их фрагментов. Ключевые концепты:
- Embedding — числовой вектор, который детерминированно отражает семантику текста или множества атрибутов.
- Метрика близости — расстояние между векторами: COSINE, Euclidean, IP (inner product).
- Индексирование — создание структуры данных, позволяющей быстро находить ближайшие соседи по векторному пространству.
- Индексы для NN‑поиска: HNSW (Hierarchical Navigable Small World), IVF (Inverted File with Residual Quantization), PQ (Product Quantization) и их гибриды.
Зачем нужен векторный слой:
- быстрый поиск релевантных документов по смыслу запроса;
- возможность работы с неструктурированными данными и перевода их в контекст для модели;
- поддержка динамического обновления знаний без перегрузки всей базы.
Индексирование: ключевые подходы и trade‑offs
Инвертированные индексы (для текста): эффективны для keyword‑поиска, поддерживают точное соответствие слов и фраз, просты в реализации.
Векторные индексы: предназначены для nn‑поиска по эмбеддингам. Основные алгоритмы:
- HNSW: быстрое приближённое расстояние, хорошо масштабируется, эффективен на больших наборах.
- IVF: разделение пространства на кластерные векторы, поиск в ближайших кластерах.
- PQ: компрессия векторов с сохранением близости, уменьшение памяти, но иногда может повредить точность.
Гибридные индексы: сочетание инвертированных и векторных индексов для поддержки и точности и скорости / релевантности. Часто реализуется в рамках "hybrid search" в современных системах.
Методы выбора зависят от требований:
- latency (микросекунды — миллисекунды);
- объём данных (миллионы–миллиарды документов);
- частота обновления данных (частые обновления требуют более быстрой индикации изменений);
- стоимость инфраструктуры и эксплуатационные риски.
Архитектура RAG для корпоративных агентов
RAG-пайплайн обычно включает:
- Ingestion и нормализацию источников знаний (PDF, документы, сайты, письма, чаты).
- Предобработку: очистку, сегментацию документов на логические фрагменты, извлечение структурированных метаданных.
- Генерацию эмбеддингов с помощью языковых моделей (модели трансформеров, мультиязычные модели для русского языка).
- Сохранение эмбеддингов в векторном хранилище, хранение метаданных и полнотекстовых текстов — в соответствующих системах.
- Поиск и переранжировку: первое прохождение через близость по векторам, второе — через более детальный ранжировщик (cross‑encoder, линейный ранжировщик или BERT‑модель, обученная на релевантности).
- Интеграция с генеративной моделью: предоставление контекста (резюме, цитаты) и формирование ответа.
- Мониторинг и обновление: отслеживание качества выдачи, обновление embedding‑индексов, версия документации, аудит доступа.
Важно помнить: в промышленной среде нередко требуется гибридный подход, где первый слой — быстрый поиск по словам и векторная близость, второй слой — семантический рейтинг и валидация на соответствие политике и регламентам.
Метаданные, происхождение и безопасность данных
- Пропускная способность и точность зависят от качества метаданных: источник, язык, дата публикации, версия документа.
- Локализация данных и юридические требования: особенно в РФ и странах СНГ требования к локализации, хранению и обработке персональных данных.
- Прозрачность источников и трассируемость: кто и когда обновлял документ, какая версия эмбеддинга применена.
- Безопасность: контроль доступа, шифрование на покое и в транзите, аудит операций, управление ключами.
Практические примеры
Ниже представлены практические сценарии и архитектурные решения, которые можно реализовать как в открытом, так и в отечественном контексте.
Типовая архитектура RAG с Milvus + PostgreSQL + Elasticsearch
- Источники знаний: PDF и Word‑документы, внутренние чаты, инструкции.
- Ингестинг: конвертация документов в текст, разбиение на фрагменты (примерно 200–500 слов на фрагмент), извлечение метаданных (Источник, Дата, Автор, Язык).
- Эмбеддинги: русскоязычные модели на базе sentence‑transformers (например, ruSBERT, multilingual‑mBERT‑варианты).
-
Хранилища:
- Векторное: Milvus 2.x (HNSW) для эмбеддингов фрагментов.
- Метаданные: PostgreSQL (или Postgres Pro, локализованный дистрибутив) для документов и фрагментов.
- Текстовый индекс: Elasticsearch или OpenSearch для поддержки полнотекстового поиска по слову и фразам.
- Поиск: сначала векторный поиск в Milvus, затем ранжирование Cross‑Encoder (например, DistilBERT‑для ранжирования), затем fallback к keyword‑поиску.
- Визуализация и аудит: Dashboards для мониторинга качества выдачи и обновлений.
- Пример конфигурации: docker‑compose с Milvus, PostgreSQL, Elasticsearch.
Code snippet: создание коллекции Milvus (упрощённо)
# pymilvus >=2.x
from pymilvus import (
connections, FieldSchema, CollectionSchema,
DataType, Collection
)
connections.connect("default", host="localhost", port="19530")
# Определяем схему: id, source metadata, и embedding размером 768
fields = [
FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
FieldSchema(name="doc_id", dtype=DataType.STRING, max_length=128),
FieldSchema(name="content", dtype=DataType.STRING, max_length=65535),
FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=768)
]
schema = CollectionSchema(fields, "KB collection with embeddings")
collection = Collection(name="kb_embeddings", schema=schema)
Code snippet: вставка и поиск
import numpy as np
from pymilvus import utility
# пример вставки
embeddings = np.random.rand(10, 768).astype('float32') # заменить на реальные эмбеддинги
docs = ["doc_"+str(i) for i in range(10)]
ids = collection.insert([ids, docs, texts, embeddings])
# создание индекса
collection.create_index(field_name="embedding", index_params={
"index_type": "HNSW", "params": {"m": 16, "efConstruction": 200}
})
# запрос
query_vec = np.random.rand(1, 768).astype('float32')
search_params = {"metric_type": "COSINE", "params": {"ef": 50}}
results = collection.search(query_vec, "embedding", search_params, limit=5)
Code snippet: простая архитектура контейнеров
version: '3.8'
services:
milvus:
image: milvusdb/milvus:2.x.x-cpu
container_name: milvus
ports:
- "19530:19530"
environment:
-TZ=UTC
postgres:
image: postgres:15
container_name: pgkb
environment:
POSTGRES_PASSWORD: example
POSTGRES_DB: kb
ports:
- "5432:5432"
elastic:
image: docker.elastic.co/elasticsearch/elasticsearch:8.8.0
container_name: es
environment:
- discovery.type=single-node
- ES_JAVA_OPTS=-Xms512m -Xmx512m
ports:
- "9200:9200"
Векторное хранение с Weaviate и отечественными решениями
Weaviate как популярная open‑source площадка для векторного поиска поддерживает модули для интеграции с языковыми моделями и может работать в локальной среде. В контексте российских проектов часто выбирают:
- ClickHouse с векторной поддержкой (vector‑type) для больших аналитических нагрузок и интеграции с существующими аналитическими пайплайнами.
- PostgreSQL + pgvector для локальной совместимости и управляемой инфраструктуры.
- Postgres Pro с pgvector для отечественной поддержки и сертифицированных сборок.
Пример архитектуры на базе ClickHouse:
- Сентезируем содержимое документов в текстовую форму.
- Храним векторную колонку типа Array(Float32) и используем векторные функции для поиска по соседству.
- Поиск: сначала векторный нюанс, затем полнотекстовый поиск.
Пример запросов в ClickHouse (упрощённо):
- Создать таблицу с полем vector Float32[], индексировать через нейронный поиск.
- Выполнить NN‑поиск через функцию vectorDistance или специализированные KPI.
3) Практические примеры интеграции с отечественными решениями
Postgres Pro + pgvector:
- pgvector — расширение PostgreSQL для хранения и поиска по векторам.
- Локално разворачиваемое решение, поддерживает расширение в отечественных инфраструктурах и соответствует требованиям локализации.
- Пример SQL для добавления вектора и выполнения поиска по косинусному сходству: SELECT id, content FROM kb WHERE embedding <=> '[0.1, 0.2, ...]' ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 5;
ClickHouse в роли аналитического слоя и интеграции с русскоязычными пайплайнами.
Кодовый пример полного пайплайна
Ниже приводится упрощённый порядок действий и примеры кода, иллюстрирующие создание KB, генерацию эмбеддингов и поиск:
- Этап 1: загрузка документов, сегментация и извлечение метаданных.
- Этап 2: генерация эмбеддингов на русском языке.
- Этап 3: сохранение в Milvus (векторный слой) и PostgreSQL (метаданные).
- Этап 4: выполнение запроса к агенту: векторный поиск + ранжирование.
Python‑пример генерации эмбеддингов (использование мультиязычной модели)
from transformers import AutoTokenizer, AutoModel
import torch
model_name = "sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModel.from_pretrained(model_name)
def embed(texts):
inputs = tokenizer(texts, padding=True, truncation=True, return_tensors="pt")
with torch.no_grad():
model_output = model(**inputs)
embeddings = model_output.last_hidden_state.mean(dim=1)
return embeddings / embeddings.norm(dim=1, keepdim=True)
texts = ["Какой документ нужен для запроса на отпуск?", "Как обновить пароль в корпоративной системе?"]
vecs = embed(texts).numpy()
- Этап 5: вставка в Milvus и PostgreSQL
# вставка в Milvus (как ранее)
# вставка в PostgreSQL
import psycopg2
conn = psycopg2.connect(dbname="kb", user="postgres", password="example", host="localhost")
cur = conn.cursor()
cur.execute("INSERT INTO kb_meta (doc_id, title, source, language) VALUES (%s, %s, %s, %s)", (doc_id, title, source, "ru"))
conn.commit()
- Этап 6: пример запроса
# запрос к Milvus по вектору
# затем ранжирование и выбор релевантных документов
Примечание: реальные реализации требуют детальной настройки архитектуры: конвейеры ETL, управление версиями документов, обработку дубликатов, управляемый доступ, тестирование качества ранжирования, а также мониторинг.
Пример структуры данных
Коллекция/таблица документов
- doc_id (строка / UUID)
- title (строка)
- content (TEXT)
- source (строка)
- created_at (timestamp)
- language (RU/EN/อื่น)
- metadata (JSON)
-
embedding (VECTOR
)
Метаданные и индексы
- postgres: индекс по doc_id, GIN/Btree для текстового поля
- milvus: индекс по embedding (HNSW и/или IVF)
Конкретные алгоритмы индексации
HNSW: по умолчанию лучший выбор для большинства задач NN‑поиска по эмбеддингам благодаря балансам между скоростью и точностью.
- Параметры: M (соединение графа), efConstruction (пласткость дерева поиска на этапе построения индекса).
IVF/PQ: экономия памяти и скорости на больших объёмах при небольшом падении точности.
- Параметры: nlist (количество кластеров), nprobe (число кластеров для точного прогона).
Инвертированная часть: для текста и метаданных — обеспечивает хорошую точность и управляемость.
Метрическая совместимость и выбор модели
- Косинусное сходство — часто лучше для нормированных эмбеддингов.
- Л2‑нормализация — альтернативный выбор в зависимости от модели.
Этапы внедрения и миграции
- Определение набора источников знаний и примеров запросов пользователей.
- Развертывание подходящей векторной базы и связанного слоя метаданных.
- Обучение первых эмбеддингов и базовых ранжировщиков.
- Постепенная доставка и A/B тестирование изменения ранжирования.
- Мониторинг качества (Recall@k, MRR, coverage), обновление моделей и индексов.
Риски и ограничения
- Качество данных: шум, дубликаты, неправильная метаинформация приводят к некачественным ответам.
- Эмбеддинги и drift: со временем семантика документов может меняться; необходимо планировать обновления эмбеддингов и переиндексацию.
- latency и вычислительные затраты: векторные операции требуют мощных графических процессоров или оптимизированных CPU‑решений; важно соблюдать баланс между задержками и точностью.
- Безопасность и соответствие требованиям: данные сотрудников и клиентов часто подпадают под регламентированные требования. Нужны строгие политики доступа, аудит, шифрование, локализация в целях соответствия.
- Вендорная зависимость: выбор конкретной векторной базы может привести к ограничению гибкости, особенно если организация планирует масштабирование или смену технологий.
- Сложности внедрения: интеграция с существующими системами документооборота, системами идентификации и аутентификации, логами и мониторингом.
- Экономические риски: лицензии, поддержка, апгрейды и DevOps‑ресурсы — стоимость проекта может существенно варьироваться.
Рекомендации по снижению рисков:
- Экспериментируйте в тестовой среде с несколькими стеками: Milvus + PostgreSQL + Elasticsearch против ClickHouse с векторной поддержкой.
- Реализуйте гибридный поиск: сочетайте векторный поиск и полнотекстовый индексацию; добавляйте ранжирование на уровне модели.
- Введите версионирование документов и явную политику удаления устаревших материалов.
- Обеспечьте безопасность и соответствие: доступ по ролям, аудит, шифрование, локализация.
- Проводите регулярные тестирования качества поиска и обновляйте модели эмбеддингов.
Выводы
- Архитектура данных и знаний для корпоративных AI‑агентов требует внимания к двум уровням: структурированию данных и созданию осмысленных векторных представлений знаний.
- Выбор векторного хранилища и индексов зависит от требований к латентности, объёму данных и частоте обновлений. В большинстве случаев эффективна гибридная архитектура: документная база + векторный слой + полнотекстовый индексовый слой.
- Практические решения включают открытые системы (Milvus, FAISS, Weaviate, ClickHouse с vector‑модулями) и отечественные решения (PostgreSQL + pgvector, Postgres Pro, похоже на российский рынок для локализации). Использование российского стека часто обеспечивает лучшую совместимость с локальным законодательством и существующей инфраструктурой.
- Внедрение требует внимательного подхода к качеству данных, безопасности, мониторингу и управлению версиями, иначе риск «платформы» превысит пользу от ускоренного доступа к знаниям.
FAQ (Вопросы и ответы)
1) Что такое база знаний и чем она отличается от векторного хранилища?
- База знаний — это набор источников информации (документы, FAQ, инструкции, SOP) с метаданными, предназначенный для извлечения фактов и контекста. Векторное хранилище содержит эмбеддинги этих материалов для быстрого поиска по смыслам. В реальной архитектуре они работают вместе: текст и метаданные в KB, векторные представления — в хранилище эмбеддингов.
2) Что значит индексация в контексте AI‑агентов?
- Индексация обеспечивает быстрый доступ к данным. Инвертированные индексы ускоряют текстовый поиск, векторные индексы ускоряют поиск по смыслу. Гибридные решения позволяют достигать баланса точности и скорости.
3) Какие технологии стоит рассмотреть для открытого стека?
- Milvus (векторный движок), FAISS (библиотека NN‑поиска), Weaviate (облегчённое управление KB), ClickHouse (для аналитики и векторной поддержки), PostgreSQL с pgvector (для локализованных решений). Для русского языка хорошо подходят мультиязычные модели и русскоязычные версии BERT/Roberta/RuBERT.
4) Какие практики по архитектуре RAG?
- Разделяйте хранение текста и эмбеддингов, применяйте гибридный поиск, используйте повторную валидацию и переиндексацию по мере обновления знаний, применяйте reranking через Cross‑Encoder, добавляйте политикам на валидацию контекста.
5) Какие российские решения можно использовать?
- PostgreSQL + pgvector, Postgres Pro (локальная версия PostgreSQL в РФ), ClickHouse с vector‑модулем. Эти решения обеспечивают локализацию данных и удобную интеграцию в российские инфраструктуры.
6) Как обеспечить безопасность и соответствие требованиям?
- Контроль доступа по ролям, аудит, шифрование на покое и в транзите, сегментация данных по уровню секретности, локализация хранилищ, управление ключами. Важно наличие политики удаления устаревших материалов и журнала изменений.
7) Как обновлять знания без сбоев в работе агентов?
- Разработайте пайплайны обновления: периодическая переиндексация эмбеддингов, версионирование документов, A/B тестирование нового индекса, откат к прошлой версии при снижении качества.
8) Как измерять качество поиска?
- Метрики: Recall@k, MRR@k, NDCG@k, точность на тестовом наборе вопросов, качество ранжирования Cross‑Encoder. Важно иметь набор качественных тестов, соответствующих реальным запросам сотрудников.
9) Как начать внедрять архитектуру в компанию?
- Сформируйте минимально жизнеспособный продукт (MVP): набор ключевых источников знаний, векторный слой (Milvus или ClickHouse), простой ранжер, базовый KB‑интерфейс. Затем постепенно расширяйте источники, улучшайте качество эмбеддингов и внедряйте режимы мониторинга.
10) Какие риски наиболее критичны и как их минимизировать?
- Риск некорректных ответов (hallucinations) — используйте верификацию источников, подтягивайте факты из документов и применяйте дополнительный слой проверки. Риск утечки данных — усиливайте безопасность, ограничение доступа и локализацию. Риск устаревания данных — планируйте переиндексацию и обновление контента. Риск зависимости от конкретной платформы — проектируйте архитектуру с модульными компонентами и гибкой миграцией между технологиями.
