База знаний

Зачем это нужно

LLM знает общий мир: Википедию, новости, программирование, историю. Но не знает вашу компанию — ваши тарифы, регламенты, FAQ, прайс-лист 2026 года, условия договоров, внутренние процедуры.

Если просто спросить — агент начнёт выдумывать правдоподобно, и клиент поверит. Это называется «галлюцинации LLM» и это самая большая проблема чат-ботов без RAG.

Сравнение — бот без базы знаний vs с ней

Что ещё даёт база знаний

Как это работает (RAG)

RAG (Retrieval-Augmented Generation) — «генерация с опорой на найденное». Академическое название технологии.

Три шага

Визуализация

Шаг 1 — Индексация (офлайн):

[Документы] → [Чанкер] → [Embedding-модель] → [Qdrant]
               ↓             ↓
          куски 1000        векторы
          символов          [0.12, -0.34, 0.91, ...]


Шаг 2 — Поиск (при запросе клиента):

[Вопрос клиента] → [Embedding-модель] → [Qdrant: найди ближайшие]
                                               ↓
                                          [5 релевантных чанков]
                                               ↓
                                          [добавлены в промпт LLM]
                                               ↓
                                          [Ответ клиенту]

Коллекции

Коллекция — папка документов с общей темой. Основная единица организации знаний в платформе.

Зачем делить на коллекции

Плохо: одна гигантская коллекция со всеми документами компании подряд.

Почему:

• Агент поддержки получает в контекст кусочки из юр-документов → путается.
• Агент продаж видит регламенты HR → ответы странные.
• Невозможно дать разным агентам разный доступ.

Хорошо: коллекции по темам, каждому агенту — только нужное.

Типичное разделение

• product-docs — инструкции по продуктам, описания услуг.
• pricing — прайс-листы, тарифные планы.
• faq — часто задаваемые вопросы клиентов.
• internal-policies — внутренние регламенты (не показываем клиенту, но используем как контекст).
• legal — юр. документы (договоры, оферты).
• hr — кадровые документы (для HR-бота).

Привязка к агенту

В настройках агента отмечаете галочками доступные коллекции:

• Агент поддержки — видит faq + product-docs.
• Юр-бот — только legal.
• HR-бот для соискателей — только hr.
• Менеджер по продажам — pricing + product-docs.

Агент ищет только в привязанных коллекциях. Это даёт:

• Точность. Не находит «лишнее».
• Безопасность. HR-бот не увидит тайн продаж.
• Скорость. Поиск в 1 коллекции быстрее поиска по всей базе.

Форматы документов

Платформа принимает и обрабатывает:

• PDF — включая сканы. Для отсканированных файлов применяется OCR (оптическое распознавание текста). Качество OCR зависит от разрешения скана и языка.
• Word (.docx) — с форматированием, таблицами, списками.
• Excel / CSV — каждая строка становится чанком. Полезно для каталогов, таблиц цен.
• Markdown / TXT — plain text с минимальной разметкой.
• HTML — очищается от тегов, извлекается текст.
• PowerPoint (.pptx) — текст из слайдов, заголовки, заметки.
• Изображения (PNG, JPG) — через OCR, если на картинке есть текст.

Лимит на файл: 50 МБ на Free-плане, 200 МБ на Pro, без лимита на Enterprise.

Что лучше работает

• Markdown и чистый текст — идеальная ситуация, RAG работает максимально точно.
• Word с текстом — отлично.
• PDF с текстовым слоем — хорошо.
• Отсканированный PDF с OCR — средне, зависит от качества скана.
• Презентации — обычно плохо: мало текста, много картинок и графики. Лучше экспортировать в PDF после заполнения.
• Таблицы с большой плотностью данных (прайс-листы в Excel) — подход «строка = чанк» работает, но для сложных таблиц лучше преобразовать в текст.

Как подготовить документы правильно

1. Структурируйте — заголовки разделов, подзаголовки. RAG лучше режет структурированные тексты.
2. Убирайте воду — «Уважаемый клиент, рады вас приветствовать в нашей компании…» — на поиск не влияет, а контекст съедает.
3. Обновляйте регулярно — при изменении цен / условий / регламентов сразу заменяйте документ в базе.
4. Называйте по-человечески — Прайс-лист_апрель_2026.pdf лучше чем doc_v3_final_FINAL.pdf.

Добавление документов

Чанкинг — как документы режутся

Документ нельзя проиндексировать целиком — LLM не впихнёт 100-страничный PDF в своё контекстное окно. Документ режут на чанки — куски по 500-1500 символов.

Настройки чанкинга

В настройках коллекции:

• Размер чанка (chunkSize) — максимум символов на кусок. По умолчанию 1000. Для очень структурированных документов — 500, для длинных связных текстов — 1500.
• Перекрытие (overlap) — сколько символов соседние чанки перекрывают друг друга. По умолчанию 150. Это нужно, чтобы важная фраза не попала «на стык» и не потерялась.
• Стратегия резки:
  • semantic — режет по логическим границам (параграф, секция, заголовок). Лучший вариант для большинства документов.
  • fixed — режет каждые N символов без оглядки на смысл. Подходит для однородных данных (логи, таблицы без структуры).

