RAG для системных аналитиков: строим базу знаний на LLM

Если вам приходилось тратить час на поиск того самого ADR трёхмесячной давности, который объясняет, почему шлюз оплаты спроектирован именно так — добро пожаловать в клуб. Аналитик работает с дикой концентрацией текста: ТЗ, протоколы встреч, архитектурные решения, спецификации API, переписка в трекере задач. Всё это оседает в Confluence, Jira и Google Docs, но найти связь между «требованием про возвраты из прошлого спринта» и «ADR-003 про платёжный шлюз» приходится вручную. Пальцами по клавиатуре, глазами по документу.

RAG (Retrieval-Augmented Generation) решает эту проблему иначе. Вместо того чтобы учить модель на ваших документах с нуля (fine-tuning), вы даёте LLM доступ к поиску по вашей базе знаний прямо во время генерации ответа. Модель не «знает» ваши ADR заранее — она находит их по запросу и опирается на найденное. Как если бы у вас был ассистент, который перед ответом на любой вопрос пробегает глазами по всем вашим документам и находит релевантные куски. За секунды.

Что такое RAG и зачем он аналитику

RAG (Retrieval-Augmented Generation) — архитектурный паттерн, при котором LLM перед генерацией ответа получает доступ к внешнему хранилищу документов через семантический поиск. Модель не обучается на этих данных — она ищет их в момент запроса.

Ключевое отличие от fine-tuning: модель остаётся «чистой», а знания лежат отдельно. Добавили новый ADR — он сразу доступен. Удалили устаревшее ТЗ — модель про него «забыла». Никаких циклов переобучения.

Что это даёт системному аналитику:

• Поиск по ADR и требованиям — спрашиваете «какие решения касаются аутентификации пользователей» и получаете список ADR с пояснениями, а не просто ссылки.
• Проверка новых требований на конфликты — загружаете черновик требования, RAG находит похожие и противоречащие записи.
• Ввод новых аналитиков в проект — вместо «почитай вики» даёте чат-интерфейс к базе знаний проекта.
• Подготовка к встречам — «что мы уже решили по интеграции с CRM за последние полгода?»

Примечательно, что из всех AI-инструментов для аналитика RAG — самый недооценённый. О нём говорят в контексте чат-ботов для клиентов, но почти не обсуждают его применение внутри команды. А зря.

Как работает RAG: pipeline от документа до ответа

Разберём пайплайн на уровне архитектурных решений — без кода, но с пониманием, какие компоненты за что отвечают.

graph LR
  A["Документы<br/>ТЗ, ADR, переписка"] --> B["Чанкер<br/>разбиение на фрагменты"]
  B --> C["Embedding Model<br/>векторизация чанков"]
  C --> D["Векторная БД<br/>PGVector / Qdrant"]
  E["Запрос аналитика<br/>«Есть ли требования к безопасности?»"] --> F["Embedding Model<br/>векторизация запроса"]
  F --> D
  D --> G["Retrieval<br/>поиск top-K чанков"]
  G --> H["Контекст<br/>чанки + запрос"]
  H --> I["LLM<br/>генерация ответа"]
  I --> J["Ответ аналитику<br/>со ссылками на источники"]
  
  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#7b68ee,stroke:#5a4db2,color:#fff
  style C fill:#f0a500,stroke:#c88400,color:#fff
  style D fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style E fill:#50c878,stroke:#3a9a5c,color:#fff
  style F fill:#f0a500,stroke:#c88400,color:#fff
  style G fill:#7b68ee,stroke:#5a4db2,color:#fff
  style H fill:#e0e0e0,stroke:#999,color:#000
  style I fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style J fill:#50c878,stroke:#3a9a5c,color:#fff

На диаграмме — два параллельных потока. Левый (офлайн, синий): индексация документов — ТЗ, ADR и переписка разбиваются на чанки, векторизуются через embedding-модель и попадают в векторную базу данных. Правый (онлайн, зелёный): запрос аналитика векторизуется той же моделью, по нему ищутся ближайшие чанки, они добавляются в контекст LLM, и модель генерирует ответ.

