Системный анализ · 3 минуты

Project-local RAG: что это и чем отличается от обычного RAG

Project-local RAG - это подход к Retrieval-Augmented Generation, при котором AI ищет контекст только в источниках конкретного проекта: source map, Confluence, Git, PDF, переписках, протоколах встреч и артефактах команды.

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

Для системного аналитика разница принципиальная. Вопрос «какое поле обязательно в запросе» нельзя отвечать по общим знаниям модели или похожим API из интернета. Ответ должен опираться на конкретный PDF поставщика, актуальную страницу вики, OpenAPI-файл или письмо поддержки. Если источника нет, инструмент должен показать пробел, а не придумать правдоподобное требование.

Где Project-local RAG стоит в методе

В цепочке AnalystCraft он идёт после source map и до System Context Pack:

source map -> Project-local RAG -> System Context Pack -> Review Findings -> Task Pack

Сначала аналитик собирает карту источников: что есть, кто владелец, какая дата, насколько источник актуален. Затем Project-local RAG использует только эти источники для поиска фрагментов. Из найденного контекста собирается System Context Pack: проверяемая картина проекта с цитатами, противоречиями и открытыми вопросами.

Чем отличается от общего RAG

Обычный RAG отвечает на вопрос «что известно по теме». Project-local RAG отвечает на вопрос «что известно в этом проекте».

Например, общая база может знать, что OAuth token обычно живёт час или сутки. В проекте Acme Pay актуальный срок может быть 4 часа, потому что support прислал уточнение в письме. Для постановки важна не средняя практика индустрии, а конкретный источник в конкретной задаче.

Поэтому Project-local RAG не делает инструмент умнее сам по себе. Он делает ответ проверяемым. У каждого утверждения появляется адрес: источник, раздел, дата, статус. Если два источника спорят, результатом должен быть Review Finding, а не сглаженная версия.

Ограничения

Project-local RAG не решает проблему качества источников. Если в source map попали устаревшие документы, поиск всё равно найдёт устаревшие фрагменты. Поэтому перед RAG нужна инвентаризация источников, а после RAG нужна проверка мастера.

В Подмастерье аналитика этот подход нужен для рабочей границы: модель помогает собрать контекст проекта, но не заменяет решение человека. Она показывает найденные фрагменты, цитаты и конфликты. Мастер решает, что считать фактом, что вынести в вопрос и что попадёт в Task Pack.

Связанные термины

Source map

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

System Context Pack

Фиксирует роли, термины, ограничения, открытые вопросы и границы задачи до постановки.

Review Findings

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

Task Pack

Собирает результат анализа в форму, которую можно обсуждать с PM, разработкой и владельцами процесса.