Когда менять настройки

Стоит увеличить chunkSize, если:

• Документы — длинные связные тексты (инструкции, регламенты).
• Поиск находит обрывки мысли, где нужен полный контекст.

Стоит уменьшить chunkSize, если:

• Документы — таблицы или справочники (каждая запись уже целостна).
• Контекст LLM забивается слишком большими чанками.

Перекрытие больше (200-300), если:

• Важные фразы часто попадают «на стык» чанков.

Перекрытие меньше (50-100), если:

• Экономите на размере базы (Qdrant хранит перекрытия дважды).

Embedding-модель

За превращение текста в вектор отвечает embedding-модель. Это отдельная модель от основного LLM — она только считает векторы, не генерирует текст.

Выбор для русского языка

Оптимум: bge-m3 (self-hosted). Бесплатная, качество для русского — отличное, мультиязычная.

Альтернативы:

• text-embedding-3-small (OpenAI) — дёшево, быстро, но для русского чуть хуже bge-m3.
• text-embedding-3-large (OpenAI) — точнее, но в 6× дороже. Оправдано только при огромной базе документов.
• nomic-embed-text (self-hosted) — универсальный, удобно в Ollama.

Выбор для английского

Оптимум: text-embedding-3-small — дёшево, хорошо. Для максимальной точности: text-embedding-3-large.

Выбор для специфичных доменов

• Медицина — BioBERT, PubMedBERT (self-hosted).
• Юриспруденция — LegalBERT.
• Финансы — FinBERT.

Для нишевых доменов специализированные embedding дают +20-30% точности поиска.

Настройка

В Настройки → Модели → Провайдер эмбеддингов — выбираете модель. Применяется для всех новых коллекций.

Как агент использует знание

Пошагово, что происходит при каждом разговоре с клиентом:

Вот материалы из базы знаний, которые могут помочь:

[Прайс-лист 2026.pdf, стр. 3]: "Установка холодильника:
простая — 3 200 ₽, с подключением к электросети — 5 800 ₽,
расширенная — 7 500 ₽..."

[Регламент установки.docx]: "Мастер должен проверить наличие
заземления перед подключением..."

Используй эту информацию в ответе.

Тонкие настройки поиска

В настройках агента можно изменить:

• Количество чанков для поиска (top-K) — по умолчанию 5. Увеличьте до 10-15, если у вас большая база и часто не хватает контекста.
• Порог близости (similarity threshold) — по умолчанию 0.3. Поднимите до 0.5 если видите «мусорные» совпадения. Опустите до 0.2 если ничего не находит.

Поиск вручную — для отладки

Главный инструмент для отладки RAG.

Знание → Коллекция → вкладка «Поиск». Вводите запрос, видите:

• Найденные чанки — в порядке релевантности.
• Score — насколько близко (от 0 до 1, больше — лучше).
• Документ и страница — откуда взят чанк.

Алгоритм отладки «бот отвечает неправильно»

Паттерны работы с знанием

Паттерн «живой прайс»

Задача: цены меняются еженедельно, не хочется ручками обновлять Excel.

Решение:

1. В CRM / ERP экспортируйте прайс в CSV автоматически (cron).
2. В платформе — автоматический automation-flow по расписанию: «раз в день скачай CSV → заменяй в коллекции pricing → переиндексируй».

Результат: цены всегда актуальные, ручной работы — 0.

Паттерн «версионированный регламент»

Задача: юр. документы меняются, нужна история версий.

Решение:

1. Коллекция legal-current — только актуальные документы.
2. Коллекция legal-archive — старые версии с датами.
3. Юр-бот смотрит только в legal-current.

При смене документа: старый переезжает в archive, новый кладётся в current. История сохраняется, бот всегда отвечает по актуальному.

Паттерн «многоязычная база»

Задача: клиенты пишут на русском, английском, казахском — нужны ответы на их языке.

Решение:

1. Одна коллекция с документами на любом языке — embedding bge-m3 умеет в кросс-языковой поиск.
2. В промпт агента: «Отвечай на том же языке, на каком задан вопрос».

Агент находит релевантный материал на английском, клиент получает ответ на русском — всё автоматически.

Паттерн «FAQ + инструкции разного уровня»

Задача: одни вопросы требуют короткого ответа, другие — детального разбора.

Решение:

1. Две коллекции: faq-short (короткие ответы) и product-docs (длинные инструкции).
2. В промпт: «Сначала ищи в FAQ — если есть точный ответ, цитируй его коротко. Если FAQ не покрывает — ищи в product-docs и давай развёрнутый ответ.»

Квоты

Что такое «векторы»: количество чанков × количество векторов на чанк. Один документ на 100 страниц = ~500 чанков = 500 векторов. На Pro хватает на ~2000 больших PDF.

Частые ошибки

Метрики здоровья базы знаний

Критичные для мониторинга: