Качество ответов ИИ-ассистента на 70% зависит от базы знаний, а не от модели. Правильная архитектура — RAG (поиск релевантных фрагментов + генерация ответа), чанки по 300–800 токенов и регулярная поддержка базы. Инвестируйте в контент больше, чем в модель.
Что такое база знаний для ИИ
База знаний — это структурированное хранилище документов компании, по которому ИИ ищет информацию перед тем, как сформулировать ответ. Без базы модель генерирует ответ «из головы», что приводит к галлюцинациям (читайте отдельную статью). С базой — модель опирается на конкретные источники и может дать ссылку.
Архитектура, которая для этого используется, — RAG (Retrieval-Augmented Generation). Это золотой стандарт корпоративных ИИ-ассистентов с 2024 года.
Как работает RAG
Вопрос пользователя
↓
Векторизация вопроса
↓
Поиск релевантных чанков в базе (топ-5)
↓
Передача контекста + вопроса в LLM
↓
Ответ со ссылкой на источник
Ключевые компоненты:
- Embedding-модель переводит текст в векторы (YandexGPT Embeddings, GigaChat, ru-en модели).
- Векторная база (Qdrant, pgvector, Yandex Managed Service для ClickHouse) хранит чанки и быстро ищет похожие.
- Ранжирование (опционально) переупорядочивает результаты по релевантности.
- LLM генерирует финальный ответ, опираясь только на найденный контекст.
Разбиение на чанки
Это самый недооценённый этап. Качество ответа напрямую зависит от того, как нарезаны документы.
| Параметр | Рекомендация |
|---|---|
| Размер чанка | 300–800 токенов |
| Перекрытие | 50–100 токенов |
| Границы | По абзацам и заголовкам, не посимвольно |
| Метаданные | Категория, раздел, источник, дата обновления |
Простая ошибка — резать документ по фиксированному числу символов. При этом один чанк может содержать половину одного раздела и половину другого, и поиск теряет точность. Режьте по структуре документа.
Источники и форматы
Хорошая база — это не «свалка файлов», а кураторский набор:
- регламенты и инструкции;
- FAQ из реальных обращений;
- описание продуктов и услуг;
- кейсы и примеры;
- база закрываемых тикетов поддержки.
Форматы: Markdown, структурированный HTML, plain text. PDF работает, но требует вычитки — таблицы и схемы часто ломаются.
Качество базы
База — это не «чем больше, тем лучше». Лишние документы размывают поиск и ухудшают точность. Метрики:
- Coverage — доля реальных вопросов, на которые в базе есть релевантный фрагмент. Цель — 90%+.
- Precision@5 — из пяти найденных чанков сколько реально полезных. Цель — 3+.
- Доля правильных ответов — на тестовом наборе из 50–100 вопросов. Цель — 85–92%.
Ниже 80% — пора чистить: удалять дубли, объединять похожее, переписывать непонятные фрагменты.
Поддержка в актуальном состоянии
| Действие | Частота |
|---|---|
| Пополнение новыми документами | Еженедельно |
| Удаление устаревших | Раз в месяц |
| Аудит на дубли и конфликты | Раз в квартал |
| Пересоздание векторного индекса | После значимых изменений |
| Тест на наборе вопросов | После каждого обновления |
Поддерживает базу контент-менеджер или эксперт, а не программист. Это важно: программист напишет код, но не разберётся, какие документы нужны клиентам.
Безопасность данных
В базе часто лежат коммерческая тайна и ПД. Архитектурные меры:
- разделение прав: ассистент видит только релевантные документы для текущего пользователя;
- обезличивание перед загрузкой в векторную базу (читайте «ИИ и персональные данные»);
- шифрование и аудит доступа.
Когда RAG не нужен
- База маленькая (до 20 документов) — проще засунуть весь контекст в промпт.
- Вопросы типовые и их мало — хватит набора шаблонов.
- Данные меняются слишком быстро (несколько раз в день) — RAG не успевает обновляться.
В этих случаях выбирают in-context learning или классический чат-бот. Подробнее — в материале «ИИ-ассистент vs чат-бот». Главное правило RAG: garbage in — garbage out. Хорошая база даёт хороший ответ, плохая — никакая модель не спасёт.
Комментарии · 0