Важный момент: embedding-модель для запроса и для документов — одна и та же. Если документы индексировались через text-embedding-3-large, а запрос векторизуется через другую модель — семантическая близость будет посчитана некорректно, и retrieval вернёт мусор.

Проектирование RAG-пайплайна: практические решения

Стратегии разбиения на чанки

Чанк — это фрагмент документа, который будет проиндексирован и возвращён при поиске. От размера и стратегии разбиения зависит качество ответов напрямую.

Для базы знаний аналитика оптимальна semantic-стратегия с размером чанка 400–600 токенов. ADR обычно укладываются в 1–3 таких чанка (решение + контекст + последствия), а ТЗ требуют более тонкой нарезки по разделам.

Стоит отметить: если разбить ADR на чанки по 100 токенов — при запросе «как мы решили вопрос с платёжным шлюзом» retrieval вернёт три несвязанных обрывка фраз. LLM честно попытается собрать из них ответ — и выдаст правдоподобную, но ложную интерпретацию. Классический галлюциноз от плохого чанкинга.

Выбор embedding-модели

Embedding-модель превращает текст в вектор чисел, по которому считается семантическая близость. Для русского языка и аналитической терминологии выбор имеет значение.

Если вы поднимаете RAG локально через self-hosted модель — multilingual-e5-large или BGE-M3 дают качество, близкое к OpenAI, без затрат на API. Но надо помнить: они требуют GPU с 8+ ГБ видеопамяти. Для прототипа на коленке text-embedding-3-small через API — простейший путь.

Векторная база данных: что выбрать

Векторная БД хранит эмбеддинги и умеет быстро искать ближайших соседей. Выбор богатый:

Для команды аналитиков с 3–5 человеками, парой тысяч ADR и ТЗ — PGVector на существующем PostgreSQL закроет потребности полностью. Qdrant стоит брать, когда нужна фильтрация по метаданным (например, «найди ADR за 2025 год от команды биллинга»). Chroma — для прототипа, который вы показываете техлиду через неделю. Milvus — когда объём документов перевалил за миллион и вы всерьёз решили скормить LLM всю историю компании.

Retrieval-стратегии: не просто nearest neighbour

Базовый retrieval — найти K ближайших чанков по косинусному расстоянию. Но в реальных сценариях этого недостаточно.

HyDE (Hypothetical Document Embeddings). Перед поиском LLM генерирует гипотетический идеальный документ-ответ на вопрос аналитика. Затем embedding этого гипотетического документа используется для поиска настоящих чанков. Звучит оксюмороном — модель придумывает, что искать — но работает. Для вопроса «какие у нас есть требования к отказоустойчивости» модель сгенерирует что-то вроде «система должна выдерживать отказ одного узла без потери данных, RTO ≤ 15 минут» — и этот текст даст более точный вектор для поиска, чем сам вопрос.

Re-ranking. После retrieval берём не K=5, а K=20 чанков и прогоняем их через отдельную re-ranking модель (Cohere Rerank, cross-encoder), которая оценивает релевантность каждого чанка именно этому запросу. Из 20 оставляем 5 самых релевантных. Дороже по latency, но драматически улучшает качество.

Metadata filtering. Самый недооценённый приём. Если при индексации ADR вы сохраняете метаданные (дата, автор, статус, команда, теги), то можете сузить поиск до «ADR команды биллинга за 2025 год со статусом Accepted». Без фильтрации retrieval может вернуть устаревший ADR, который был отвергнут два года назад — и LLM добросовестно сошлётся на него.

Кейс: проверка новых требований через ADR и RAG

Рассмотрим сквозной пример. Вы получили новое требование: «Добавить оплату через Telegram» в систему, где уже есть ADR-003, зафиксировавший архитектуру платёжного шлюза как единой точки входа для всех платежей.

