Обычная языковая модель знает то, чему её научили во время обучения. Но она не знает внутренние инструкции конкретного предприятия, актуальные договоры, технические регламенты, проектную документацию или последние изменения в корпоративной базе знаний.
Можно попытаться передавать документы модели непосредственно в каждом запросе. На небольшом объёме данных это работает. Но по мере роста базы появляются ограничения по размеру контекста, стоимость обработки, задержки и проблемы с контролем доступа.
Что такое RAG
RAG (Retrieval-Augmented Generation) — архитектурный подход, в котором генерация ответа языковой моделью дополняется поиском по внешнему набору данных.
Вместо схемы:
получается:
↓
Query processing
↓
Поиск релевантных фрагментов
↓
Context
↓
LLM
↓
Ответ + источники
Главная идея проста: модель не обязана помнить корпоративные знания — приложение должно уметь их найти.
Почему нельзя просто загрузить все документы в ChatGPT
На практике корпоративная база быстро становится слишком большой. В ней могут находиться тысячи договоров, сотни инструкций, десятки тысяч страниц технической документации и постоянно меняющиеся данные.
Кроме объёма есть ещё одна проблема — актуальность. Если документ изменился сегодня, не хочется ждать переобучения модели или создавать новый специализированный AI-модельный контур.
RAG отделяет знания от модели:
Индекс — механизм быстрого поиска.
LLM — механизм понимания вопроса и формирования ответа.
Документы можно обновлять независимо от модели. Это одна из главных причин, почему RAG хорошо подходит для постоянно меняющейся корпоративной информации.
Как RAG работает внутри
Типичный pipeline состоит из двух отдельных процессов: индексации и ответа на запрос.
Этап 1. Индексация документов
Система получает документы из файлового хранилища, DMS, корпоративного портала или другого источника.
↓
Parsing
↓
Очистка текста
↓
Chunking
↓
Embeddings
↓
Vector Store
Документ обычно не помещают в индекс одним огромным блоком. Его разбивают на более мелкие фрагменты — chunks. Для каждого фрагмента сохраняется текст, метаданные и векторное представление.
Этап 2. Поиск
Пользователь задаёт вопрос. Система преобразует запрос в поисковое представление и ищет наиболее релевантные фрагменты.
↓
Query embedding
↓
Vector search
↓
Top-K chunks
Этап 3. Генерация ответа
Найденные фрагменты становятся контекстом для LLM.
+
Retrieved context
↓
Local LLM / Cloud LLM
↓
Answer
Хорошая реализация также возвращает пользователю ссылки или идентификаторы документов, на основании которых был сформирован ответ.
Что такое embeddings
Для семантического поиска текст нужно представить в виде числового вектора. Такой вектор называется embedding.
Упрощённо можно представить, что близкие по смыслу фразы оказываются близко друг к другу в многомерном пространстве.
Например:
и
«Процедура возврата продукции контрагенту»
могут оказаться семантически близкими, даже если в них используются разные слова.
Именно это отличает векторный поиск от обычного поиска по точному совпадению слов.
RAG и обычный поиск — не одно и то же
Для корпоративной базы знаний часто полезно сочетать несколько видов поиска.
| Подход | Сильная сторона | Пример |
|---|---|---|
| Full-text | Точные термины и номера | «Договор № 184» |
| Vector search | Семантическое сходство | «Как оформить возврат?» |
| Hybrid search | Комбинация обоих подходов | Термин + смысл вопроса |
Для Enterprise-сценариев hybrid search часто оказывается практичнее, чем ставка только на embeddings.
Где хранить векторы
Для RAG нужен vector store. Это может быть отдельная специализированная система или существующая база данных с поддержкой векторного поиска.
Если компания уже использует PostgreSQL, одним из вариантов является pgvector. Тогда технические метаданные, документы и embeddings можно хранить в одном основном контуре.
├── documents
├── document_chunks
├── permissions
└── embeddings
Это не означает, что PostgreSQL всегда является лучшим вариантом. Выбор хранилища зависит от объёма данных, требований к latency, нагрузки и уже существующей инфраструктуры.
RAG на PostgreSQL + Symfony
Для Symfony-приложения можно построить RAG-контур без отдельной AI-платформы.
↓
Symfony Controller / API
↓
Query Service
↓
PostgreSQL + Vector Search
↓
Relevant Chunks
↓
Symfony AI
↓
Ollama / Cloud LLM
↓
Answer + Sources
Symfony при этом остаётся ответственным за application layer: авторизацию, бизнес-правила, выбор документов, сбор контекста, вызов модели и формирование ответа.
Почему права доступа — самая важная часть корпоративного RAG
Для публичного FAQ достаточно найти правильный документ. В корпоративной системе этого недостаточно.
Представим, что в базе есть:
- общие инструкции;
- финансовые документы;
- договоры клиентов;
- кадровые документы;
- техническая документация;
- внутренние коммерческие условия.
Пользователь не должен получить фрагмент документа только потому, что semantic search посчитал его релевантным.
Поэтому ACL должна применяться до передачи контекста модели.
↓
Authentication
↓
Permission filter
↓
Vector search
↓
Allowed chunks only
↓
LLM
Это принципиально: нейросеть не должна быть механизмом авторизации. Она получает только те данные, которые приложение уже разрешило использовать.
RAG и локальная модель Ollama
RAG особенно хорошо сочетается с локальными моделями.
В таком варианте корпоративный контур может выглядеть следующим образом:
↓
Parser / Chunker
↓
Embeddings
↓
PostgreSQL + pgvector
↓
Symfony AI / RAG Service
↓
Ollama
↓
Local LLM
↓
Ответ
При таком подходе и документы, и индекс, и генерация ответа могут находиться внутри корпоративного контура. Конкретная модель и конфигурация при этом должны соответствовать требованиям проекта и условиям лицензии.
Что можно спрашивать у корпоративного RAG
После построения базы знаний пользователь получает привычный интерфейс вопрос-ответ.
Например:
- «Какие документы нужны для возврата товара?»
- «Какие условия оплаты предусмотрены договором с клиентом?»
- «Какой порядок согласования закупки?»
- «Какие требования указаны в инструкции по запуску оборудования?»
- «Какие изменения внесены в регламент после последней версии?»
Вместо поиска по десяткам файлов сотрудник получает ответ и список источников.
RAG поверх 1С
RAG можно строить не только по PDF и DOCX. Источником контекста могут быть данные корпоративных систем.
Например:
CRM ──────┤
WMS ──────┤
Документы ┤
Wiki ─────┘
↓
Knowledge Layer
↓
Retrieval
↓
LLM
При этом не обязательно превращать каждую запись 1С в embedding. Для структурированных данных часто правильнее использовать обычные SQL-запросы, а RAG применять для документов и неструктурированного текста.
Именно поэтому хороший корпоративный AI часто является гибридом RAG + SQL + API, а не только векторной базы.
RAG не заменяет SQL
Если руководитель спрашивает:
это прежде всего задача работы со структурированными данными.
Если вопрос звучит:
здесь уже может понадобиться поиск по договору.
А вопрос:
может потребовать комбинацию SQL, документов и reasoning модели.
Именно здесь появляется AI orchestration
В зрелой архитектуре AI сам не должен решать, откуда брать данные. Backend определяет допустимые источники и вызывает соответствующие инструменты.
↓
AI Router / Agent
├── SQL → PostgreSQL
├── RAG → Documents
├── API → 1С / CRM
└── Search → Knowledge Base
↓
Context aggregation
↓
LLM
↓
Answer
Такой подход гораздо ближе к реальному корпоративному AI, чем просто чат с загруженными файлами.
Как правильно разбивать документы на chunks
Качество RAG сильно зависит от того, как документы индексируются.
Если chunk слишком большой, в контекст попадает много лишнего текста. Если слишком маленький — теряется смысл исходного раздела.
Поэтому обычно учитывают:
- заголовки разделов;
- абзацы;
- таблицы;
- списки;
- связь с родительским документом;
- номер страницы или раздела;
- дату и версию документа.
Для технической документации особенно важно не резать текст исключительно по фиксированному количеству символов. Структура документа часто важнее одинакового размера chunks.
Что хранить вместе с chunk
Вектор без метаданных мало полезен для production-системы.
Для каждого фрагмента желательно иметь хотя бы:
{
"document_id": 184,
"title": "Регламент закупок",
"version": "3.2",
"section": "Согласование заявки",
"page": 17,
"department": "procurement",
"access_level": "internal",
"updated_at": "2026-09-10"
}Эти данные помогают фильтровать результаты, показывать источники пользователю и поддерживать актуальность индекса.
Что происходит при обновлении документа
В production-системе документы постоянно меняются. Поэтому индексация должна быть отдельным асинхронным процессом.
↓
Messenger / Queue
↓
Parse
↓
Re-chunk
↓
Re-embed
↓
Update index
Это позволяет не блокировать пользовательские запросы во время обработки больших документов.
Как бороться с галлюцинациями
RAG уменьшает вероятность ответа без источника, но сам по себе не гарантирует достоверность.
Практические меры:
- передавать модели только найденный и разрешённый контекст;
- просить отвечать только на основании предоставленных источников;
- возвращать ссылки на документы и страницы;
- использовать порог релевантности;
- если релевантного контекста нет — возвращать «не найдено», а не придумывать ответ;
- проверять критичные ответы бизнес-правилами или человеком.
RAG в закрытом контуре предприятия
Для предприятий с повышенными требованиями к изоляции можно построить полностью локальный контур:
│
├── DMS / Файлы
├── 1С
├── CRM
├── PostgreSQL
│
└── AI Server
├── RAG Service
├── Vector Store
└── Ollama + Local LLM
В таком варианте внешний AI API вообще не является обязательным компонентом. Это особенно интересно для on-premise и air-gapped инфраструктуры, где внешние сервисы использовать нельзя или нежелательно.
Типичные ошибки при создании корпоративного RAG
- Загрузить документы и сразу назвать это RAG. Нужны ingestion, chunking, embeddings, retrieval и контроль доступа.
- Не хранить источники. Пользователь должен понимать, откуда взялся ответ.
- Индексировать всё подряд. Не каждый источник имеет одинаковую актуальность и ценность.
- Игнорировать ACL. Поиск не должен обходить права пользователя.
- Использовать только vector search. Точные номера договоров и терминов часто лучше находятся через full-text.
- Отправлять в LLM слишком много контекста. Больше текста не означает больше качества.
- Не обновлять индекс. Устаревший RAG может быть опаснее отсутствия RAG.
- Использовать LLM вместо базы данных. Структурированные показатели нужно получать из SQL/API, а не просить модель угадывать их.
Как запустить корпоративный RAG как MVP
Не нужно начинать с нескольких миллионов документов.
Для первого пилота достаточно одного понятного набора:
- 50–500 корпоративных документов;
- парсер PDF/DOCX;
- chunking и metadata;
- embeddings;
- PostgreSQL + vector search;
- Symfony API;
- Ollama + локальная модель;
- чат с ответом и источниками.
После этого можно измерить не «насколько круто выглядит AI», а конкретные показатели: долю вопросов с найденным ответом, качество retrieval, точность ответа, latency и количество вопросов, которые сотруднику больше не приходится искать вручную.
RAG + Symfony AI + Ollama: рекомендуемый контур
↓
Ingestion Service
↓
Parser → Chunker → Embeddings
↓
PostgreSQL + pgvector
↓
Symfony RAG Service
├── ACL
├── Hybrid Search
├── Context Builder
└── Source Tracking
↓
Symfony AI
↓
Ollama
↓
Local LLM
↓
Answer + Sources
Такой контур хорошо масштабируется от внутреннего FAQ до полноценного корпоративного AI-ассистента. При этом каждый компонент отвечает за свою задачу: хранилище хранит данные, retrieval ищет, Symfony управляет процессом, а LLM интерпретирует найденный контекст.
Вывод
RAG по корпоративным документам — это способ дать AI доступ к актуальным знаниям компании без необходимости обучать модель на каждом новом документе.
Но ценность RAG находится не в самом vector database. Реальная система состоит из нескольких частей: ingestion, chunking, embeddings, retrieval, ACL, context building, LLM и источников ответа.
Для локального корпоративного AI интересна связка Symfony AI + Ollama + PostgreSQL/pgvector. Она позволяет построить AI-контур внутри собственной инфраструктуры и постепенно расширять его: от документов — к 1С, CRM, WMS, внутренним API и управленческой аналитике.
И тогда корпоративный AI перестаёт быть отдельным чат-окном. Он становится ещё одним слоем информационной системы, который умеет найти нужные знания, понять вопрос и вернуть сотруднику ответ непосредственно внутри бизнес-процесса.
По теме: если вы рассматриваете локальный AI для корпоративной инфраструктуры, посмотрите Ollama и локальные AI-модели для бизнеса и Почему ChatGPT не знает ваш бизнес, даже если есть 1С.
