Сбор требований с RAG-моделями: настройка корпоративного ИИ-ассистента шаг за шагом

Тренд «сбор требований с RAG-моделями» меняет правила игры: теперь корпоративный ИИ-ассистент отвечает на вопросы по внутренним документам почти как опытный аналитик, что снижает цену ошибки на старте, но требует нового навыка — грамотной настройки AI-ассистента и дисциплины в данных (кто, что, где хранит и как обновляет).

Раньше сбор требований выглядел так: BA/PO бегает по людям, в лучшем случае — Confluence/1С-документы, в худшем — «Наташа из бухгалтерии знает». Теперь бизнес хочет кнопку: «спросил у ассистента — получил ответ с ссылкой на регламент». И это реально сделать. Но если вы думали, что RAG — это “поставили GPT и оно само”, то поздравляю: у вас будет дорогая чат-рулетка, а не корпоративный помощник.

Я видел два типа команд. Первые строят RAG как продукт: четкие требования, метрики, ответственность за контент. Вторые «прикручивают чатик» и удивляются, что он уверенно врёт, путает версии приказов и цитирует не то. Разница — в том, как вы делаете сбор требований rag-модели и как оформляете настройку ai-ассистента: не как магию, а как инженерный проект с рисками, сроками и критериями качества.

Что такое RAG в корпоративном ассистенте — на человеческом

Тезис

RAG (Retrieval-Augmented Generation) — это схема, где модель не «помнит всё», а сначала находит релевантные фрагменты в вашей базе знаний (retrieval), а потом формирует ответ на их основе (generation).

Обоснование (почему это важно)

В корпоративной среде знания живут в 1С, Битрикс24, Jira/YouTrack, Confluence, на сетевых шарах, в PDF, в приказах и письмах. Модель без RAG будет фантазировать, потому что она не знает ваши регламенты, тарифы, формы, SLA и «как у нас принято».

Практический вывод

Если вам нужен ассистент, который отвечает «по документу» и даёт ссылку/цитату — вам почти всегда нужен RAG, а не просто “чат с LLM”.

Подводный камень

RAG не спасает от бардака в документах. Он просто начинает быстро искать в бардаке. И да, будет находить «прошлогодний регламент» чаще, чем новый, если не настроить версии и приоритеты.

Сбор требований к RAG-модели: что спрашивать у бизнеса и ИТ

Тезис

Требования для RAG — это не «пусть отвечает на вопросы». Это перечень сценариев, источников данных, ограничений доступа, метрик качества и правил обновления знаний.

Обоснование (что реально спрашивают в вакансиях и проектах)

На рынке (и в России это особенно заметно) ценятся специалисты, которые могут связать «бизнес-задачу» с «данными и доступами». В описаниях ролей уровня Junior+/Middle в аналитике/продукте всё чаще встречается: работа с базами знаний, постановка задач на NLP/LLM, формулировка acceptance criteria, контроль качества ответов, защита данных (152‑ФЗ), разграничение прав.

Практический вывод

Пишите требования в формате: «пользователь X в системе Y задаёт вопрос Z → ассистент отвечает так-то, с источниками, с уровнем уверенности, в пределах прав доступа».

Подводный камень

Если не зафиксировать, что ассистент обязан давать ссылки на источники и “не знает — значит не отвечает”, вы получите эффект «самоуверенный стажёр на собеседовании».

Чек-лист вопросов для сбора требований (минимум, без философии)

Пользователи: кто будет пользоваться (HR, поддержка, продажи, бухгалтерия, ИТ)?
Сценарии: топ‑20 вопросов, которые реально задают каждый день (а не «когда-нибудь пригодится»).
Источники: где правда живёт (1С, Битрикс24, Confluence, локальные папки, PDF, письма)?
Актуальность: как часто обновляются документы, кто владелец, есть ли версии?
Доступы: какие группы, что можно/нельзя показывать (персональные данные, зарплаты, договоры)?
Формат ответа: кратко/подробно, нужен ли шаблон (например, «шаги + ссылки + контакт владельца процесса»).
Критерии качества: точность, полнота, доля ответов с ссылками, допустимый процент “не знаю”.
Инциденты: что считаем критической ошибкой (например, неверная инструкция по оплате/кадрам).

Шаг за шагом: настройка AI-ассистента на RAG

Шаг 1. Декомпозиция цели: «какую боль лечим»

Тезис: лучший старт — не «ассистент для всех», а один процесс и одна команда.

