Компании подключают к внутренним документам AI-поиск и корпоративных ассистентов, рассчитывая, что ИИ сможет находить нужную информацию в регламентах, инструкциях, базах знаний, Confluence или SharePoint и формировать ответ на естественном языке. На практике качество такого ответа зависит не только от выбранной языковой модели, но и от того, насколько правильно подготовлена корпоративная база знаний.
Поиск по документам с помощью ИИ отличается от обычного поиска по ключевым словам. Система должна найти не просто документ, в котором встречается нужное слово, а релевантный фрагмент, передать его языковой модели и сформировать ответ с учётом найденного контекста.
Поэтому перед внедрением AI-поиска важно проверить структуру документов, их актуальность, метаданные, терминологию, дубли и правила индексации.
Важно: подготовка внутренней базы знаний для AI-поиска — это не то же самое, что GEO- или AEO-оптимизация сайта. GEO (generative engine optimization) и AEO (answer engine optimization) ориентированы на попадание публичного контента в ответы внешних поисковых и генеративных систем. Здесь объект работы — внутренние документы компании, а пользователь — сотрудник.
Что такое AI-поиск по документам
AI-поиск по документам — это поиск информации в корпоративной базе знаний с помощью технологий семантического поиска и языковых моделей.
Вместо того чтобы возвращать пользователю список документов, система находит релевантные фрагменты, передаёт их языковой модели и формирует ответ на основе найденного контекста. Такой подход обычно строится по архитектуре retrieval-augmented generation (RAG).
RAG позволяет использовать частные и регулярно обновляемые данные компании как контекст для ответа языковой модели. В типовой архитектуре сначала выполняется поиск по индексу, затем найденная информация передаётся модели, которая формирует ответ на её основе.
AI-поиск по корпоративным документам может работать с:
- регламентами;
- инструкциями;
- внутренними базами знаний;
- технической документацией;
- FAQ;
- политиками и стандартами;
- материалами Confluence;
- документами SharePoint;
- внутренними PDF, DOCX и другими файлами.
Главное отличие от классического поиска — система оценивает не только совпадение слов, но и смысл запроса.
Чем AI-поиск отличается от обычного поиска
Обычный поиск чаще отвечает на вопрос: «В каких документах встречается это слово?»
AI-поиск решает другую задачу: «В каких фрагментах документов есть информация, которая отвечает на мой вопрос?»
Например, сотрудник спрашивает: «Как оформить доступ новому сотруднику к корпоративным системам?»
Если в базе знаний процесс называется «адаптация персонала», а слово «доступ» встречается в нескольких документах, поиск только по ключевым словам может вернуть много нерелевантных результатов.
Семантический поиск способен сопоставить запрос с содержанием документов даже при различии формулировок. Для корпоративных сценариев при этом полезно сочетать смысловой и лексический поиск: второй лучше работает с кодами продуктов, именами, аббревиатурами и внутренним жаргоном.
Как работает AI-поиск по документам
В упрощённом виде поиск по корпоративной базе знаний с помощью ИИ проходит несколько этапов.
- Подготовка документов. Файлы очищаются, структурируются и получают необходимые метаданные.
- Разбиение на фрагменты. Большие документы делятся на чанки — самостоятельные части текста.
- Индексация. Для фрагментов создаются поисковые представления, в том числе embeddings для семантического поиска.
- Запрос сотрудника. Пользователь задаёт вопрос обычным языком.
- Поиск. Система ищет наиболее релевантные фрагменты.
- Реранкинг. Найденные результаты дополнительно сортируются по релевантности.
- Формирование ответа. Релевантный контекст передаётся языковой модели.
- Ответ пользователю. Модель формулирует ответ на основе найденных данных.
Современные RAG-системы используют разные варианты retrieval (поиск и извлечение): keyword search, semantic search, vector search и hybrid search. Гибридный подход объединяет поиск по словам и смысловой близости, а дополнительное ранжирование помогает выбрать наиболее релевантный контекст.
Инфографика 1: «Как работает AI-поиск по документам»
Документ → подготовка → чанкинг → индексация → запрос → поиск → реранкинг → LLM → ответ
Ключевой вывод: более мощная модель не заменяет качественный поиск и извлечение. Если в контекст попал устаревший регламент или нерелевантный фрагмент, модель может сформулировать грамматически правильный, но практически неверный ответ. При этом модель способна частично сгладить отдельные дефекты поиска, например за счёт переформулирования запроса или дополнительных проходов, но не может надёжно восстановить отсутствующую или устаревшую информацию.
Почему AI-поиск может находить не тот документ
Основная ошибка при внедрении корпоративного AI-поиска — считать, что достаточно загрузить документы в систему и подключить хорошую языковую модель.
На качество ответа влияют:
- качество исходных документов;
- структура текста;
- способ разбиения на чанки;
- качество индексации;
- метаданные;
- актуальность версий;
- терминология;
- стратегия поиска;
- реранкинг;
- права доступа;
- выбранная языковая модель.
Исследования RAG-систем показывают, что проблемы могут возникать ещё до этапа генерации ответа: нужной информации может не быть в базе или она может не попасть в число найденных результатов.
Поэтому более мощная модель не всегда решает проблему плохого поиска. Если в контекст передан отменённый регламент, модель будет работать именно с ним.
Как подготовить документы для AI-поиска
Перед индексацией документ разбивается на фрагменты — чанки (chunks). После этого система работает с ними как с самостоятельными единицами поиска.
Для человека документ имеет естественный контекст: заголовок, дату, соседние разделы и предыдущие абзацы. При поиске система может получить только тот фрагмент, который попал в индекс и был выбран retrieval-механизмом.
Если смысл правила находится в одном чанке, а исключение — в другом, модель может получить только первую часть и сформировать неполный ответ.
Поэтому подготовка документа должна учитывать не только удобство чтения человеком, но и то, как информация будет извлекаться машиной.
Какой размер чанка нужен для AI-поиска
Размер чанка нельзя выбирать исключительно по принципу «чем больше, тем лучше» или «чем меньше, тем точнее».
Большой фрагмент содержит больше контекста, но может включать много нерелевантной информации. Маленький фрагмент легче сопоставить с конкретным запросом, но он может потерять условия применения правила.
В документации Azure AI Search приведены ориентиры для разбиения документов и подчёркивается, что оптимальный размер зависит от используемых моделей и характера данных. Чанкинг помогает укладываться в ограничения моделей и улучшает работу retrieval (поиск и извлечение) для RAG-сценариев.
Для корпоративных русскоязычных регламентов 500–800 токенов можно рассматривать только как стартовую гипотезу для тестирования, а не как подтверждённую универсальную рекомендацию. Такой диапазон следует проверять на собственном наборе документов и реальных запросов, поскольку оптимальный размер чанка зависит от структуры контента, используемой модели и конкретного сценария.
В исходной версии статьи также использовался ориентир около 512 токенов и перекрытие около 25%; его также лучше воспринимать именно как стартовую точку для тестирования, а не как универсальное правило.
Главное требование к автору документа проще: один смысловой блок должен быть достаточно самостоятельным, чтобы его можно было извлечь из документа без потери основного контекста.
Поэтому длинный раздел на несколько тысяч знаков без подзаголовков лучше разбивать на логические части.
Как заголовки влияют на поиск по корпоративным документам
Заголовок помогает не только человеку ориентироваться в документе. Он задаёт смысловую границу раздела и помогает системе определить, к какой теме относится конкретный фрагмент.
Для базы знаний лучше придерживаться нескольких правил:
- один заголовок — одна тема;
- не использовать слишком глубокую вложенность;
- придерживаться единого стиля заголовков;
- называть раздел конкретно, а не использовать формулировки вроде «Общие вопросы» или «Важно»;
- размещать условия и исключения рядом с правилом;
- для длинных документов добавлять краткое резюме в начале.
Например:
Плохо: Важная информация
Лучше: Как настроить резервное копирование базы данных PostgreSQL
Во втором варианте уже из заголовка понятно, о чём будет фрагмент.
Почему условия и исключения нужно хранить рядом с правилом
Для человека естественно прочитать весь документ и учесть оговорку, которая находится в конце раздела.
Поисковый механизм может получить только часть документа.
Например: «Сотрудники могут самостоятельно оформить доступ к системе».
А ниже, в другом разделе: «Исключение: для внешних сотрудников доступ оформляется через службу безопасности».
- Если в контекст попадёт только первый фрагмент, AI-ассистент может дать ответ без важного исключения. Поэтому условия, ограничения и исключения должны находиться рядом с тем правилом, к которому они относятся.
Термин также лучше раскрывать в первом предложении абзаца, где он появляется. Перечисления стоит оформлять списками — так отдельные пункты проще извлекать как самостоятельные элементы ответа.
Как актуальность документов влияет на AI-поиск
Одна из самых опасных проблем корпоративной базы знаний — наличие нескольких версий одного документа.
Предположим, в системе находятся:
- действующий регламент;
- старая редакция;
- черновик;
- копия документа в другом разделе.
Все они могут быть похожи по содержанию. Если система не знает, какая версия актуальна, несколько документов могут попасть в результаты поиска.
В итоге сотрудник получает противоречивые ответы или инструкцию по уже отменённому процессу.
Что исправляется в контенте, а что в поисковой системе
На стороне контента:
- удалить дубли;
- архивировать старые версии;
- обозначить статус документа;
- назначить владельца содержания;
- указать дату пересмотра.
На стороне поискового пайплайна:
- фильтровать документы по статусу до поиска;
- выполнять дедупликацию при индексации;
- использовать реранкинг;
- ограничивать источники для конкретного сценария.
При этом технический фильтр не заменяет работу с контентом: фильтру нечего отбирать, если статус документа нигде не указан.
Какие метаданные нужны для AI-поиска
Для человека дата и владелец документа могут быть справочной информацией. Для поисковой системы метаданные становятся рабочим инструментом.
С их помощью можно отфильтровать архивные или нерелевантные документы ещё до расчёта смысловой близости.
Минимальный набор метаданных
- дата создания;
- дата последнего обновления;
- статус: действующий, архивный, черновик, заменён;
- владелец содержания — подразделение или сотрудник;
- тип документа: регламент, инструкция, FAQ, техническая заметка;
- срок действия или дата следующего пересмотра.
Но заполнить поле в корпоративной вики недостаточно. Метаданные должны быть доступны поисковой схеме и использоваться при retrieval.
Инфографика 2: «Метаданные документа как фильтр AI-поиска»
Документ → статус + владелец + тип + дата → фильтрация → поиск по смыслу → релевантный контекст
Единая терминология улучшает поиск по базе знаний
В разных подразделениях один процесс может называться по-разному.
Например:
- «онбординг»;
- «адаптация новых сотрудников»;
- «ввод в должность».
Семантический поиск способен находить близкие формулировки, но не всегда с одинаковой точностью.
Особенно важны:
- внутренние сокращения;
- коды продуктов;
- названия систем;
- названия подразделений;
- профессиональный жаргон;
- уникальные названия процессов.
Для таких случаев полезно сочетать векторный и лексический поиск.
Аббревиатуры и точные названия часто лучше обрабатываются лексическим поиском, тогда как семантический поиск помогает находить документы при переформулированном запросе.
Поэтому не обязательно сразу переписывать всю базу в единой терминологии.
Быстрый практический шаг — создать карту синонимов и использовать её на стороне поиска. Параллельно можно вести корпоративный глоссарий.
Что нужно для запуска AI-поиска по документам
Для корпоративного AI-поиска недостаточно только языковой модели.
Типовая архитектура включает несколько слоёв:
- Источники данных — Confluence, SharePoint, файловые хранилища, базы данных и другие корпоративные системы.
- Подготовка контента — извлечение текста, очистка, чанкинг и обогащение метаданными.
- Индекс — хранение поисковых представлений документов и фрагментов.
- Retrieval — поиск релевантных фрагментов по запросу.
- Реранкинг — дополнительная оценка найденных результатов.
- LLM — формирование ответа на основе найденного контекста.
- Контроль доступа — ограничение результатов в соответствии с правами пользователя.
- Мониторинг и оценка — проверка качества поиска и ответов.
Современные RAG-пайплайны также могут включать отдельные этапы извлечения текста из PDF, обработки изображений, векторизации и работы с несколькими источниками данных.
AI-поиск в корпоративном контуре: решение ITGLOBAL.COM
Для корпоративного сценария важно контролировать не только качество поиска, но и то, куда передаются фрагменты внутренних документов при обращении к языковой модели.
Слой доступа к моделям может быть организован через AIaaS от ITGLOBAL.COM — единый API-шлюз к более чем 100 языковым моделям.
Для сценария AI-поиска по документам это позволяет использовать:
- единый защищённый канал вместо прямых обращений к разным провайдерам;
- DLP-фильтрацию промптов и ответов;
- ролевую модель доступа;
- логирование запросов для аудита;
- обработку данных на территории РФ с возможностями, предусмотренными платформой; при этом соответствие конкретного решения требованиям 152-ФЗ зависит от состава данных, схемы их обработки, настроек, договоров и отдельной юридической оценки;
- смену модели без переписывания поискового контура;
- квоты и бюджеты по подразделениям.
Retrieval-слой — индексация, векторная база, разбиение на фрагменты и управление правами доступа — может строиться поверх шлюза.
Если требуется изолированный контур или работа с собственной GPU-инфраструктурой, можно использовать формат Private AI Cloud на GPU-инфраструктуре ITGLOBAL.COM.
Для сценариев, в которых предъявляются требования к размещению персональных данных, используется облачная инфраструктура с соответствующим уровнем защиты.
Что происходит с корпоративными данными при работе через внешние AI-сервисы, важно оценивать отдельно — с учётом архитектуры конкретного решения, политики провайдера, требований к размещению и настроек безопасности.
Что выбрать: готовый AI-шлюз или собственный AI-контур
Подход зависит от требований компании.
| Критерий AIaaS | API-шлюз | Private AI Cloud |
|---|---|---|
| Доступ к нескольким моделям | Да | Зависит от конфигурации |
| Быстрый запуск | Подходит | Требует больше инфраструктурной настройки |
| Контроль доступа | Да | Да |
| Работа в изолированном контуре | Зависит от конфигурации | Да |
| Собственная GPU-инфраструктура | Не обязательна | Да |
| Возможность менять модели | Да | Зависит от архитектуры |
| Контроль инфраструктуры | Ниже | Выше |
Для части компаний оптимальным вариантом становится комбинация: единый шлюз для доступа к моделям и отдельный защищённый контур для данных и инфраструктуры.
Человек и AI-поиск: что меняется в подготовке контента
| Параметр | Что дает человеку | Что определяет для AI-поиска |
|---|---|---|
| Заголовки разделов | Навигацию по документу | Границы смысловых фрагментов |
| Длина раздела | Удобство чтения | Уместится ли смысловой блок в один фрагмент |
| Актуальность версии | Возможность уточнить информацию | Попадёт ли устаревшая редакция в контекст |
| Метаданные | Справочную информацию | Фильтрацию документов до поиска |
| Терминология | Понятность | Вероятность найти нужный источник |
| Дубли | Заметны при чтении | Могут создавать противоречивый контекст |
Главный принцип: документ должен быть удобен не только для чтения человеком, но и для извлечения отдельными смысловыми фрагментами.
Как оптимизировать базу знаний для AI-поиска: пошаговый чек-лист
Перебирать всю корпоративную базу перед запуском AI-поиска не обязательно.
Практичнее начать с реальных вопросов сотрудников.
Соберите 30–50 типовых запросов, найдите документы, которые должны на них отвечать, и начните с 20–30 наиболее важных файлов.
- Провести инвентаризацию: соберите список документов с датами и владельцами.
Найдите:
- дубли;
- черновики;
- устаревшие редакции;
- документы без владельца.
- Привести в порядок структуру: проверьте заголовки и разбейте длинные разделы на самостоятельные смысловые блоки.
- Заполнить метаданные: для документов должны быть определены:
- статус;
- владелец;
- тип;
- дата обновления;
- дата следующего пересмотра.
Затем эти поля необходимо связать с поисковой схемой.
- Проверить терминологию: соберите разные названия одних и тех же процессов и заведите карту синонимов.
- Переписать неинформативные заголовки: заголовок должен сразу сообщать, о чём раздел.
- Назначить владельцев: у каждого важного раздела должен быть ответственный за актуальность содержания.
- Проверять базу регулярно: без регулярного пересмотра даже хорошо подготовленная база постепенно снова накапливает дубли и устаревшие версии.
Как проверить качество AI-поиска
После подготовки базы важно не ограничиваться субъективной оценкой вроде «ответы стали лучше».
Нужен контрольный набор вопросов.
Минимальная схема:
- Собрать 50–100 реальных вопросов сотрудников;
- Для каждого вопроса определить правильный источник;
- Выполнить поиск до изменений;
- Внести изменения в базу;
- Выполнить поиск повторно;
- Сравнить результаты.
Для оценки RAG можно использовать, в частности:
- context precision — насколько найденный контекст релевантен;
- context recall — удалось ли найти необходимую информацию;
- faithfulness — насколько ответ опирается на найденный контекст.
Ragas предоставляет эти и другие метрики для оценки retrieval и качества ответов RAG-систем. Однако это не универсальный обязательный стандарт: набор метрик и методику оценки следует выбирать под конкретный тестовый набор. В частности, для полнотs контекста нужен эталонный ответ или набор референс.
При этом важно оценивать не только ответ LLM, но и сам retrieval. Если нужный документ не найден, улучшение промпта не исправит проблему поиска.
Что чаще всего снижает точность AI-поиска
На практике проблемы обычно связаны не с одной причиной.
1. Устаревшие документы
Система находит старый регламент, потому что он всё ещё похож на запрос.
2. Слишком большие фрагменты
В контекст попадает много текста, часть которого не относится к вопросу.
3. Слишком маленькие фрагменты
В найденном фрагменте отсутствуют условия или исключения.
4. Отсутствие метаданных
Поиск не может отличить действующий документ от архивного.
5. Дубли
Несколько одинаковых или похожих документов создают конкурирующие источники.
6. Внутренний жаргон
Один и тот же процесс описан разными терминами.
7. Только один тип поиска
Чистый vector search может плохо работать с точными названиями, кодами и аббревиатурами.
8. Отсутствие оценки
Команда не знает, улучшился ли поиск после изменений.
Как подготовка базы знаний связана с RAG
RAG нужен для того, чтобы языковая модель могла формировать ответы на основе корпоративных данных, которые не обязательно входили в её исходные обучающие данные.
В типовой схеме:
вопрос → retrieval → релевантные фрагменты → контекст → LLM → ответ
Поэтому подготовка базы знаний — не вспомогательная задача, а часть RAG-пайплайна.
Качество результата определяется сочетанием:
- качества данных;
- качества retrieval;
- структуры индекса;
- поисковой стратегии;
- контекста;
- модели;
- правил формирования ответа.
Современные системы также могут использовать более сложные варианты retrieval, при которых сложный пользовательский запрос разбивается на несколько поисковых подзапросов, а результаты объединяются перед формированием ответа.
Заключение
AI-поиск по документам — это не просто подключение языковой модели к корпоративному хранилищу.
Чтобы поиск по документам с помощью ИИ давал полезные ответы, необходимо подготовить сам источник данных: привести в порядок структуру документов, разбить длинные материалы на логические фрагменты, заполнить метаданные, удалить дубли, обозначить актуальные версии и учесть внутреннюю терминологию.
Начинать необязательно со всей базы знаний. Практичный подход — собрать 30–50 реальных вопросов сотрудников, определить документы, которые должны на них отвечать, и сначала привести в порядок 20–30 наиболее важных источников.
После этого качество AI-поиска можно измерять на контрольном наборе вопросов и постепенно улучшать retrieval, индексацию и контент.
Главный принцип простой: чем лучше подготовлена база знаний, тем меньше системе приходится угадывать, какой именно контекст нужен для ответа.
FAQ
AI-поиск оценивает смысловую близость фрагмента текста к запросу и передаёт найденный фрагмент языковой модели, которая формулирует ответ. Поиск по ключевым словам возвращает список документов с совпадающими словами. Промышленные системы используют оба механизма: смысловая близость находит переформулировки, точное совпадение — коды, аббревиатуры и имена.
Чанк — это один из фрагментов, на которые документ разбивается перед индексацией, и именно он служит единицей поиска. Типовой ориентир — 512 токенов, примерно 2000 знаков, с перекрытием около 25%; для русскоязычных регламентов чаще берут 500–800 токенов. Для автора это значит, что смысловой блок длиннее 2000 знаков нужно разбивать подзаголовками.
Нет. Требуется привести к единым правилам структуру заголовков, метаданные и терминологию, удалить дубли и заархивировать устаревшие редакции. Начинать разумно с 20–30 документов, которые закрывают основную часть вопросов сотрудников.
Работа делится на два контура. Содержание, статусы и владельцы разделов — зона владельцев контента. Фильтры по метаданным, дедупликация при индексации и реранкинг — зона команды внедрения.
GEO и AEO решают задачу попадания публичного сайта в ответы внешних AI-поисковиков для внешней аудитории. Подготовка базы знаний работает на точность ответов внутреннего ассистента для сотрудников и опирается на внутренние документы компании.
Предыдущая статья
