Роутер работает нормально в process v2

2026-04-07 14:09:51 +03:00
parent 5d77ab1a88
commit 6b74d410cd
1748 changed files with 216679 additions and 14208 deletions
@@ -0,0 +1,105 @@
+`pipeline_setup_v3` это YAML-driven test harness для проверки agent pipeline на уровне сценариев, а не unit-тестов.
+
+Как он работает:
+- Берёт один YAML-файл или директорию с YAML-кейсами.
+- Каждый кейс описывает:
+  - `id`
+  - `query`
+  - `runner`
+  - `mode`
+  - `input`
+  - `expected`
+- Если в `input` нет готового `rag_session_id`, harness сам получает его:
+  - либо берёт из `input.rag_session_id`
+  - либо индексирует `input.repo_path` в RAG и кеширует полученную сессию для одинакового `(repo_path, project_id)`
+
+Какие режимы кейсов есть:
+- `router_only`
+  Проверяется только роутинг, без retrieval и без LLM.
+- `router_rag`
+  Проверяется роутинг плюс retrieval, но без полной генерации ответа.
+- `full_chain`
+  Проверяется полный pipeline: router → retrieval → downstream pipeline/LLM → final answer.
+
+Как устроен execution flow:
+1. Loader читает YAML и превращает каждый кейс в `V3Case`.
+2. Runner для каждого кейса резолвит `rag_session_id`.
+3. `AgentRuntimeAdapter` исполняет кейс в зависимости от `mode`.
+4. Возвращаются два объекта:
+   - `actual`
+   - `details`
+5. Validator сравнивает `actual/details` с `expected`.
+6. Writer сохраняет:
+   - JSON с машинными результатами
+   - Markdown с человекочитаемой диагностикой
+   - итоговый `summary.md` по всему прогону
+
+Что обычно лежит в `actual`:
+- `intent`
+- `sub_intent`
+- `graph_id`
+- `conversation_mode`
+- `rag_count`
+- `answer_mode`
+- `llm_answer`
+- `path_scope`
+- `doc_scope`
+- `entity_candidates`
+- `symbol_candidates`
+- `layers`
+- `filters`
+
+Что лежит в `details`:
+- `router_result`
+- `retrieval_request`
+- `retrieval_result`
+- `rag_rows`
+- `diagnostics`
+- `llm_request`
+- `pipeline_steps`
+- иногда `validation`, `token_usage`, `runtime_trace`
+
+Что умеют expectations:
+- `expected.router`
+  Проверяет `intent`, `sub_intent`, `graph_id`, `conversation_mode`
+- `expected.retrieval`
+  Проверяет:
+  - пустой/непустой retrieval
+  - минимум строк
+  - наличие нужных слоёв
+  - path/doc scope
+  - symbol/entity candidates
+  - фильтры
+- `expected.llm`
+  Проверяет:
+  - есть ли ответ
+  - содержит ли ответ обязательные фразы
+  - не содержит ли запрещённые фразы
+  - `answer_mode`
+- `expected.pipeline`
+  Проверяет в основном итоговый `answer_mode`
+
+Что важно при формулировке нового test case для ChatGPT:
+- кейс должен описывать не “как реализовать код”, а “какой пользовательский сценарий проверяем”
+- у кейса должны быть:
+  - понятный `query`
+  - корректный `mode`
+  - вход: `rag_session_id` или `repo_path`
+  - минимально достаточные `expected`
+- не надо переописывать весь output, лучше проверять только ключевые инварианты
+
+Хороший шаблон задания для ChatGPT:
+1. Укажи, для какого suite нужен кейс.
+2. Укажи `mode`: `router_only`, `router_rag` или `full_chain`.
+3. Дай пользовательский `query`.
+4. Опиши, что именно должно проверяться:
+   - роутинг
+   - retrieval layers/scope
+   - answer mode
+   - ключевые фразы в ответе
+5. Попроси вернуть YAML-фрагмент в формате `pipeline_setup_v3`.
+
+Пример формулировки для ChatGPT:
+“Сформируй YAML test case для `pipeline_setup_v3` в режиме `full_chain`. Нужно проверить, что запрос `Объясни по документации как работает /health` маршрутизируется в docs-intent, retrieval использует docs layers, retrieval непустой, а ответ содержит `/health` и не содержит фраз про отсутствие данных.”
+
+Если хочешь, я могу сразу подготовить тебе готовый prompt для ChatGPT, который будет генерировать новые кейсы в нужном формате.