agent/pipeline_setup_v3.md

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