Обоснование: чем шире охват, тем хаотичнее источники и выше риск утечек. В корпорациях это быстро превращается в проект на полгода без эффекта.

Вывод: возьмите, например, поддержку сотрудников (FAQ по отпускам, командировкам, доступам) или поддержку клиентов (скрипты, регламенты, тарифы).

Подводный камень: если взять продажи и юристов одновременно, вы упрётесь в противоречащие документы и секретность.

Шаг 2. Инвентаризация знаний: «что кладём в RAG»

Тезис: RAG живёт на корпусе документов. Корпус — это ваш “датасет”, только текстовый.

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

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

Подводный камень: PDF-сканы и письма без структуры. Их придётся чистить, иначе поиск будет подсовывать мусор.

Шаг 3. Подготовка данных: чистка, версии, метаданные

Тезис: метаданные (дата, версия, подразделение, уровень доступа) — половина успеха.

Обоснование: retrieval работает лучше, когда может фильтровать. Например: «только документы HR, версия после 2024‑01‑01».

Вывод: договоритесь об обязательных полях и “правде о версии”.

Подводный камень: два одинаковых регламента в разных папках. RAG может выбрать старый, потому что он “популярнее” по текстовым совпадениям.

Шаг 4. Индексация и поиск: векторная база + правила

Тезис: RAG — это не только векторный поиск, но и здравые правила: фильтры, ограничения, приоритеты.

Обоснование: векторный поиск хорош в «похожих смыслах», но бизнес любит точность: правильный приказ, правильная форма, правильный тариф.

Вывод: комбинируйте: семантический поиск + ключевые слова + фильтрация по метаданным.

Подводный камень: “топ‑k” (сколько фрагментов отдаём модели). Слишком мало — не хватит контекста. Слишком много — ответ расплывётся и начнёт противоречить сам себе.

Шаг 5. Промпт и политика ответа: «как ассистент должен себя вести»

Тезис: корпоративный ассистент должен быть скучным и осторожным, а не «креативным».

Обоснование: креативность в регламентах = инцидент. Внутри компании ценят воспроизводимость: чтобы два сотрудника получили одинаковый ответ.

Вывод: фиксируйте правила: отвечай только по найденным источникам, цитируй, если не уверен — скажи «не нашёл» и предложи эскалацию.

Подводный камень: если не прописать запрет на выдумывание, модель будет “додумывать” недостающее, потому что так она обучена общаться.

Шаг 6. Оценка качества: метрики, тесты, пилот

Тезис: без измерений это не продукт, а демонстрация.

Обоснование: бизнесу нужны цифры: сколько обращений закрыли, сколько времени сэкономили, сколько ошибок допустили.

Вывод: соберите набор тестовых вопросов (50–200), разметьте “правильные” ответы, гоняйте регресс-тесты после обновлений корпуса.

Подводный камень: оценивать по «мне нравится». Нравится — не равно правильно, особенно в бухгалтерии и кадрах.

Таблица: требования vs технастройки (чтобы не потеряться)

Бизнес-требование	Как это реализуется в RAG	Чем мерить	Риск
Отвечать только по регламентам	Контекст только из retrieval + запрет на домыслы в политике ответа	% ответов с источниками	Галлюцинации без жёстких правил
Учитывать права доступа	Фильтры по группам, интеграция с SSO/AD, тегирование документов	0 инцидентов утечки	Показ “не того” документа
Всегда актуальная информация	Версионирование, расписание переиндексации, владелец источника	Доля ответов по новой версии	Старые приказы всплывают чаще
Быстро отвечает	Ограничение топ‑k, кэширование, нормальная инфраструктура	p95 latency (например, <5–8 сек)	Пользователи перестанут пользоваться

Два кейса из практики: один “в плюс”, другой “в минус”

Кейс 1 — удачный пилот (HR/внутренняя поддержка)

Команда начала с 60 HR-документов: отпуска, больничные, командировки, доступы к системам. Сделали реестр источников, назначили владельцев, добавили метаданные «подразделение/дата/версия», включили правило “если нет источника — не отвечай”. Итог: ассистент стал закрывать типовые вопросы, а HR перестал быть “живым поисковиком по PDF”. Ключевое: сбор требований rag-модели был не про «умный чат», а про конкретные сценарии и ограничения.

Кейс 2 — провал “потому что надо к квартальному отчёту”

