Qdrant — векторная база, в которой RAG-система ищет подходящие фрагменты документов компании перед ответом ИИ. Она хранит векторы, текстовые фрагменты и метаданные, но ответ сотруднику формирует отдельная модель. Качество результата зависит от разбивки документов, фильтров доступа и проверки найденных источников.
Место в системе
Qdrant отвечает за поиск фрагментов; модель формулирует ответ по найденному тексту, а права сотрудника проверяются до выдачи источника.
Для базы знаний путь начинается с исходного файла: договор, инструкция, регламент или карточка товара. Загрузчик извлекает текст, делит его на смысловые фрагменты и получает векторное представление через модель эмбеддингов. Затем отправляет фрагмент, вектор и служебные поля в Qdrant. Когда сотрудник задаёт вопрос, система получает вектор вопроса и просит базу вернуть близкие фрагменты.
Близость векторов показывает смысловое сходство, без гарантии юридической или фактической истинности. Если в коллекции лежат устаревшие правила, поиск честно найдёт устаревший текст. Если документ разбит посреди условия, модель получит половину мысли. Поэтому Qdrant полезно рассматривать как поисковый слой, а подготовку источников и ответ модели — как отдельные этапы. Общую архитектуру показывает разбор RAG-базы знаний.
Удобная единица результата включает фрагмент, название документа, раздел, дату версии и ссылку на исходник. Сотрудник должен открыть первоисточник одним действием. Для внутренней базы знаний это важнее эффектного пересказа модели: проверяемая цитата помогает разрешить спор по действующей версии документа.
Поисковый слой удобнее проверять отдельно от генерации ответа. Выведите сотруднику список найденных документов с заголовками и датами. Если среди них нет нужного источника, проблема лежит в загрузке, индексации или фильтрах. Модель в этой ситуации только замаскирует ошибку гладким текстом.
Запуск через Docker
Запрос «qdrant docker» связан с быстрым запуском базы на своём сервере. Контейнер подходит для разработки и проверки схемы данных, но рабочий контур требует постоянного тома для хранения, резервных копий, ограниченного сетевого доступа и наблюдения за состоянием. Перед запуском определите, кто владеет сервером и кто восстановит коллекцию после сбоя. Одного запуска контейнера для этого мало.
- Подготовьте сервер и постоянное хранилище для данных Qdrant; закройте служебный интерфейс от общего доступа.
- Создайте коллекцию под выбранную модель эмбеддингов и зафиксируйте её параметры в конфигурации приложения.
- Загрузите контрольные документы с идентификатором версии, разделом и меткой доступа.
- Проверьте поиск, резервную копию и восстановление на отдельном контуре до подключения сотрудников.
Вектора разных моделей эмбеддингов нельзя бесконтрольно смешивать в одной логике поиска: схожие слова могут оказаться в несовместимых пространствах. При смене модели спланируйте повторную индексацию и сравните выдачу на одном наборе вопросов. Ключевые параметры коллекции и подключения храните рядом с кодом загрузчика, чтобы восстановление было воспроизводимым.
Свой сервер даёт компании контроль над расположением документов и журналами доступа. Если для ответа используется модель с открытыми весами, её размещают на своём или арендованном сервере после проверки условий конкретной модели. Иной путь для зарубежной модели — сервис её вендора напрямую; оплата напрямую российскими картами недоступна. Qdrant остаётся поисковым слоем при любом выбранном варианте ответа.
Фильтры документов
Векторная близость без фильтра прав может показать фрагмент закрытого договора человеку из другого отдела. Поэтому перед поиском приложение передаёт фильтр по допустимому подразделению, проекту или уровню доступа. Метка хранится рядом с каждым фрагментом, а её значение берётся из проверенной учётной записи сотрудника. Текст вопроса и догадка модели для определения прав непригодны.
| Поле фрагмента | Зачем хранить | Проверка |
|---|---|---|
| Версия документа | Исключить старое правило | Дата и статус |
| Группа доступа | Ограничить выдачу | Роль сотрудника |
| Ссылка на файл | Открыть источник | Права на оригинал |
Возьмём условный вопрос кадровика о порядке согласования отпуска. В базе есть старая и новая инструкции. Поисковый запрос без фильтра версии может поднять старую страницу выше актуальной: её формулировка ближе к вопросу. Приложение ограничивает выдачу действующими версиями, а модель получает ссылку на конкретный раздел. Кадровик может проверить цитату и сообщить владельцу базы об ошибке документа.
Для смешанных запросов по номеру и смыслу одной семантики может быть мало. Точный номер договора ищут по метаданным или обычному текстовому индексу; смысловой вопрос — по векторам. После получения кандидатов отдельная проверка ранжирует их с учётом задачи. Подробности общей сборки под компанию есть на странице про создание базы знаний.
После настройки фильтров проверьте особенно вопросы на границе доступа. На них видно, совпадает ли поисковая выдача с правами человека.
Нужно ограничить поиск по вашим внутренним документам?
Качество выдачи
Соберите контрольный набор вопросов из реальной работы: точный номер документа, вопрос своими словами, спор между версиями, запрос без ответа в базе. Для каждого укажите ожидаемый источник и допустимый фрагмент. Сначала оцените выдачу Qdrant без модели, затем полный ответ RAG. Если источник найден неверно, переписывание промпта ответа вряд ли решит проблему.
Отдельно измеряйте полноту загрузки. Файл может лежать в папке, но парсер пропустит таблицу или подпись на скане. Для сканов нужен этап распознавания текста и выборочная ручная сверка. Обновление документа должно заменять старые фрагменты и сохранять след версии. Без этого база быстро начнёт отвечать по разным редакциям одного правила.
- Смотрите долю запросов, где нужный документ появился среди найденных фрагментов.
- Проверяйте ссылки: открывается ли исходник у сотрудника с его правами.
- Разбирайте случаи без ответа отдельно от случаев с неверным ответом модели.
Полезный тест на ложную уверенность: вопрос о правиле, которого в документах нет. Поиск вернёт ближайший по смыслу текст, но приложение должно позволять ответ «в базе нет подтверждения». Порог уверенности подбирают на собственных вопросах и вместе с владельцем знаний. Красивый ответ без источника здесь считается ошибкой, даже если выглядит убедительно.
Для оценки заведите журнал промахов поиска: вопрос, ожидаемый раздел, найденные фрагменты и причину расхождения. Через него видно, какие ошибки вызваны разбиением текста, а какие — устаревшими метаданными. Исправление выбирают по этой причине.
Обновление базы
Назначьте владельца каждого массива документов. После изменения регламента владелец сообщает об обновлении, загрузчик повторно обрабатывает файл, а старая версия выходит из поисковой выдачи. В журнале сохраняют источник, время загрузки и результат обработки. Если документ отклонён из-за пустого текста или неверного формата, ответственному нужен сигнал до того, как сотрудники начнут задавать вопросы.
Возьмите раздел знаний с понятным владельцем. Проверьте поиск по действующей версии и восстановление после обновления файла; только затем расширяйте набор источников.
Для рабочего контура разделите смету на подготовку документов, поиск, права, интеграцию с чатами и поддержку обновлений. Объём текстов сам по себе мало говорит о сложности: грязные сканы, противоречивые версии и разные права отделов добавляют работы. Решение для работы с документами помогает связать поиск с конкретным процессом; напишите нам о ваших источниках и правах доступа.
После запуска отслеживайте два вида изменений: новые документы и смену вопросов сотрудников. Новые темы могут требовать другого разбиения или дополнительных полей фильтра. Пересматривайте контрольный набор вместе с владельцами знаний, иначе точность на старых примерах будет выглядеть высокой при слабых ответах на новые запросы.
Частота переиндексации зависит от того, как часто меняются источники. При редких обновлениях достаточно управляемого запуска после утверждения новой версии. Для постоянно меняющейся базы потребуется очередь событий и проверка, что удалённый документ исчез из выдачи.