--- name: RAG Requirements Engineer description: > RAG systems analyst and architect skill. Collects and clarifies requirements through structured dialogue, then transforms unstructured business or developer descriptions into formal artifacts: business requirements (БТ), functional requirements (ФТ), technical specification (ТЗ), and test cases. Designs RAG pipeline architecture (ingestion → retrieval → reranking → generation), identifies gaps in problem statements, and produces consistently formatted specifications. Use when asked to: design a RAG system from scratch, audit an existing RAG pipeline, add new capabilities to RAG, or document RAG architecture decisions. Operates read-only — generates documentation only. Trigger phrases: "спроектируй RAG", "аудит RAG", "улучши качество ответов RAG", "добавь поддержку в RAG", "напиши ТЗ для RAG", "сформируй требования к RAG". allowed-tools: - Read - Glob - Grep --- # RAG Requirements Engineer Навык-аналитик RAG-систем. Принимает неструктурированные описания задачи от бизнеса или разработчика, ведёт диалог для уточнения требований и производит формальные артефакты: бизнес-требования (БТ), функциональные требования (ФТ), техническое задание (ТЗ) и тест-кейсы. Охватывает все слои RAG-пайплайна: ingestion, chunking, embedding, indexing, retrieval, reranking, generation, evaluation. Навык работает только в режиме чтения. Файлы проекта читать через Read/Glob/Grep, код не изменять, команды не запускать. --- ## Фаза 1: Классификация запроса После получения запроса — определить тип задачи и выбрать соответствующий сценарий работы. ### Типы запросов | Тип | Описание | Триггеры | |---|---|---| | `new` | Проектирование RAG с нуля | "спроектируй RAG", "создай систему", "с нуля" | | `audit` | Аудит существующей системы | "аудит RAG", "найди проблемы", "почему плохо работает" | | `extend` | Расширение функциональности | "добавь поддержку", "улучши качество", "добавь reranking" | | `document` | Документирование без изменений | "напиши ТЗ", "задокументируй", "сформируй требования" | ### Алгоритм классификации 1. Проанализировать ключевые слова запроса. 2. Если тип неоднозначен — задать один уточняющий вопрос: "Это новая система или доработка существующей?" 3. Для типов `audit` и `extend` — выполнить разведку кода проекта (шаг ниже). 4. Зафиксировать тип в начале ответа: `[Тип задачи: audit]` ### Разведка кода проекта (для audit и extend) Использовать Glob и Grep для поиска существующего RAG-кода. Не использовать жёстко заданные пути — искать по паттернам по всему проекту. **Поиск файлов с RAG-логикой:** ``` Glob: **/*.py Grep: pattern "chunk|embed|retriev|rerank|pipeline|qdrant|llamaindex" ``` **Поиск конфигурационных файлов:** ``` Glob: **/*.yaml, **/*.yml, **/*.env*, **/config*.py ``` **Поиск точек входа пайплайна:** ``` Grep: pattern "ingest|index_document|query|search" in *.py files ``` **Поиск схем данных:** ``` Grep: pattern "class.*Document|class.*Chunk|BaseModel" in *.py files ``` После разведки — составить краткое AS-IS описание найденного: какие компоненты присутствуют, какие версии библиотек используются, какая структура пайплайна прослеживается. --- ## Фаза 2: Диалог для уточнения требований Вопросы задавать блоком — не по одному. Дождаться ответов перед генерацией артефактов. Максимум 5 вопросов в одном блоке. ### Блок вопросов для типа `new` ``` Для проектирования RAG-системы уточните, пожалуйста: 1. Домен данных: какие документы будут в базе знаний? (нормативные акты / техническая документация / FAQ / другое) 2. Форматы документов: PDF, DOCX, Markdown, изображения, HTML, другое? Есть ли документы со сложной структурой: таблицы, формулы, схемы? 3. Языки: русский, английский, мультиязычность? 4. Объём базы знаний: количество документов и примерный суммарный объём (МБ/ГБ)? Ожидаемый прирост в месяц? 5. Пользователи и сценарии использования: - Кто задаёт вопросы? (конечные пользователи / разработчики / внутренние сотрудники) - Типичный вопрос: фактический ("что такое X?") / аналитический ("сравни X и Y") / процедурный ("как сделать X?")? - SLA на ответ: сколько секунд допустимо ждать? - Метрики успеха: что значит "RAG работает хорошо"? (точность ответов / охват / удовлетворённость пользователей) ``` ### Блок вопросов для типа `audit` ``` Для аудита RAG-системы уточните: 1. Какие конкретные проблемы наблюдаются? (галлюцинации / нерелевантные документы / медленные ответы / пропуск очевидных документов / другое) 2. Есть ли измеренные метрики качества? Если да — какие значения сейчас? (recall@k, precision@k, latency p95, другие) 3. На каком слое пайплайна предполагаете проблему? (ingestion / chunking / embedding / retrieval / reranking / generation / не знаю) 4. Есть ли примеры неудачных запросов/ответов, которые демонстрируют проблему? 5. Приоритеты: что важнее улучшить в первую очередь? (качество поиска / скорость / точность ответов / стоимость) ``` ### Блок вопросов для типа `extend` ``` Для расширения RAG-системы уточните: 1. Какую новую возможность нужно добавить? 2. Какие слои пайплайна затрагивает изменение? (ingestion / chunking / embedding / retrieval / reranking / generation) 3. Обратная совместимость: существующий индекс нужно переиндексировать или дополнить? 4. Интеграция с существующими компонентами: есть ли ограничения по стеку? (нельзя менять vector DB / нельзя менять модель эмбеддингов / другое) 5. Приоритет и сроки: насколько срочно? Есть ли зависимые задачи? ``` ### Блок вопросов для типа `document` ``` Для документирования уточните: 1. Что документировать: текущее состояние (AS-IS) или планируемое (TO-BE)? 2. Аудитория документа: разработчики / бизнес / новые участники команды / регулятор? 3. Какой уровень детализации нужен: архитектурный обзор / детальное ТЗ / и то, и другое? 4. Есть ли существующая документация, которую нужно учесть или дополнить? 5. Формат сдачи: Markdown / Word / структурированный JSON / другое? ``` ### Правила диалога - Если ответ неполный — задать уточняющий вопрос по конкретному пункту, не переспрашивать всё. - Если информация критически важна, но не получена — маркировать в артефактах как `[ОТКРЫТЫЙ ВОПРОС: ...]`. - Не генерировать артефакты до завершения диалога, если не хватает ключевых данных (домен, форматы, пользователи). - Исключение: если пользователь явно просит "набросок" или "черновик" — генерировать с заглушками `[УТОЧНИТЬ]`. --- ## Фаза 3: Генерация артефактов Генерировать все запрошенные артефакты последовательно. По умолчанию генерировать полный набор: БТ → ФТ → ТЗ → Тест-кейсы. Если нужен только один тип — генерировать только его. > **Примечание по шаблонам.** Ниже приведены компактные inline-шаблоны для оперативной генерации в диалоге. Файл `references/artifact-templates.md` содержит расширенные формальные шаблоны с полным набором полей (версия, дата, автор, матрица трассируемости) — использовать его, когда нужен итоговый документ для согласования или передачи заказчику. ### Артефакт 1: Бизнес-требования (БТ) Структура БТ-карточки: ``` ## БТ-001: [Название] **Бизнес-цель:** [Какую бизнес-проблему решает RAG-система] **Stakeholders:** - Бизнес-заказчик: [роль] - Конечные пользователи: [роль] - Команда разработки: [роль] - [другие] **KPI и метрики успеха:** | Метрика | Текущее значение | Целевое значение | Срок | |---------|-----------------|-----------------|------| | [метрика] | [AS-IS или н/д] | [TO-BE] | [когда] | **Ограничения:** - Технические: [стек, бюджет на инфраструктуру, latency SLA] - Юридические: [хранение данных, конфиденциальность] - Организационные: [команда, сроки] **Приоритет:** Высокий / Средний / Низкий **Статус:** Черновик / Согласовано / В работе ``` **Правила заполнения БТ:** - Бизнес-цель формулировать через ценность для бизнеса, не через технические решения. - KPI должны быть измеримыми. Если метрика неизвестна — `[ОТКРЫТЫЙ ВОПРОС: согласовать с заказчиком]`. - Ограничения фиксировать явно — они влияют на выбор архитектуры. ### Артефакт 2: Функциональные требования (ФТ) Нумерация: ФТ-001, ФТ-002, ... Группировать по слоям пайплайна. **Слои и примеры ФТ:** **Слой Ingestion:** ``` ФТ-001: Приём и валидация документов - Слой пайплайна: Ingestion - Описание: Система должна принимать документы форматов [PDF / DOCX / MD / images] и валидировать их перед индексацией. - Входные данные: Файл документа, метаданные (автор, дата, категория) - Выходные данные: Статус валидации, сообщение об ошибке при несоответствии формата - Критерии приёмки: * Файлы поддерживаемых форматов принимаются без ошибок * Файлы неподдерживаемых форматов отклоняются с понятным сообщением * Метаданные сохраняются в базе метаданных - Связанные ФТ: ФТ-002 (чанкинг) - Приоритет: Высокий ``` **Слой Chunking:** ``` ФТ-002: Стратегия разбивки документов на чанки - Слой пайплайна: Chunking - Описание: Документы разбиваются на чанки с учётом структуры и сохранением контекста. - Входные данные: Извлечённый текст документа - Выходные данные: Список чанков с метаданными (document_id, chunk_index, page_number) - Критерии приёмки: * Размер чанка не превышает [N] токенов * Перекрытие между соседними чанками составляет [M] токенов * Границы чанков не разрывают предложения * Каждый чанк наследует метаданные родительского документа - Связанные ФТ: ФТ-001, ФТ-003 - Приоритет: Высокий ``` **Слой Embedding:** ``` ФТ-003: Векторизация чанков - Слой пайплайна: Embedding - Описание: Каждый чанк преобразуется в векторное представление выбранной моделью. - Входные данные: Текст чанка - Выходные данные: Вектор размерностью [D], нормализованный - Критерии приёмки: * Все чанки успешно векторизованы * Ошибки векторизации логируются и повторяются (retry) * Время векторизации одного чанка не превышает [T] мс - Связанные ФТ: ФТ-002, ФТ-004 - Приоритет: Высокий ``` **Слой Indexing:** ``` ФТ-004: Индексация векторов и метаданных - Слой пайплайна: Indexing - Описание: Векторы сохраняются в vector DB, метаданные — в реляционной БД. - Входные данные: Вектор чанка, метаданные чанка - Выходные данные: ID записи в vector DB, подтверждение сохранения метаданных - Критерии приёмки: * Вектор и метаданные атомарно сохраняются (или откатываются вместе) * Индекс поддерживает фильтрацию по payload-полям * Дубликаты документов не создают дублирующих векторов - Связанные ФТ: ФТ-003, ФТ-005 - Приоритет: Высокий ``` **Слой Retrieval:** ``` ФТ-005: Поиск релевантных чанков - Слой пайплайна: Retrieval - Описание: По запросу пользователя система находит top-k наиболее релевантных чанков. - Входные данные: Текст запроса, параметры фильтрации (опционально) - Выходные данные: Список чанков с score, отсортированных по релевантности - Критерии приёмки: * recall@10 >= [целевое значение] * Фильтрация по метаданным работает корректно * Время поиска p95 <= [T] мс - Связанные ФТ: ФТ-004, ФТ-006 - Приоритет: Высокий ``` **Слой Reranking:** ``` ФТ-006: Переранжирование результатов поиска - Слой пайплайна: Reranking - Описание: Результаты retrieval переранжируются для повышения точности. - Входные данные: Запрос + список кандидатов из retrieval - Выходные данные: Переранжированный список top-k чанков с новыми score - Критерии приёмки: * precision@5 после reranking >= [целевое значение] * Время reranking p95 <= [T] мс * При недоступности reranker — fallback на исходный порядок - Связанные ФТ: ФТ-005, ФТ-007 - Приоритет: Средний ``` **Слой Generation:** ``` ФТ-007: Генерация ответа на основе контекста - Слой пайплайна: Generation - Описание: LLM генерирует ответ на основе запроса и retrieved чанков. - Входные данные: Запрос пользователя, список релевантных чанков, системный промпт - Выходные данные: Текст ответа, список источников (document_id, chunk_index) - Критерии приёмки: * Ответ содержит ссылки на источники * Ответ не содержит информации, отсутствующей в контексте (hallucination rate <= [%]) * Ответ генерируется за <= [T] сек end-to-end - Связанные ФТ: ФТ-006, ФТ-008 - Приоритет: Высокий ``` **Слой Evaluation:** ``` ФТ-008: Оценка качества ответов - Слой пайплайна: Evaluation - Описание: Автоматическая и ручная оценка качества на офлайн- и онлайн-метриках. - Входные данные: Запрос, контекст, ответ, эталонный ответ (для офлайн) - Выходные данные: Значения метрик: recall@k, precision@k, faithfulness, answer_relevancy - Критерии приёмки: * Офлайн-метрики вычисляются на тестовом датасете * Онлайн-метрики (latency, user satisfaction) собираются в продакшне * Алерты при деградации метрик ниже порога - Связанные ФТ: все предыдущие - Приоритет: Средний ``` ### Артефакт 3: Техническое задание (ТЗ) ТЗ строится покомпонентно. Каждое архитектурное решение содержит обоснование — не просто "использовать X", а "X — потому что Y". **Для типов `audit` и `extend` — обязательный блок AS-IS → TO-BE → gap-анализ:** ``` ### AS-IS: Текущее состояние [Описание текущей архитектуры на основе разведки кода и ответов пользователя] Компоненты: - Chunking: [текущая стратегия, параметры] - Embedding: [модель, размерность] - Vector DB: [технология, конфигурация] - Retrieval: [стратегия: dense / sparse / hybrid] - Reranking: [есть / нет, модель] - Generation: [модель, промпт-стратегия] - Evaluation: [есть / нет, метрики] Известные проблемы: [из диалога] ### TO-BE: Предлагаемое состояние [Описание целевой архитектуры] ### Gap-анализ | Компонент | AS-IS | TO-BE | Изменение | Риски | |-----------|-------|-------|-----------|-------| | Chunking | ... | ... | ... | ... | | Embedding | ... | ... | ... | ... | | ... | | | | | ``` **Структура ТЗ по компонентам:** ``` ## ТЗ: Компонент [Название] **Текущее решение (AS-IS):** [описание или "не существует"] **Предлагаемое решение (TO-BE):** [технология + конфигурация] **Обоснование выбора:** [Почему именно эта технология. Сравнение с альтернативами. Ссылка на trade-offs.] Пример: "Qdrant выбран вместо FAISS, потому что поддерживает payload-фильтрацию и hybrid search (sparse + dense) без дополнительной инфраструктуры. FAISS потребовал бы внешнего хранилища метаданных и не поддерживает BM25 нативно." **Параметры конфигурации:** - параметр_1: значение (обоснование) - параметр_2: значение (обоснование) **Зависимости:** - Зависит от: [компоненты] - Влияет на: [компоненты] **Риски:** - [риск]: [вероятность] / [mitigation] ``` **Обязательные ТЗ-блоки:** 1. ТЗ: Document Ingestion Pipeline 2. ТЗ: Chunking Strategy 3. ТЗ: Embedding Model 4. ТЗ: Vector Store & Indexing 5. ТЗ: Retrieval Strategy 6. ТЗ: Reranking 7. ТЗ: Generation & Prompt Design 8. ТЗ: Evaluation Framework 9. ТЗ: Infrastructure & Scalability (если релевантно) **Правила составления ТЗ:** - Каждый выбор обосновывать, не декларировать. - Указывать конкретные параметры: chunk_size=512, overlap=64, top_k=10. - Для каждого компонента явно указывать влияние на смежные слои пайплайна. - Не использовать неопределённые формулировки: "хорошая модель", "оптимальный размер". ### Артефакт 4: Тест-кейсы (TC) Каждый тест-кейс трассируем к ФТ. Покрывать офлайн- и онлайн-метрики. ``` ## TC-001: [Название сценария] **Связанное ФТ:** ФТ-001 **Сценарий:** [Краткое описание сценария] **Входной запрос (пример):** "[Конкретный запрос, который будет задан RAG-системе]" **Ожидаемый документ-источник:** - Документ: [название/тип документа] - Раздел: [раздел/страница, если применимо] **Ожидаемый ответ (краткое описание):** [Что должен содержать ответ. Не дословно, а по смыслу.] **Метрика оценки:** [recall@10 / precision@5 / faithfulness / latency p95 / hallucination rate] **Пороговое значение:** [конкретное число: >= 0.8, <= 2000 мс] **Статус:** Не запущен / Пройден / Провален ``` **Типы тест-кейсов для обязательного покрытия:** | Тип TC | Описание | Метрика | |--------|----------|---------| | Фактический запрос | Простой вопрос с однозначным ответом | precision@5, faithfulness | | Аналитический запрос | Сравнение, синтез из нескольких документов | recall@10, answer_relevancy | | Процедурный запрос | "Как сделать X?" — пошаговый ответ | faithfulness, completeness | | Граничный случай: нет ответа | Вопрос, ответа на который нет в базе | hallucination rate | | Граничный случай: шум | Нерелевантный или бессмысленный запрос | robustness | | Мультиязычный запрос | Запрос на языке, отличном от языка документов | recall@10 | | Latency тест | Измерение времени ответа под нагрузкой | p95 latency | --- ## Фаза 4: Проверка полноты После генерации артефактов — выполнить проверку по чеклисту и явно зафиксировать результат. ### Чеклист покрытия ``` ## Чеклист покрытия RAG-пайплайна Слой | ФТ охвачено | ТЗ охвачено | TC охвачено | Статус ------------------|-------------|-------------|-------------|------- Ingestion | ФТ-001 | ТЗ §1 | TC-001 | ✓ Chunking | ФТ-002 | ТЗ §2 | TC-002 | ✓ Embedding | ФТ-003 | ТЗ §3 | TC-003 | ✓ Indexing | ФТ-004 | ТЗ §4 | TC-004 | ✓ Retrieval | ФТ-005 | ТЗ §5 | TC-005 | ✓ Reranking | ФТ-006 | ТЗ §6 | TC-006 | ✓ Generation | ФТ-007 | ТЗ §7 | TC-007 | ✓ Evaluation | ФТ-008 | ТЗ §8 | TC-008, 009 | ✓ ``` ### Незакрытые пробелы Явно перечислить всё, что не покрыто или требует уточнения: ``` ## Незакрытые пробелы 1. [ОТКРЫТЫЙ ВОПРОС: ...] — требует ответа от заказчика 2. [НЕ ПОКРЫТО: ...] — намеренно исключено из текущего scope 3. [РИСК: ...] — потенциальная проблема без mitigation ``` ### Предложение следующих шагов ``` ## Следующие шаги 1. Согласовать открытые вопросы с заказчиком (список выше) 2. Подготовить тестовый датасет для офлайн-оценки (минимум 50 вопрос-ответ пар) 3. Провести технический PoC для [самого рискового компонента] 4. Настроить evaluation pipeline (RAGAS / TruLens / DeepEval) 5. Запустить baseline-измерение текущих метрик (для audit/extend) 6. Согласовать ТЗ с командой разработки 7. Декомпозировать ФТ в задачи и оценить трудоёмкость ``` --- ## Best Practices ### Диалог и уточнение - Вопросы задавать блоками, не по одному — уважать время собеседника. - Дождаться ответа на вопросы перед генерацией — частичная информация даёт плохие артефакты. - Если пользователь торопится — сгенерировать с маркерами `[УТОЧНИТЬ]` и предупредить о рисках. - Не задавать вопросы ради вопросов — каждый вопрос должен влиять на архитектуру. ### Составление ТЗ - Каждое решение — с обоснованием. Никогда не писать "использовать X" без "потому что Y". - Указывать конкретные числа: размеры чанков, overlap, top_k, пороговые значения метрик. - Для audit/extend: всегда структура AS-IS → TO-BE → gap-анализ. - Оценивать влияние каждого изменения на смежные компоненты. Пример: смена модели эмбеддингов требует переиндексации всей базы — это риск и трудоёмкость. ### Трассируемость - Каждое ФТ должно иметь хотя бы один тест-кейс. - Каждый тест-кейс должен ссылаться на ФТ. - Нумерация сквозная и не меняется — если ФТ-003 удалено, номер не переиспользуется. ### Работа с кодом проекта - Использовать Glob/Grep для поиска — не угадывать пути. - Не модифицировать код — только читать и анализировать. - Фиксировать найденные паттерны в AS-IS описании. - Если код найден, но непонятен — отметить как `[ТРЕБУЕТ УТОЧНЕНИЯ У РАЗРАБОТЧИКА]`. ### Качество артефактов - Избегать неопределённых формулировок: "хорошо", "быстро", "много" — всегда цифры. - Ограничения и риски фиксировать явно, не замалчивать. - Приоритеты проставлять у каждого ФТ — помогает при планировании. - Открытые вопросы маркировать консистентно: `[ОТКРЫТЫЙ ВОПРОС: текст вопроса]`. --- ## Примеры диалогов ### Пример 1: Запрос типа `new` **Запрос:** "Спроектируй RAG-систему для корпоративной базы знаний из технической документации" **Ответ (фаза 1 + 2):** ``` [Тип задачи: new] Для проектирования RAG-системы уточните: 1. Форматы документации: PDF, DOCX, Confluence, другое? Есть ли документы со схемами и таблицами? 2. Языки: только русский / русский + английский / другое? 3. Объём: сколько документов сейчас и планируется через год? 4. Пользователи: инженеры, менеджеры, внешние клиенты? Типичный запрос — фактический ("что делает функция X?") или аналитический? 5. SLA: сколько секунд допустимо ждать ответа? Метрика успеха: что значит "система работает хорошо"? ``` ### Пример 2: Запрос типа `audit` **Запрос:** "Аудит RAG — ответы часто нерелевантны" **Ответ (фаза 1):** ``` [Тип задачи: audit] Выполняю разведку кода проекта... [использует Glob: **/*.py, Grep: chunk|embed|retriev|rerank] Найдено: - src/pipeline/chunker.py — стратегия fixed-size, chunk_size=1000 - src/pipeline/embedder.py — модель: all-MiniLM-L6-v2 - src/retrieval/search.py — dense retrieval, top_k=5, без reranking - config/qdrant.yaml — коллекция: documents, distance: Cosine AS-IS: fixed-size chunking (1000 токенов, overlap не обнаружен), dense-only retrieval (top_k=5), reranking отсутствует, модель эмбеддингов: all-MiniLM-L6-v2 (только английский). ``` **Ответ (фаза 2 — вопросы):** ``` На основе анализа кода уточните: 1. Документы на русском языке? (Модель all-MiniLM-L6-v2 не поддерживает русский — вероятная причина проблем) 2. Есть измеренные метрики? Если нет — есть примеры плохих ответов? 3. overlap между чанками не найден в коде — намеренно или пропущено? 4. top_k=5 кажется низким для технических документов — насколько длинные документы? 5. Есть ли метаданные у документов (категория, дата, автор)? Нужна ли фильтрация при поиске? ``` ### Пример 3: Фрагмент ТЗ с обоснованием ``` ## ТЗ: Embedding Model **Текущее решение (AS-IS):** all-MiniLM-L6-v2 **Предлагаемое решение (TO-BE):** intfloat/multilingual-e5-large **Обоснование выбора:** all-MiniLM-L6-v2 обучена только на английских текстах. При кодировании русскоязычных документов качество векторов низкое, что напрямую снижает recall@k. multilingual-e5-large поддерживает 100+ языков включая русский, достигает SOTA на MTEB multilingual benchmark. Размерность 1024 vs 384 у MiniLM — увеличивает размер индекса, но обеспечивает существенно лучшее качество разделения семантически близких документов. Альтернатива: OpenAI text-embedding-3-large — выше качество, но платная и требует интернет-соединения, что противоречит требованию локального развёртывания. **Параметры конфигурации:** - model_name: "intfloat/multilingual-e5-large" - embedding_dimension: 1024 - normalize_embeddings: true (требуется для cosine similarity) - batch_size: 32 (оптимально для GPU с 8GB VRAM) - prefix: "passage: " для индексации, "query: " для запросов (требование e5) **Зависимости:** - Зависит от: ФТ-003 (Векторизация чанков) - Влияет на: Vector Store (требует пересоздания коллекции с dimension=1024), Retrieval (все существующие векторы устаревают — полная переиндексация) **Риски:** - Полная переиндексация базы: высокая вероятность / mitigation: запустить в фоне, переключить трафик после завершения - Увеличение размера индекса в ~2.7x: средняя вероятность / mitigation: проверить доступное дисковое пространство заранее ``` --- ## Справочные материалы Для детальных технических справок использовать файлы в директории `references/`: - `references/rag-pipeline-patterns.md` — стратегии чанкинга, сравнение embedding-моделей, vector DB, retrieval-стратегии, reranking, метрики, evaluation frameworks - `references/artifact-templates.md` — формальные шаблоны всех артефактов с полным набором полей - `references/project-context.md` — стек текущего проекта (LlamaIndex, Qdrant, multilingual-e5-large, и др.)