Carry-over от Ильдара: «может это не цель, а промежуточный результат».
Контекст
В production loinc-harmonization-pipeline есть Agent Fallback — agentic loop, который запускается когда основной 3-step pipeline вернул no_match. 4 tools, max 10 итераций, hallucination check.
Когда параметр приходит впервые от новой лабы (cold start, незнакомый формат) — pipeline может не справиться. Agent Fallback — последняя попытка перед manual review.
Вопрос
В зрелой системе с Dictionary-First подходом (dictionary-first-paradigm) — реально ли нужен Agent Fallback?
Pre-Dictionary мир: pipeline вызывается на каждый незнакомый параметр; Agent Fallback покрывает edge cases.
Post-Dictionary мир (target): Dictionary lookup закрывает большинство — параметры уже видели. Pipeline вызывается только при новом параметре (онбординг лабы). Здесь:
- A. Можем proactively создать Dictionary при онбординге новой лабы — попросить их каталог параметров offline, прогнать через pipeline + manual review, fill the Dictionary заранее. Тогда production pipeline видит только параметры из known catalog → Agent Fallback не нужен (или почти).
- B. Online discovery — лаба онбордится “сразу”, Dictionary наполняется на ходу. Agent Fallback нужен — он покрывает первые встречи с новыми форматами до того как Dictionary “догонит”.
- C. Hybrid — Agent Fallback существует но используется редко (~few % requests), его complexity не оправдана если можно offline pre-fill.
Что нужно для разрешения
- Решение по dictionary-creation strategy — proactive (option A) vs reactive (option B)
- Реальная статистика какой % requests падает в Agent Fallback в production сейчас
- Carry-over: Ильдар несколько раз в design-сессиях говорил что Agent Fallback не должен быть основным путём — это уже намёк на direction A
Связано
- loinc-harmonization-pipeline — pipeline где живёт Agent Fallback
- dictionary-first-paradigm — основная парадигма
- dictionary-creation — proactive создание справочника
- loinc-unification-direction — общее направление