Внутри компании лежат сотни документов: регламенты, инструкции, договоры, коммерческие предложения, переписка. Сотрудник не помнит, в каком из них ответ, и идёт спрашивать коллегу. Через какое-то время появляется идея: сделать бота, который отвечает по этим документам сам.
Идея рабочая, но не так, как её обычно представляют. Бот не держит ваши документы в памяти. Он ищет в них подходящие места и отвечает по найденному. Грабли начинаются здесь. Если поиск нашёл не тот кусок, бот уверенно скажет неправду; если документы противоречат друг другу, он повторит оба; если базу не обновлять, он будет отвечать по прошлогоднему регламенту.
Пример того, как спор о качестве бота решается по эталону, - в разборе AI-ассистента карьерных решений, который мы спроектировали.
Когда бот по документам нужен, а когда хватит поиска по папкам
Коротко: бот окупается, когда документов много, они меняются и ответ нужен каждый день. При десяти неизменных файлах дешевле навести порядок в папках.
Считайте вопросы. Число документов тут ни при чём. Если сотрудники задают одни и те же десять вопросов, а ответы лежат в одном регламенте, бот не нужен: нужна понятная папка и человек, который за неё отвечает.
Другое дело, когда вопросов сотни, они разные, а знание размазано по десяткам файлов, таблиц и систем. Тогда каждый ответ - это поиск. Продавец уточняет условия скидки, поддержка ищет срок гарантии, новый сотрудник разбирается, как оформляется заявка. Каждый такой поиск съедает время и часто заканчивается письмом коллеге.
Есть третий случай, ради которого всё и затевают. Ответ нужен снаружи. Клиент спрашивает про условия, и хочется, чтобы он получил ответ сам.
Скажем прямо. Часто выясняется, что задача решается без всякого ИИ и втрое дешевле, и это тоже результат. Если вся нужная информация - это одна страница с частыми вопросами, сначала сделайте её. Бот уместен, когда единой страницы не хватает и вопросов слишком много, чтобы разложить их руками.
Как бот находит ответ в документах
Коротко: перед ответом бот ищет в документах подходящие куски и отвечает по найденному. Если поиск ничего не нашёл, честный бот об этом скажет.
Устройство у таких ботов общее, и его полезно понимать, даже если вы не пишете код.
Сначала документы готовят. Каждый файл режут на куски - абзацы, разделы, страницы. Так делает и LangChain: сначала загрузка, потом нарезка, потом превращение в числа. Резать приходится потому, что документ целиком в ответ не помещается. По небольшим отрывкам удобнее искать по смыслу.
Потом каждый кусок превращают в набор чисел, чтобы близкие по смыслу отрывки оказались рядом. Microsoft описывает это как четыре шага: нарезка, эмбеддинги, хранилище с метаданными, отправка найденного в модель. Отдельная база для этого не обязательна: Selectel показывает, как поиск по смыслу собирается поверх обычного PostgreSQL.
Когда приходит вопрос, бот ищет в этой базе куски, близкие по смыслу к вопросу, и отдаёт их модели вместе с вопросом. Модель отвечает по этим кускам. Качество ответа задаёт найденный кусок.
Метаданные - это подписи, которые остаются при кусках: из какого файла, какая версия, какая дата, кому можно показывать. Без них бот не сошлётся на источник. И вы не поймёте, откуда взят ответ.
Почему бот выдумывает ответы и как это выключить
Коротко: без требования источника модель достраивает правдоподобное. Правило «нет источника - нет ответа» убирает выдумку, но бот начинает отказываться на часть вопросов.
Модель обучена продолжать текст так, чтобы он выглядел правдоподобно. Если найденные куски не отвечают на вопрос и правило молчать не задано, она соберёт ответ из того, что знает вообще. Разбор на Habr называет это прямо: модель отвечает настолько хорошо, насколько хорош контекст, а без релевантного поиска уверенно галлюцинирует.
Выдумка опаснее всего там, где ответ выглядит точным. «Срок гарантии - 14 месяцев» звучит так же уверенно, как верный ответ, и проверить его на глаз нельзя.
Лечится это одним требованием: у каждого факта в ответе должен быть источник, который виден рядом с ответом. Оригинальная работа про такой поиск (RAG) ещё в 2020 году называла указание на источник отдельной нерешённой задачей. Если источника нет, бот говорит, что в документах ответа не нашёл.
У этого есть цена: часть вопросов бот начнёт отклонять, хотя ответ где-то есть. Куски не нашлись, документ плохо порезан, вопрос сформулирован другими словами. Такой отказ - часть работы, не поломка.
Если вам нужен бот, который отвечает по вашим документам и показывает источник, - опишите задачу, состав работ и смету пришлём за 24 часа.
Что подготовить до первой строки кода
Коротко: до разработки нужны корпус документов, владелец базы и решение, кому бот отвечает.
Основная работа здесь - навести порядок в документах. Код придёт вторым. Пять шагов, которые стоит пройти до разговора с подрядчиком.
- Соберите документы в одно место. Нужен конкретный список: какие регламенты, инструкции, договоры и таблицы должен знать бот. Разбросанные по системам данные - одна из причин, по которой ассистент отвечает неверно. Об этом пишет CNews.
- Назначьте владельца базы. Это человек, который решает, какой документ считать правильным. Без него база быстро перестаёт отражать реальность.
- Решите, кому бот отвечает: сотрудникам, клиентам или обеим группам. От этого зависят права доступа и то, какие документы вообще можно показывать.
- Отметьте, что нельзя показывать никому. Зарплаты, персональные данные, коммерческие условия для отдельных клиентов.
- Договоритесь, что бот делает, когда ответа нет. Молчит и просит уточнить, передаёт человеку или отвечает своими словами. От этого выбора зависит доверие к нему.
Проверить себя просто: если на эти пять вопросов у вас есть ответы, задача готова к разработке. Если нет - вы ещё не готовы её заказывать, и любой подрядчик начнёт именно с них.
Что делать с устаревшими и противоречивыми документами
Коротко: приказ 2021 года и приказ 2024 года дадут оба ответ. Базу надо вести, иначе бот уверенно повторяет устаревшее.
У документов есть возраст, и он опаснее, чем кажется. Старый приказ и новый приказ от одного ведомства живут рядом, и бот честно найдёт оба. Он не знает, какой из них действующий, если вы это не отметили.
Технически это выглядит так: копия документа попадает в базу и индексируется отдельно от оригинала. В разборе Microsoft описан случай, когда бот отвечал по прошлой версии файла: индекс обновляется примерно каждые четыре-шесть часов, а статус «готов» не значит, что документ перечитан. По данным Atlan, базы без сопровождения заметно сдают через три-шесть месяцев: ответ остаётся уверенным, хотя данных уже нет.
Практический вывод простой. У каждого документа должен быть один хозяин и одна актуальная версия. Когда документ меняется, старая версия убирается из базы и не остаётся лежать рядом. Если документы противоречат друг другу, кто-то решает, какой из них правильный. Это решение человека.
Кому отвечает бот: сотрудникам или клиентам
Коротко: внутренний бот и бот для клиентов - разные задачи по доступу и риску. Снаружи нужны границы и проверка ответа.
Внутренний бот отвечает сотрудникам. Здесь риск в основном один: он покажет тому, кому не положено, чужой документ. Поэтому права проверяются на каждом вопросе, и лишний документ вообще не должен попасть в подборку. Так это устроено в Azure AI Search: доступ проверяется в момент запроса.
Внешний бот отвечает клиентам. Здесь добавляются два риска. Первый - утечка: если права настроены грубо, пользователь получит чужой документ, о чём предупреждает Kiteworks. Второй - попытка выманить ответ: клиент формулирует вопрос так, чтобы бот выдал внутреннюю инструкцию. Поэтому наружу бот отдаёт только те документы, которые и так публичны, и оставляет человеку последнее слово в спорных случаях.
Если бот отвечает и внутри, и снаружи, это по сути два бота с общей базой и разными правилами доступа. Проще закладывать это с самого начала, чем разделять потом.
Готовый сервис, шаблон или разработка под себя
Коротко: сервис, шаблон и своя разработка расходятся по контролю над данными, качеству ответа, обновлению базы, связи с системами и ответственности за ошибку.
Способов три, и каждый про свою ситуацию.
| Критерий | Готовый сервис | Шаблон своими силами | Разработка под себя |
|---|---|---|---|
| Где лежат документы | В облаке сервиса | Там, куда их положит ваш инженер | У вас или в вашем контуре |
| Качество ответа | Какое даёт сервис | Зависит от того, кто собирал | Задаётся требованиями и проверяется по эталону |
| Обновление базы | По регламенту сервиса | Вручную, вашими руками | По вашему регламенту, можно связать с системами |
| Связь с вашими системами | Ограничена возможностями сервиса | Через доработки | Под ваши системы и права |
| Кто отвечает за ошибку | Сервис, в рамках договора | Вы сами | Подрядчик, по критериям приёмки |
| Кому подходит | Быстрый старт на типовой задаче | Есть свой инженер, задача простая | Свои документы, свои права, свои системы |
Готовый сценарий существует: например, шаблон n8n берёт файлы из облачного диска, режет их, строит поиск и отдаёт агенту. Он полезен, чтобы понять устройство. Для рабочих документов с правами доступа его придётся серьёзно достраивать.
Готовый сервис хорош, пока задача типовая. Когда появляются свои правила доступа, связка с внутренними системами и жёсткие требования к ответу, начинается разработка - даже если формально вы «настраиваете сервис».
Как проверить, что бот отвечает правильно
Коротко: качество проверяют на наборе вопросов с заранее известными ответами, по числам. Впечатление «мне нравится» ничего не доказывает.
На встрече бот покажет лучший ответ. Платить вы будете за средний, поэтому качество проверяют на наборе вопросов.
Соберите свои вопросы заранее: 50-100 штук, с ответами, которые вы сами считаете верными. Такой набор советует и разбор на Habr. В него входят три вида: частые вопросы, редкие и «ловушки» - такие, где верный ответ «в документах этого нет».
Дальше считают числа. Первое число - верность. Это доля утверждений в ответе, которые подтверждает найденный документ. Если верность 0,6, значит около сорока процентов сказанного взято не из документов. Второе число - попадание поиска: нашёл ли бот нужный кусок в первых нескольких результатах. Как считать эти числа, подробно разбирает вторая статья на Habr; научная основа - работа про оценку таких систем.
Эти же числа ложатся в критерии приёмки. Работа считается принятой, когда бот на вашем наборе вопросов даёт ответ с источником не реже оговорённой доли и не выдумывает там, где в документах ответа нет.
Что записать в задачу подрядчику
Коротко: в задачу записывают список документов, кому бот отвечает, правило источника, где живёт база, кто её ведёт и как принимается работа.
Чем конкретнее задача, тем меньше споров на приёмке. Шесть пунктов, которых достаточно.
- Список документов и где они лежат: папки, база знаний, внутренние системы.
- Кому отвечает бот: сотрудникам, клиентам или обеим группам, и что нельзя показывать наружу.
- Правило источника: каждый факт со ссылкой на документ, а без источника - честный отказ.
- Где живёт база и кто её обновляет, как быстро изменение документа доходит до ответа.
- Набор вопросов с ответами, по которому вы будете принимать работу.
- Что считается браком: выдуманный факт, ответ без источника, показ запретного документа.
Пункт про брак забывают чаще всего. Без него спор «хорошо ли бот отвечает» решается на вкус. По делу его не решить.
Из чего складывается цена и срок
Коротко: смету двигают состояние документов, число интеграций и строгость приёмки. Точные цифры зависят от вашей задачи, но по этим трём пунктам видно, во что вы попадёте.
Цены не привожу: они зависят от вашей задачи, и любая цифра из статьи была бы выдумкой. Зато видно, что двигает смету сильнее всего.
Состояние документов. Десять аккуратных файлов и тысяча разнородных таблиц - разная работа. Если документы разбросаны по папкам, их сначала надо свести и разобрать, и это заметная часть сметы.
Число интеграций. Каждая связка с учётной системой, CRM или базой знаний добавляет работу. Иногда одна интеграция стоит дороже самого бота.
Строгость приёмки. Набор вопросов с порогом по верности ответов требует времени и на настройку, и на проверку. Зато на приёмке спор идёт по числам.
Отсюда и способ проверить смету. Попросите разбить её на эти части: документы, интеграции, настройка качества. Если в смете одна строка «разработка бота», вы не увидите, за что платите, и не сможете сравнить два предложения.
Экономит здесь одно. Чем раньше разобраны требования, тем меньше переделок. Ошибка в устройстве базы, найденная на приёмке, стоит заметно дороже, чем тот же вопрос, решённый до разработки.
Что ломается на практике
Коротко: чаще всего ломается база. Документы разошлись, базу перестали вести, права доступа не учли.
Типовых сбоев три.
Первый - поиск вытаскивает мусор. В одном разборе три плохих куска из ста семидесяти шести ломали ответы по всей базе: короткий обрывок текста оказывался «близок» к любому вопросу и вытеснял нормальные документы. Лечится фильтрами и аккуратной нарезкой, но обнаруживается только на проверке.
Второй - база устарела. Документы поменялись, а копии в базе остались. Бот отвечает по прошлому году, и по ответу это не видно.
Третий - права настроили грубо. Сотрудник получает документ, который ему не положен. Здесь ошибка стоит дороже всего, поэтому права закладывают в устройство сразу.
Про ожидания скажу отдельно. Бот по документам не заменяет специалиста. Он быстрее находит нужное место и всегда показывает источник. Решение по спорному вопросу всё равно принимает человек - и это правильно, потому что ответственность за ответ должна быть на ком-то конкретном.
Пример того, как ответ с источником превращает спор о качестве в проверяемый факт, - в разборе обработки первичных документов.
Источники
- Microsoft Learn. «Integrate Your Data into AI Apps with RAG» - https://learn.microsoft.com/en-us/dotnet/ai/conceptual/rag
- Microsoft Learn. «Document-Level Access Control» (Azure AI Search) - https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
- Amazon Web Services. «How Amazon Bedrock knowledge bases work» - https://docs.aws.amazon.com/bedrock/latest/userguide/kb-how-it-works.html
- LangChain. «Retrieval» - https://docs.langchain.com/oss/python/deepagents/retrieval
- Lewis et al. «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», 2020 - https://arxiv.org/abs/2005.11401
- Es et al. «RAGAS: Automated Evaluation of Retrieval Augmented Generation» - https://arxiv.org/abs/2309.15217
- Selectel. «Семантический поиск для RAG в PostgreSQL» - https://selectel.ru/blog/rag-semantic-search-postgresql-pgvector/
- CNews. «Что мешает ИИ-ассистенту корректно решать задачи сотрудников» - https://www.cnews.ru/articles/2026-09-29_chto_meshaet_ii-assistentu_otvechat
- Habr (OTUS). «RAG для тех, кто разочаровался» - https://habr.com/ru/companies/otus/articles/1034386/
- Habr (OTUS). «Как оценивать RAG-системы» - https://habr.com/ru/companies/otus/articles/1011464/
- Atlan. «LLM Knowledge Base Staleness» - https://atlan.com/know/llm-knowledge-base-staleness/
- Kiteworks. «RAG Pipeline Security Best Practices» - https://www.kiteworks.com/cybersecurity-risk-management/rag-pipeline-security-best-practices/
- n8n. Шаблон «Company knowledge base agent (RAG)» - https://n8n.io/workflows/6538-company-knowledge-base-agent-rag/
- Microsoft Learn Q&A. «SharePoint knowledge source returning old/stale file version» - https://learn.microsoft.com/en-in/answers/questions/5942736/copilot-studio-sharepoint-knowledge-source-returni
- Habr. «3 мусорных документа отравили весь RAG» - https://habr.com/ru/posts/1023042/
Если задача похожа на вашу, опишите её - пришлём состав работ и смету за 24 часа. Про то, как ИИ встраивается в рабочие процессы, у нас есть отдельный разбор.