105 lines
4.7 KiB
Markdown
105 lines
4.7 KiB
Markdown
`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, который будет генерировать новые кейсы в нужном формате. |