Корпоративный RAG для данных и портала

Документация устаревает в Confluence, знания живут в головах инженеров, а новый сотрудник неделю ищет «какая процедура грузит FACT_Продажи». NevaDWH закрывает этот разрыв: Retrieval-Augmented Generation (RAG) — ответы модели опираются на ваши документы и код хранилища, а не на общие догадки LLM.

На платформе планируются два ассистента: помощник портала для пользователей и инженерный ассистент DWH для команды разработки. Точка входа — Neva AI.

Зачем бизнесу корпоративный RAG

• Самообслуживание пользователей: «где MetaData → SQL», «чем Debug SQL отличается от генератора» — ответ со ссылкой на нужный раздел портала, без тикета в IT.
• Онбординг DWH-инженеров: объяснение цепочек Landing → ODS → DWH, ролей схем mq / etl / staging / target и процедур загрузки — по фактическому коду проекта, а не по устаревшей wiki.
• Контур безопасности: модели и индекс можно держать on-prem / в вашем k8s. Знания не уходят в публичный ChatGPT.
• Учёт потребления: интеграция с корпоративным Identity и биллингом — кто спрашивал, сколько токенов, лимиты по компании.

Два ассистента — два контура знаний

Смешивать UX-документацию и исходники хранимых процедур в одном индексе нельзя: поиск начинает путать «где кнопка» и sp_*. Поэтому в архитектуре Neva — два изолированных workspace.

1. Помощник портала (Portal Helper)

• База: страницы документации Astro, описание разделов и сервисов платформы.
• Для кого: аналитики, администраторы, новые пользователи генератора и финансового модуля.
• Стиль ответа: короткие инструкции и прямые ссылки на разделы вроде MetaData → SQL или ROI генератора.

2. Инженерный ассистент DWH (Engineer)

• База: SQL-проекты (MS SQL / PostgreSQL), сервис очередей MQ, архитектурные заметки по слоям хранилища.
• Для кого: ETL/DWH-разработчики, сопровождение, архитекторы данных.
• Стиль ответа: разбор процедур, вызовы, различия диалектов, поток сообщений через очередь — с цитированием объектов схемы.

Как это устроено на платформе Neva

1. Локальная LLM (например, линейка Qwen / Llama 7–8B) на GPU-хосте через Ollama — подходит даже для карт класса 8GB при квантовании Q4.
2. AnythingLLM в Kubernetes: UI чата, загрузка документов, векторный индекс на PVC.
3. Конвейер знаний: экспорт документации и SQL в чистые документы → чанкинг → embeddings → обновление индекса при изменениях в репозитории.
4. Разграничение доступа через корпоративный Identity (SSO) и отдельные workspace для пользователей и разработчиков.

Генерация самого DWH по метаданным 1С остаётся задачей генератора NevaDWH. RAG не заменяет автоматизацию DDL/ETL — он делает знания о готовом хранилище и портале доступными за секунды.

Что получает заказчик

• Единая точка вопросов по продукту и по коду хранилища.
• Сокращение времени поиска по документации и SQL-проектам.
• Контролируемый контур: свои модели, свой кластер, свои лимиты токенов.
• Масштабируемый шаблон: те же принципы можно применить к внутренней wiki, runbook’ам и регламентам компании.

С чего начать

1. Откройте Neva AI и оцените текущий чат на локальной модели.
2. Изучите документацию по инструментам портала — MetaData → SQL, Import Data, Debug SQL.
3. Для полного цикла DWH — личный кабинет Генератор DWH и материал по экономике внедрения.

Корпоративный RAG на NevaDWH — следующий слой платформы: не только быстро собрать хранилище, но и быстро объяснить его людям.