Хотели «ассистента для всей компании» за месяц. В корпус закинули всё подряд: сетевые папки, старые презентации, письма, несколько конспектов из Teams. Доступы не настроили: решили “потом”. На демо ассистент выдал сотруднику инструкцию по процессу, который ему видеть нельзя. После этого проект заморозили “до лучших времен”, то есть навсегда. Мораль: настройка ai-ассистента без требований к безопасности — это не смелость, это халатность.

Коммерческие факторы: сколько это стоит и где прячутся расходы

Рынок цен на корпоративные внедрения в России разъезжается как курс рубля: зависит от масштаба, инфраструктуры и требований ИБ (информационной безопасности). Но структура затрат почти всегда одинаковая.

Интеграции с источниками (1С, Битрикс24, Confluence, файловые хранилища): часто дороже, чем “сама модель”.
Подготовка данных (чистка, разметка, версии): это часы аналитиков и контент-менеджеров.
Инфраструктура (серверы/облако, векторная БД, мониторинг): платите регулярно.
ИБ и доступы (SSO, аудит, журналирование): без этого в корпоративке вас не пустят в прод.
Поддержка: документы обновляются — значит, модель нужно переиндексировать и тестировать.

Скрытая цена обычно вот где: компания хочет “чтобы ассистент знал всё”, но не хочет назначать владельцев знаний. Без владельцев знания протухают. Ассистент начинает отвечать “по старинке”. Потом виноват кто? Конечно, ИИ.

Кстати, похожие разборы про IT-профессии, продуктовую аналитику и прикладной AI я публикую на https://itokno.ru

Экспертный вердикт и инструмент

Если вы новичок и хотите войти в IT через AI-тему: RAG — отличный “практичный мостик” между аналитикой и разработкой. Тут ценится не магия нейросетей, а умение делать сбор требований, описывать сценарии, работать с данными и проверять результат. Если вы уже в IT: RAG — шанс быстро принести бизнесу пользу, но только если вы не забыли, что корпоративный ИИ-ассистент — это система, а не фокус.

Чек-лист: 7 вопросов перед стартом проекта RAG-ассистента

Какие 20 вопросов ассистент должен закрывать в первую очередь (и кто их подтвердил)?
Где находятся “источники истины” и кто владелец каждого источника?
Какие документы запрещены для выдачи (и как это будет технически обеспечено)?
Что ассистент обязан показывать в ответе: цитаты, ссылки, дату версии?
Какая метрика успеха через 2–4 недели пилота: % закрытых обращений, экономия времени, снижение ошибок?
Что делаем, когда ассистент “не знает”: эскалация на человека, тикет в Jira/YouTrack, ссылка на форму?
Как часто обновляем индекс и как тестируем, что качество не упало?

Частые вопросы

RAG нужен всегда, или можно обойтись без него?

Если ассистент должен отвечать по внутренним документам компании и ссылаться на них — RAG почти неизбежен. Без него модель будет отвечать “в общем по миру”, а в корпоративных регламентах это быстро превращается в ошибки.

С чего начать новичку, чтобы попасть в проекты про RAG?

С навыка формализовать сценарии: топ вопросов, источники, правила доступа, критерии качества. Технически можно начать с прототипа на 1–2 источниках, но требования и метрики — ваш главный козырь.

Как заставить ассистента не выдумывать?

Жёстко: отвечать только на основе найденных фрагментов, всегда давать источники, а при отсутствии контекста говорить “не нашёл в базе” и предлагать эскалацию. Это часть политики ответа и критериев приёмки.

Какая самая частая причина провала RAG-ассистента?

Не модель и не “плохие промпты”, а отсутствие владельцев знаний и хаос в документах: версии не размечены, источники дублируются, доступы не определены. RAG просто ускоряет поиск — но не создаёт порядок.

Как оценивать качество ответов, если нет времени на сложную аналитику?

Минимум: набор из 50–100 типовых вопросов, ручная разметка “правильного ответа/источника”, и регулярная проверка после обновления базы. Плюс метрика: доля ответов со ссылками и доля “не знаю” (она должна быть, это нормально).

Что важнее: выбрать модель помощнее или лучше подготовить данные?

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

Можно ли сделать RAG внутри компании, не отправляя данные во внешние сервисы?

Да, архитектурно это возможно: хранение документов внутри периметра, локальная индексация, контроль доступов и журналирование. Но требования ИБ и инфраструктура могут повысить стоимость и сроки — это нужно отдельно закладывать в проект.