Поиск по большим документам¶

Поиск по документам нужен, когда документ слишком большой для удобного чтения целиком или когда вы хотите работать с коллекцией материалов многократно.

Технически подход называется RAG — Retrieval-Augmented Generation. В пользовательском интерфейсе ИИ Студии важнее простое объяснение: сначала Студия находит в ваших документах подходящие фрагменты, затем модель формирует ответ на их основе.

Что вы сделаете¶

Вы:

загрузите документ для поиска;
дождётесь индексирования;
зададите вопрос обычным языком;
получите ответ на основании найденных фрагментов;
откроете цитату и проверите первоисточник.

Когда использовать поиск по документам¶

Он особенно полезен для:

длинных руководств;
нормативных документов;
внутренних регламентов;
технической документации;
нескольких десятков PDF;
базы знаний подразделения;
документов постоянного ИИ-помощника;
повторяющихся вопросов к одному набору материалов.

Когда File Search не нужен¶

Если у вас один файл на 3–10 страниц и нужно прочитать его полностью, проще использовать чтение целиком.

Если у вас огромная таблица для статистических вычислений, смысловой поиск по текстовым фрагментам тоже не является идеальным инструментом.

Как это работает простыми словами¶

Представьте 500-страничное руководство.

Вместо того чтобы каждый раз отправлять модели 500 страниц, Студия заранее разбивает документ на небольшие смысловые части.

Когда пользователь спрашивает:

«Как восстановить кластер после потери управляющего узла?»

система ищет части, близкие по смыслу к вопросу. Например:

стр. 312 — аварийное восстановление
стр. 313 — восстановление control-plane
стр. 314 — проверка quorum

Только эти фрагменты и их метаданные добавляются к запросу модели.

Что происходит при индексировании¶

Упрощённый pipeline текущей Студии:

файл
 ↓
извлечение текста
 ↓
нормализация
 ↓
разбиение на фрагменты
 ↓
создание смыслового представления
 ↓
локальное векторное хранилище
 ↓
готово к поиску

В текущей архитектуре индексирование обслуживается отдельным RAG-компонентом, а поисковые представления хранятся в локальном pgvector/PostgreSQL-контуре.

Что такое фрагмент¶

Большой документ разбивается на части, которые удобно находить и передавать модели.

Фрагмент может соответствовать:

нескольким абзацам;
части раздела;
небольшой секции;
группе строк исходного текста.

Размер и перекрытие фрагментов являются серверной настройкой и могут изменяться при развитии продукта.

Пользователю важен эффект: слишком маленькие фрагменты теряют контекст, слишком большие ухудшают точность поиска и расходуют контекст модели.

Что такое embedding¶

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

Это называется embedding.

Благодаря этому вопрос:

«Как поменять пароль администратора?»

может найти раздел:

«Сброс учётных данных привилегированного пользователя»

даже если слова запроса и документа не совпадают буквально.

Note

Embedding — не краткое содержание и не зашифрованная копия документа. Это поисковое представление, используемое для сравнения смысловой близости.

Пошаговая загрузка для поиска¶

Шаг 1. Выберите рабочий контекст¶

Если документы нужны только в одном разговоре — работайте в этом разговоре.

Если они должны стать постоянными знаниями специализированного помощника — добавляйте их в его File Search/базу знаний. Это будет подробно описано в разделе ИИ-помощники.

Шаг 2. Нажмите добавление файла¶

Откройте меню вложения.

Шаг 3. Выберите поиск по документу¶

Выберите режим, связанный с File Search / поиском по документам.

Шаг 4. Загрузите файл¶

Выберите документ и дождитесь завершения загрузки.

Шаг 5. Дождитесь индексирования¶

Файл не обязательно готов к смысловому поиску сразу после передачи байтов на сервер.

Дождитесь состояния, показывающего завершение обработки.

Шаг 6. Задайте контрольный вопрос¶

Спросите о факте, который точно присутствует в документе.

Например:

«Найди в документе срок хранения ежедневных резервных копий. Покажи источник».

Шаг 7. Откройте цитату¶