sequenceDiagram
  participant A as Аналитик
  participant LLM as LLM + RAG
  participant VB as Векторная БД<br/>(ADR)
  participant TZ as Чеклист<br/>требований
  
  A->>LLM: Новое требование:<br/>«Оплата через Telegram»
  LLM->>VB: Поиск похожих ADR<br/>(embedding запроса)
  VB-->>LLM: ADR-003: Платёжный шлюз<br/>ADR-007: Интеграция с внешними API
  
  LLM->>LLM: Анализ на противоречия<br/>с существующими решениями
  
  LLM->>A: Найдено:<br/>ADR-003 уже предполагает единый gateway,<br/>Telegram-оплата ломает эту модель
  
  A->>LLM: Уточнение:<br/>«Telegram Payments API — это тот же gateway»
  LLM->>VB: Повторный поиск<br/>с расширенным контекстом
  
  LLM->>TZ: Проверка по чеклисту НФТ:<br/>безопасность, отказоустойчивость
  
  TZ-->>LLM: Пропущено:<br/>нет требований к timeout<br/>и обработке ошибок Telegram API
  
  LLM->>A: Итоговая проверка:<br/>1. Конфликт с ADR-003 решён (gateway).<br/>2. Добавь timeout и retry policy.<br/>3. Зафиксируй ADR-008.

Диаграмма показывает итеративный процесс: аналитик вносит новое требование, RAG находит конфликт с ADR-003, аналитик уточняет контекст, система перепроверяет и дополнительно находит пробелы по чеклисту нефункциональных требований. В результате вы не просто получаете ответ «всё ок» или «конфликт», а проходите полноценный цикл верификации с экономией времени на ручном перечитывании документации.

Это не серебряная пуля — финальное решение всё равно за аналитиком. Но вместо часа на поиск и сопоставление документов вы тратите 5 минут на диалог с RAG и 10 минут на осмысление результатов.

Если практика ADR вам незнакома — начните с ADR: Architecture Decision Records — зачем и как документировать архитектурные решения. Без формализованных решений RAG-у будет просто нечего искать.

Ограничения RAG и когда это не работает

Честно о границах применимости — чтобы не было иллюзий.

• Garbage in — garbage out. Если ADR написаны в стиле «решили сделать хорошо», RAG найдёт их, но LLM не извлечёт из них смысла. Качество ответа ограничено качеством документации. Это тавтология, но про неё забывают после первого успешного демо.

• Контекстное окно. У LLM есть лимит на объём контекста. Если retrieval вернул 10 чанков по 512 токенов — это 5120 токенов контекста, плюс системный промпт, плюс история диалога. На моделях с окном 8K токенов легко упереться в потолок. Решение: агрессивный re-ranking (оставлять 3–5 чанков, а не 10) и суммаризация чанков перед подачей в LLM.

• Отсутствие действительно новых знаний. RAG находит то, что уже записано. Если в проекте никто не формализовал требования к безопасности — RAG не придумает их за вас. Он скажет «не найдено», а не «похоже, вам стоит добавить». Тут нужен другой инструмент — например, AI-ассистент аналитика на MCP: как подключить LLM к Jira, Confluence и БД, который может не только искать, но и подключаться к живым источникам данных в Jira и Confluence.

• Стоимость на больших объёмах. Индексация 10 000 документов через text-embedding-3-large стоит около $1.30. Каждый запрос с retrieval K=10 и генерацией через GPT-4o — ещё$0.01–0.03. Для команды из 5 аналитиков с 50 запросами в день — около $20–40 в месяц на API. Не дорого. Но если вы решите проиндексировать всю историю переписки в Slack за 5 лет — бюджет станет заметным.

Заключение

RAG — это не магия и не замена аналитику. Это инструмент, который убирает самую бессмысленную часть работы: ручной поиск и сопоставление уже записанных решений. Вы пишете ADR и требования не для того, чтобы они лежали мёртвым грузом в Confluence. Вы пишете их, чтобы к ним возвращаться. RAG делает это возвращение мгновенным.

И да — если после запуска RAG окажется, что ваши ADR противоречат друг другу чаще, чем вы думали, не вините инструмент. Он просто показал то, что вы сами написали. Работает — не трогай? Уже не работает.