Компании подключают к внутренним документам AI-поиск и корпоративных ассистентов, рассчитывая, что модель сама разберётся в накопленном контенте: регламентах, инструкциях, базах знаний в Confluence или SharePoint. На практике точность ответов зависит от состояния базы знаний не меньше, чем от выбранной модели.
Это внутренняя задача, а не продвижение публичного сайта в ответах чат-ботов. Сайт под генеративные ответы оптимизируют методами GEO (generative engine optimization) и AEO (answer engine optimization): там читатель внешний. Здесь читатель — сотрудник, а объект работы — внутренние документы, написанные для человека и без учёта того, что их будет читать поисковый механизм.
Что такое AI-поиск по документам
AI-поиск ищет не документ, а фрагмент. Система оценивает близость фрагментов к запросу, отбирает несколько лучших и передаёт их языковой модели. Модель формулирует ответ по переданному тексту, а не по своей памяти. Эта архитектура называется retrieval-augmented generation, RAG.
Близость считается двумя способами. Векторный поиск работает с эмбеддингами (embeddings) — числовыми представлениями смысла текста. Лексический поиск ищет точные совпадения слов и выигрывает там, где важна буква: коды продуктов, специальный жаргон, даты, имена. Промышленные системы используют оба механизма: по документации Azure AI Search, гибридный поиск с семантическим реранкингом заметно выигрывает у чисто векторного по релевантности.
Более сильная модель плохой поиск не спасает: если в контекст попал отменённый регламент, модель аккуратно перескажет именно его. Исследование Seven Failure Points When Engineering a RAG System (CAIN 2024) относит большинство типовых отказов к данным и поиску: нужного текста нет в базе или он не попал в верхние результаты.
Почему поисковый механизм читает документы иначе, чем человек
Перед индексацией документ разбивается на фрагменты — чанки (chunks). Дальше система работает с ними как с независимыми единицами, а оценка документа целиком если и участвует в ранжировании, то как дополнительный сигнал.
Человек, открыв файл, видит заголовок, дату и соседние разделы и достраивает контекст сам. Поисковому механизму достаётся ровно тот текст, который попал в границы чанка. Фрагмент из середины раздела теряет привязку к теме и к условиям применения правила, и модель достраивает недостающее сама.
Эффект измерим. В эксперименте Anthropic к каждому чанку добавили короткое пояснение, к какому разделу и документу он относится. Доля промахов поиска по топ-20 фрагментам снизилась на 35%, вместе с лексическим поиском — на 49%, с реранкингом — на 67%. Цифры получены на технических корпусах, а не на регламентах, но порядок эффекта показателен.
Структура документа задаёт границы фрагментов
Размер фрагмента: от чего отсчитывать
Границы чанка привязывают к структуре документа: к заголовку, абзацу, предложению. Часто применяют фиксированный размер с перекрытием, чтобы мысль не обрывалась на стыке.
Ориентиры из документации Azure AI Search по чанкингу: начинать с 512 токенов (примерно 2000 знаков) и перекрытия 25%, то есть 128 токенов. Значения по умолчанию у встроенного разбиения — 2000 знаков на фрагмент и 500 знаков перекрытия. Для русских регламентов на практике берут 500–800 токенов: русский текст даёт больше токенов на тот же смысл.
Отсюда требование к автору. Смысловой блок, который должен читаться целиком, не должен превышать примерно 2000 знаков. Раздел на 8000 знаков без подзаголовков будет разрезан машиной, и точку разреза выберет не автор.
Требования к заголовкам
- Один заголовок — одна тема. Раздел из пяти разнородных тем разрежется посередине смысловой единицы.
- Вложенность не глубже двух-трёх уровней. Глубже граница фрагмента перестаёт совпадать с границей смысла.
- Единый стиль заголовков по всей базе. Microsoft формулирует это прямо: «Consistent use of header styles (H1, H2, and so on) reduces confusion for both AI and human readers».
- Заголовок называет тему. «Общие вопросы» и «Важно» не сообщают о разделе ничего, а «Как настроить резервное копирование для базы данных PostgreSQL» задаёт границы темы.
- Краткое резюме в начале длинного документа снижает риск, что ответ соберут не из того раздела.
Условия и исключения — рядом с правилом
Оговорки в конце документа попадают в другой фрагмент, чем само правило. Поиск найдёт правило и не найдёт исключение, а ответ будет формально верным и практически неправильным.
Термин раскрывайте в первом предложении того абзаца, где он появляется: тогда абзац извлекается как самостоятельный ответ на прямой вопрос. Перечисления оформляйте списком — он даёт модели дискретные пункты вместо сплошного текста.
Актуальность версий и дубли
Поиск возвращает несколько наиболее близких фрагментов. Если в базе живут старая и новая версия регламента, обе близки к запросу и обе могут попасть в контекст, а надёжного признака, какую предпочесть, у модели нет.
Результат — противоречивые ответы на один вопрос. Риск конкретный: сотрудник получает инструкцию по отменённому процессу. Черновики и копии одного регламента в разных разделах повышают шанс такого попадания.
Что чинится в контенте, а что в настройках индексации
- На стороне контента: удаление дублей, архивирование старых редакций, статус документа, назначенный владелец.
- На стороне пайплайна: фильтр по статусу до поиска, дедупликация при индексации, реранкинг, ограничение источников под конкретный сценарий.
Порядок работ от этого не меняется. Фильтру по статусу нечего фильтровать, пока статус не заполнен.
Метаданные: фильтр, а не карточка каталога
Для человека дата и владелец документа — справочная информация. Для поиска это рабочий инструмент: система отсекает архивные документы до расчёта смысловой близости. Без фильтра единственным критерием остаётся сходство, а сходство не отличает действующий текст от отменённого.
Минимальный набор полей
- дата создания и дата последнего обновления;
- статус: действующий, архивный, черновик, заменён;
- владелец содержания — подразделение или сотрудник;
- тип документа: регламент, инструкция, FAQ, техническая заметка;
- срок действия или дата следующего пересмотра.
Тот же набор рекомендует Microsoft для контента под корпоративных ассистентов: «rich, consistent metadata (such as country/region, document type, owner, and review date)».
Поле работает только после проброса в поисковую схему
Здесь теряется большая часть усилий. Заполненное поле в вики само по себе фильтром поиска не становится, его нужно связать со схемой индекса. Microsoft говорит об этом без оговорок: «Always map important site columns to managed properties in the SharePoint Search Schema». Это вторая задача, и она ставится команде внедрения.
Единая терминология и внутренний жаргон
Синонимы векторный поиск распознаёт, но не идеально. Документ, где привычный процесс назван внутренним жаргоном, хуже совпадает с запросом в стандартных терминах и опускается ниже в списке кандидатов. Один отдел называет процесс «онбордингом», второй — «адаптацией новых сотрудников», третий использует сокращение: на типовой запрос система найдёт один источник из трёх.
Аббревиатуры — отдельный случай. Их плохо ловит смысловая близость и хорошо ловит лексический поиск. Поэтому современные модели эмбеддингов делают ставку на комбинацию: BGE-M3 выдаёт одновременно плотное, разреженное и многовекторное представление текста.
Переименовать процессы во всех отделах — проект на годы. Быстрый результат даёт карта синонимов на стороне поиска: запрос расширяется вариантами названия до обращения к индексу, это штатный механизм поисковых движков. Глоссарий остаётся, но как долгая задача, а не как условие запуска.
Человек и AI-поиск рядом: что меняется в подготовке контента
| Параметр | Что даёт человеку | Что определяет для AI-поиска |
|---|---|---|
| Заголовки разделов | Навигацию по документу при чтении | Точку разреза документа на фрагменты |
| Длина раздела | Комфорт чтения, не более | Уместится ли смысловой блок в один фрагмент |
| Актуальность версии | Возможность переспросить автора | Попадёт ли отменённая редакция в контекст ответа |
| Метаданные | Карточку в каталоге | Фильтр, отсекающий документы до расчёта близости |
| Терминология | Понятность за счёт опыта и контекста | Найдётся ли документ по типовому запросу |
| Дубли | Заметны визуально при просмотре раздела | Источник противоречивых ответов на один вопрос |
Оптимизация базы знаний для ИИ: чек-лист
Перебирать базу целиком до запуска не нужно и почти никогда не получается. Рабочий вход — собрать 30–50 реальных вопросов сотрудников, найти закрывающие их документы и привести в порядок эти двадцать-тридцать файлов.
- Инвентаризация. Выгрузить список документов с датами и владельцами, найти дубли, черновики и устаревшие редакции. В Confluence помогает макрос Page Properties Report и отчёты по неактивным страницам, в SharePoint — отчёты о неиспользуемом контенте.
- Структура заголовков. Привести к единой иерархии, разделы длиннее 2000 знаков разбить подзаголовками.
- Метаданные. Заполнить обязательные поля и поставить задачу на их проброс в поисковую схему: в Confluence это метки и свойства страницы, в SharePoint — колонки сайта и managed properties.
- Терминология. Собрать расхождения между отделами, завести карту синонимов на стороне поиска, параллельно вести глоссарий.
- Формулировки. Переписать неинформативные заголовки, вынести определения в первое предложение абзаца, перечисления оформить списками.
- Регулярность. Назначить владельцев разделов и дату следующего пересмотра. Без этого база возвращается в исходное состояние за один-два квартала.
Технический слой закрывает команда внедрения: парсинг документов (pdfplumber, PyMuPDF, python-docx), разбиение с опорой на заголовки (MarkdownHeaderTextSplitter и родственные сплиттеры), векторная база (pgvector, Qdrant, OpenSearch с гибридным поиском).
Как проверить, что стало лучше
Минимальная схема измерения: набор из 50–100 вопросов с заранее известными правильными источниками, прогон до и после правок. Открытые фреймворки оценки RAG считают по такому набору понятные метрики. У Ragas это context precision (насколько релевантен найденный контекст), context recall (нашлось ли всё нужное) и faithfulness (опирается ли ответ на найденный текст). Первые две отвечают за качество базы и поиска.
Где развернуть AI-поиск: доступ к моделям и инфраструктура
Подготовленная база — половина задачи. Вторая половина в том, куда уходят фрагменты корпоративных документов, когда система обращается к модели.
Слой доступа к моделям закрывает AIaaS от ITGLOBAL.COM — единый API-шлюз к более чем 100 языковым моделям. Что это даёт сценарию поиска по документам:
- один защищённый канал вместо прямых обращений к разным провайдерам;
- DLP-фильтрация промптов и ответов, ролевая модель доступа, логирование запросов для аудита;
- обработка данных на территории РФ в соответствии с 152-ФЗ;
- смена модели без переписывания кода поискового контура и без вендор-лока (vendor lock-in);
- квоты и бюджеты по подразделениям.
Retrieval-слой — индексация, векторная база, разбиение на фрагменты, права доступа — собирается поверх шлюза.
Если контур должен быть изолированным, а модели дообучаться на данных компании, применяется формат Private AI Cloud: выделенный ИИ-контур на GPU-инфраструктуре ITGLOBAL.COM.
Требования к размещению персональных данных закрывает облако с аттестацией по 152-ФЗ.
Что происходит с данными при работе через внешние AI-сервисы, разобрано в статье о безопасности данных при использовании внешних AI-сервисов.
Заключение
Точность AI-поиска задаётся на входе в индекс, а не в промпте и не выбором модели. Фрагмент без контекста, отменённый регламент без статуса и процесс под тремя названиями дадут неверный ответ на любой модели.
Список работ при этом конечен и проверяем: двадцать ключевых документов, заполненные статусы, единая иерархия заголовков и набор контрольных вопросов дают измеримый результат за недели.
Предыдущая статья