Проверьте, что найденный фрагмент действительно подтверждает ответ.

Как задавать хорошие вопросы для поиска¶

Смысловой поиск лучше работает с содержательными запросами.

Слишком коротко:

«резервирование»

Лучше:

«Какой срок хранения ежедневных резервных копий установлен внутренним регламентом?»

Слишком широко:

«Расскажи всё про безопасность»

Лучше:

«Какие требования к сроку действия привилегированных учётных записей установлены в документах?»

Просите отвечать только по источникам¶

Для внутренней нормативной базы полезна формулировка:

«Отвечай только на основании найденных корпоративных документов. Для каждого существенного утверждения укажи источник. Если в документах нет ответа — прямо напиши, что информация не найдена».

Это снижает риск смешения корпоративного правила и общих знаний модели.

Несколько документов¶

Когда в индексе несколько файлов, модель может получить фрагменты из разных источников.

Это удобно для вопросов вида:

«Есть ли противоречие между политикой ИБ и инструкцией ИТ по срокам хранения журналов?»

Но наличие двух версий одного регламента может создать проблему.

Например:

Access_Policy_v2.pdf
Access_Policy_v3.pdf

Если обе редакции активны, поиск может вернуть обе.

Поэтому версиями нужно управлять осознанно. См. Корпоративная база знаний.

Почему поиск иногда находит «не тот» фрагмент¶

Смысловой поиск — это ранжирование, а не точная база данных.

Причины:

вопрос сформулирован слишком широко;
одинаковые термины встречаются в разных разделах;
в базе есть устаревшая версия;
документ плохо извлечён;
заголовок отделился от основного текста;
таблица потеряла структуру;
нужная информация находится в изображении;
фрагмент слишком мал или слишком велик;
вопрос требует точного значения, а пользователь описал его абстрактно.

Как улучшить запрос, если источник не найден¶

Добавьте термин из документа¶

Было:

«Когда меняют пароль?»

Стало:

«Какова периодичность смены пароля привилегированной учётной записи?»

Добавьте контекст подразделения¶

«Какой порядок аварийного доступа установлен для системных администраторов?»

Укажите документ¶

«Ищи ответ только в ИБ_Регламент_управления_доступом_v3.2.pdf».

Попросите сначала найти источники¶

«Сначала перечисли 3 наиболее релевантных фрагмента с названиями документов. Пока не делай итоговый вывод».

После проверки можно попросить сформировать заключение.

Двухэтапная проверка для важных вопросов¶

Для юридических, информационно-безопасностных и финансовых вопросов используйте два шага.

Этап 1. Факты¶

«Найди все фрагменты документов, где указаны сроки уведомления. Не делай выводов. Покажи источник и точный смысл каждого фрагмента».

Этап 2. Вывод¶

После проверки:

«Теперь на основании только этих найденных фрагментов составь итоговый порядок действий».

Так легче заметить ошибку retrieval до того, как она превратится в уверенный итоговый ответ.

Цитаты¶

Если функция цитат разрешена для вашей роли, ответ может содержать ссылки на документы или найденные фрагменты.

Цитата помогает проверить:

какой документ использован;
какой участок текста был найден;
действительно ли источник подтверждает вывод;
не перепутана ли версия документа.

Подробнее: Источники и цитаты.

Поиск по документам и локальная модель¶

Если активна локальная модель:

файл индексируется локальными компонентами Студии;
поиск выполняется локально;
найденные фрагменты передаются локальной модели.

Это основной вариант для полностью внутреннего контура документов.

Поиск по документам и Yandex AI¶

Если администратор активировал Yandex AI:

индекс документов остаётся в инфраструктуре Студии;
локальный поиск выбирает релевантные фрагменты;
эти фрагменты включаются в запрос;
запрос отправляется в Yandex AI Studio.

То есть весь архив документов не обязан передаваться в облако, но найденные части, использованные для ответа, передаются облачной модели.

Конфиденциальность

Не считайте локальный RAG автоматически полностью локальным, если финальная модель облачная. Граница данных определяется тем, куда отправляется сформированный контекст.

