Как собрать AI-агента для работы с документами компании

Запрос «сделайте нам чат-бота по нашим документам» стал стандартной задачей 2024–2025 годов. За ним обычно скрывается одно и то же: сотрудники тратят часы на поиск нужного пункта в договоре, регламенте или базе знаний, и кто-то предложил заменить этот поиск разговором с моделью. Технически это RAG-агент — связка из поиска по документам и языковой модели, которая формулирует ответ. Собрать прототип можно за вечер на бесплатных инструментах. Довести его до состояния, которому доверяют юристы и бухгалтерия, — задача на недели. Разбираем, из чего он состоит, сколько стоит и где ломается.

Что такое RAG-агент и зачем он нужен

Языковая модель сама по себе не знает содержания ваших документов. Обучать её на них дорого и почти всегда избыточно. Вместо этого используют подход RAG*: документы разбивают на фрагменты, превращают в числовые векторы и складывают в специальную базу. Когда приходит вопрос, система находит наиболее близкие по смыслу фрагменты и передаёт их модели вместе с вопросом. Модель отвечает, опираясь только на переданный текст, а не на догадки.

Ключевое отличие от обычного чат-бота — ответ привязан к конкретным местам в документах. Хороший агент показывает источник: «пункт 4.2 договора поставки от такого-то числа». Без этой ссылки бизнес-пользователь не сможет проверить ответ, а без проверки такому инструменту в юридических и финансовых вопросах доверять нельзя.

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

Из каких частей собирается агент

Минимальный работающий контур состоит из четырёх блоков. Каждый можно заменить на аналог — от полностью облачного до полностью локального.

1. Загрузка и разбиение документов. PDF, DOCX, таблицы и письма приводят к тексту и режут на фрагменты по 500–1500 символов с перекрытием, чтобы не разрывать мысль на границе куска.
2. Векторизация и хранилище. Каждый фрагмент прогоняют через эмбеддинг-модель** и кладут в векторную базу — например, локальные Chroma или Qdrant, либо облачный сервис.
3. Поиск. Вопрос пользователя тоже векторизуют и ищут ближайшие фрагменты. Хорошая практика — гибридный поиск: сочетание векторного и обычного текстового по ключевым словам.
4. Генерация ответа. Найденные фрагменты и вопрос отдают языковой модели с инструкцией отвечать только по контексту и указывать источник.

Облако или свой сервер

Главная развилка — где обрабатываются документы. Если в базе лежат договоры с персональными данными, коммерческая тайна или медицинские сведения, отправка их в чужое облако может нарушать ваши же обязательства перед контрагентами и требования по защите данных. Сверяйте это с юристом до, а не после запуска.

Актуальные цены на облачные API и характеристики моделей проверяйте на официальных страницах провайдеров — они меняются каждые несколько месяцев, и подставлять сюда «вечную» цифру было бы обманом.

Пошаговый план запуска пилота

1. Возьмите один узкий сценарий: например, вопросы по внутреннему регламенту отпусков, а не «все документы компании сразу».
2. Соберите 20–30 реальных вопросов, которые сотрудники уже задавали, — это ваш тестовый набор.
3. Загрузите только те документы, что нужны для этого сценария. Меньше мусора — точнее поиск.
4. Настройте, чтобы ответ всегда содержал ссылку на источник, а при отсутствии данных агент говорил «в документах ответа нет», а не додумывал.
5. Прогоните тестовые вопросы и вручную проверьте каждый ответ. Считайте долю правильных, а не общее впечатление.
6. Расширяйте охват документов и сценариев только после того, как на узком наборе агент отвечает стабильно.

Кому это пригодится, а кому нет

Пригодится:

• Поддержке и HR, где сотрудники сотни раз в месяц ищут одно и то же в регламентах и инструкциях.
• Отделам продаж, которым нужно быстро найти условия в типовых договорах и прайсах.
• Аналитикам, которым важно найти нужный фрагмент в сотнях отчётов и понять, где смотреть дальше.

Не стоит полагаться:

• Там, где цена ошибки — деньги или иск: расчёт налога, вывод о законности сделки, толкование спорного пункта. Агент подскажет, где искать, но решение и ответственность остаются на человеке.
• Когда документов мало и они меняются каждый день: поддерживать актуальность базы дороже, чем читать глазами.
• Когда в базе противоречивые версии одного документа без пометок о дате — агент выдаст любую и не поймёт, какая действует.

Где такой агент чаще всего ломается

Три типовые проблемы. Первая — плохое разбиение: таблицы и сканы превращаются в кашу, и поиск не находит нужное. Вторая — устаревшая база: документ обновили, а векторы остались старые, агент отвечает по недействующей редакции. Третья — галлюцинации при пустом контексте: если поиск ничего не нашёл, слабо настроенная модель всё равно выдаёт правдоподобный, но выдуманный ответ. Каждую из них лечат на этапе настройки, но ни одна не решается сама по себе установкой готового инструмента.

* RAG (retrieval-augmented generation) — генерация ответа с опорой на найденные документы: модель не «вспоминает», а читает переданные ей фрагменты.

** Эмбеддинг-модель — модель, которая превращает текст в вектор чисел так, что близкие по смыслу тексты оказываются близко в пространстве векторов. На этом строится смысловой поиск.