Retrieval-Augmented Generation (RAG) — стандартный способ дать LLM доступ к корпоративным знаниям без дообучения модели на каждом новом регламенте. Идея проста: по вопросу пользователя система находит релевантные фрагменты документов, подставляет их в промпт и просит модель ответить с опорой на цитаты. На практике «простая идея» распадается на десятки решений: как резать текст, какие эмбеддинги, как обновлять индекс, как не утечь NDA в ответ конкуренту. Ниже — рабочая архитектура pipeline для среднего B2B и объяснение, почему загрузка всех файлов в один чат ChatGPT — тупиковый путь.
Перед подключением документов к модели стоит отдельно проверить права доступа в корпоративной RAG-системе: ограничения должны применяться к поиску, контексту и кешу ответа, а не только к отображению ссылок.
Pipeline: от документа до ответа
Типичный production-контур выглядит так:
- Ingestion — мониторинг папок SharePoint, Confluence, S3, почтовых архивов или выгрузок из CRM. Фиксируются версия, автор, ACL.
- Parsing — из PDF извлекаются таблицы и заголовки (не «сплошной текст»), из Word — стили, из Wiki — якоря разделов.
- Chunking — нарезка 300–800 токенов с overlap и метаданными (продукт, регион, дата действия регламента).
- Embedding + index — векторное хранилище (pgvector, Qdrant, OpenSearch k-NN) плюс часто BM25 для гибридного поиска.
- Retrieval — top-k чанков, reranker (cross-encoder или lightweight LLM), фильтр по правам пользователя.
- Generation — промпт с инструкцией «отвечай только по контексту; если данных нет — скажи об этом».
- Observability — лог запроса, id чанков, feedback оператора; метрики hit rate и hallucination rate на исследовательских выборках.
Между retrieval и generation часто вставляют лёгкий AI-агент: не один shot, а уточняющий поиск, если первый проход дал низкий score.
Почему «залить всё в ChatGPT» не масштабируется
Корпоративный ChatGPT / Projects удобен для прототипа, но ломается на границах:
- ACL — у сотрудников разные допуски; общий проект либо слишком узкий, либо слишком широкий.
- Актуальность — регламент изменился в 1С или Wiki, а в чате старая версия до ручного re-upload.
- Объём — лимиты контекста и стоимость; нельзя индексировать 200 ГБ техдокументации в одном окне.
- Аудит — сложно доказать, из какого пункта договора взят ответ при претензии клиента.
- Интеграция — нет связки «ответ → создать сделку / задачу» без отдельного middleware к Bitrix24 или ERP.
RAG в вашем контуре (VPC, выбранный провайдер LLM, свои ключи) даёт контроль над данными и возможность встроить ответ в портал, бота или 1С.
Источники: PDF, Word, Wiki, CRM
PDF — главный источник боли: сканы без OCR, многоколонная вёрстка, приложения. Без нормального parsing retrieval находит «обрывки» и модель достраивает фантазию. Решение: OCR pipeline, сохранение номера страницы в metadata для ссылок «источник, стр. 12».
Word — проще, если использовать структуру заголовков как границы чанков. Версионность через Git или DMS обязательна.
Wiki (Confluence, Notion, internal) — live sync по API лучше, чем раз в месяц export. Важно инвалидировать чанки при edit.
CRM — не только «текстовые поля сделок», но и связанные письма, если политика позволяет. RAG по CRM почти всегда требует row-level security: менеджер видит только свои клиенты. Это ближе к операционным сценариям, описанным в кейсах внедрения.
Типичные ошибки (и как их избежать)
1. Слишком крупные или мелкие чанки
Целый договор в одном embedding — retrieval промахивается по конкретному пункту. Абзац в 50 токенов теряет контекст «к какому разделу относится». Калибруйте на реальных вопросах поддержки.
2. Один embedding на все языки и домены
Техдок на английском и приказы на русском в одной модели без фильтра — шум. Используйте metadata filters и при необходимости разные коллекции.
3. Нет гибридного поиска
Артикулы, ИНН, номера заказов плохо ловятся «семантикой». BM25 + vectors — baseline для commerce и logistics.
4. Игнорирование negative answers
Модель обязана уметь сказать «в базе нет данных» — иначе галлюцинации выглядят убедительнее правды. Тестируйте на adversarial questions.
5. RAG без метрик ROI
Сокращение времени поиска регламента измеримо; «стало удобнее» — нет. Свяжите пилот с моделью из статьи расчёта экономического эффекта от ИИ.
6. Пропуск legal / ПДн
Индексировать всю почту без redaction — прямой путь к инциденту. На этапе ingestion — классификация чувствительных полей.
Связка RAG и action
Знание без действия закрывает только часть запросов. Следующий уровень — агент с tools: RAG для фактов, API для создания задач. Для учётных систем смотрите подключение LLM к 1С через контролируемые HTTP-сервисы, а не произвольный SQL. Авторские заметки по архитектуре — у Александра Тимофеева.
Итог: RAG — не «фича чата», а продуктовая линия с ingestion, правами и мониторингом. Начните с одного домена (например, поддержка одного продукта), зафиксируйте golden set вопросов и только потом расширяйте источники.
Метаданные и governance
К каждому чанку добавляйте поля: doc_id, version, valid_from, audience, product_line. Retrieval без фильтра по audience — частая причина утечки внутренних цен в ответ клиенту на портале. Governance council из legal + product + IT утверждает список источников truth и SLA обновления: Wiki — 24 часа, PDF договоров — по событию подписания. Для спорных ответов UI показывает цитату и кнопку «сообщить об ошибке», feedback идёт в очередь на re-index или правку регламента.
Гибридный поиск и reranker имеют стоимость; на больших объёмах кэшируйте embedding запроса на 5–15 минут для повторяющихся FAQ. Связка с операционными системами — через агента, а не через «один чат на все отделы»; см. Bitrix24 и 1С как типовые sink для actions после ответа.
На этапе пилота зафиксируйте 50–100 реальных вопросов от поддержки и продаж с эталонными ответами и ссылками на пункты регламентов. Еженедельно прогоняйте их через pipeline и измеряйте citation accuracy: совпал ли top-1 чанк с ожидаемым разделом. Без этого команда оптимизирует «красивый ответ», а не «правильный источник».