Поиск по документам и интернет-поиск — разные функции¶

File Search ищет в загруженных пользователем или организацией документах.

Интернет-поиск обращается к внешним веб-источникам.

Они могут использоваться в одном разговоре, но источники нужно различать.

Если задача должна опираться только на внутренний регламент, отключите внешние источники или прямо запретите использовать их в запросе.

RAG не обучает модель¶

После загрузки документов локальная модель не становится «дообученной» на них.

Её веса не меняются.

Вместо этого нужные фрагменты подставляются в контекст перед ответом.

Это означает:

документ можно обновить без переобучения модели;
разные пользователи могут иметь разные наборы знаний;
одна модель может работать с несколькими базами;
удаление документа не требует пересборки модели.

RAG не является памятью пользователя¶

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

RAG хранит и ищет документы.

Не используйте корпоративную базу документов как замену памяти и не загружайте тысячи файлов только для того, чтобы модель «помнила проект».

Что индексировать не стоит¶

Не добавляйте без необходимости:

двоичные файлы;
повторные копии одного документа;
временные файлы Office;
каталоги зависимостей;
сгенерированный код;
архивы логов за годы без отбора;
резервные копии;
файлы с секретами;
документы без владельца и понятной актуальности.

Чем чище коллекция, тем выше качество поиска.

Работа с таблицами¶

File Search оптимизирован прежде всего под текстовые знания.

Сложные электронные таблицы могут потерять часть структуры при текстовом извлечении. Вопрос вроде:

«В какой строке листа 17 сумма столбцов C и F максимальна?»

не является идеальной RAG-задачей.

А вопрос:

«Какие категории расходов описаны в таблице?»

может быть вполне подходящим, если текст извлечён корректно.

Работа с кодовой базой¶

Смысловой поиск по большому набору исходников может помочь найти связанный код, но это не полноценный IDE-indexer.

Для точной диагностики конкретной ошибки полезнее загрузить:

stack trace;
относящийся к нему файл;
вызывающую функцию;
конфигурацию;
версию компонентов.

Как оценить качество базы¶

Создайте набор из 20–50 реальных вопросов, на которые вы заранее знаете правильные источники.

Для каждого вопроса фиксируйте:

найден ли нужный документ;
найден ли правильный фрагмент;
нет ли устаревшего источника выше актуального;
корректно ли модель интерпретировала текст;
присутствует ли цитата;
признаёт ли модель отсутствие ответа.

Это намного полезнее, чем субъективное «кажется, отвечает хорошо».

Если в базе нет ответа¶

Правильное поведение:

«В доступных документах не найдено достаточной информации для ответа».

Плохое поведение:

модель уверенно дополняет внутреннее правило общими знаниями.

Для корпоративных помощников явно указывайте в инструкции, что при отсутствии источника нужно сообщать об этом.

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

Файл долго находится в состоянии обработки¶

Большой документ ещё индексируется или сервис обработки недоступен.

Не перезагружайте одну и ту же копию много раз — это может создать дубликаты.

Ответ есть, но цитаты нет¶

Возможные причины:

ответ сформирован из общей модели, а File Search не сработал;
цитаты отключены политикой роли;
источник не был передан инструментом;
вопрос продолжает старый контекст, где факт уже был упомянут.

Возвращается старая версия¶

Удалите или выведите из использования устаревший документ и проверьте коллекцию версий.

Поиск плохо понимает таблицу¶

Экспортируйте содержательное представление в текст/CSV или разделите таблицу на логические части.

Ничего не находится¶

Проверьте, что:

файл действительно проиндексирован;
в нём есть извлекаемый текст;
вопрос относится к содержимому;
вы используете правильного помощника/коллекцию;
у вас есть право доступа к документу.

Как проверить результат¶

Система работает правильно, если:

документ имеет готовый статус;
контрольный вопрос находит правильный фрагмент;
цитата ведёт к ожидаемому источнику;
отрицательный вопрос не порождает выдуманный факт;
при нескольких документах отображается правильное имя источника.