Полный разбор, где систему проектируют на skills/capabilities с on-demand тулами (урок 0021), а не на графе. Показываем, как экономим токены, и — главное — как эту архитектуру покрываем метриками и evals.
Что говорит кандидат:
«Задача звучит как skill-based архитектура: прогрессивное раскрытие знаний вместо одного гигантского промпта. Уточню: какие процедуры частые (горячие), а какие редкие (кандидаты на скиллы)? Сколько всего процедур и какой бюджет контекста? Есть ли уже текстовый бот с графом — или строим с нуля? И что критичнее: стоимость токенов или латентность? От этого зависит, какие тулы прятать за скиллами, а какие держать в базе».
Вопрос: «Почему скиллы, а не граф с router'ом?»
Ответ: «Граф хорош, когда ветки известны и их немного. Здесь процедур 40+ и они растут: новый продукт = новый FAQ. В графе каждый новый сценарий — правка кода и ретест. В skill-based: новый SKILL.md, и модель сама решает, когда его применить. Плюс контекст: граф всё равно тянет все тулы в промпт, а скиллы грузят знания по требованию. Но: граф оставляю для action-путей с деньгами — блокировка, перевод — там нужна строгая последовательность и предсказуемость».
Что говорит кандидат:
«К метрикам каре добавляются метрики именно скилл-слоя. Продуктовые: resolution, recontact 72ч, эскалация, PII-leak=0, $/диалог. Скилл-слой: skill selection accuracy (правильный скилл выбран?), trigger precision/recall (скиллы не триггерятся зря и не пропускаются), token economy (сколько токенов сэкономлено vs монолитный промпт), latency impact (round-trip загрузки не сломал p95). И главное — end-to-end: resolution при включённых скиллах vs выключенных».
Вопрос: «А как понять, что скилл сломался, а не тул?»
Ответ: «Разделяю вину по слоям: (1) skill selection — правильный скилл выбран? (метрика выбора); (2) skill content — инструкции в SKILL.md привели к верному действию? (eval на golden set сценариев скилла); (3) tool execution — тул выполнился и вернул верный результат? (tool-call F1, outcome). Если selection ок, а ответ плохой — проблема в контенте скилла. Если контент ок, а результат неверный — в туле. Каждый слой — свой eval, как в уроке 0002 разделяли retrieval и generation».
Что говорит кандидат:
«30k диалогов/мес, пик 3 RPS. Процедур: 40 FAQ + 10 action-процедур. Монолитный промпт: 40 × 1000 токенов = 40k токенов на каждый запрос → $0.12/диалог только вход. Со скиллами: 50 × ~100 описаний = 5k токенов всегда + средний скилл 1.5k при триггере → ~$0.02/диалог. Экономия ×6 на входных токенах. Минус: средний +0.5–1 round-trip на диалог (загрузка скилла) — меряю, не превышает ли p95».
Что рисует кандидат:
Вход → input guard (PII, injection)
→ базовый агент (loop):
горячие тулы: get_balance, cards_block_confirm (3–5, всегда в контексте)
каталог скиллов: "refunds", "faq_cards", "faq_credits", "disputes",
"docs_ocr", "block_card_procedure" (только описания)
→ модель выбирает скилл по description (LLM-рассуждение, не роутер)
→ загрузка SKILL.md → в ран попадают тулы скилла (refund_status, dispute_filing…)
→ action-пути (деньги): жёсткий граф-подграф + HITL, НЕ свободный выбор
→ output guard → лог: request_id, skill_loaded, tool_calls, tokens, cost
Каталог скиллов:
- FAQ-скиллы (знания): процедуры ответов по продуктам
- Action-скиллы (тул за скиллом): возврат, спор — схема тула грузится
только после триггера скилла (экономия, урок 0021)
- Compliance-скилл: что НЕльзя говорить (всегда в базе, не on-demand!)Ключевые решения:
Вопрос: «А если модель выберет НЕ тот скилл?»
Ответ: «Это и есть главный риск архитектуры — цена ошибки выше, чем у графа. Поэтому: (1) skill selection accuracy — отдельный eval на golden set запросов с ожидаемым скиллом; (2) description — тестируется как промпт, итерации на ошибках выбора; (3) fallback: если скилл не найден или уверенность низкая — эскалация на человека, а не догадка; (4) для action-скиллов с деньгами — обязательный HITL, так что даже при неверном выборе ущерб ограничен».
Вопрос: «Почему compliance в базе, а не скиллом?»
Ответ: «On-demand работает, когда скилл можно НЕ загрузить без последствий. Политику „не называть лимит чужой карты" нельзя отдать на выбор модели — если она не загрузит compliance-скилл, будет утечка. Безопасность и запреты — всегда в базовом промпте, они дешёвые (~500 токенов). On-demand — только для позитивных знаний, отсутствие которых не опасно».
Что говорит кандидат:
«Это ядро. Слои eval-ов:
| Слой | Метрика | Как |
|---|---|---|
| Выбор скилла | Skill selection accuracy | Golden set: запрос → ожидаемый скилл. Модель выбрала правильный? |
| Триггеры | Trigger precision / recall | Precision: загруженные скиллы были нужны? Recall: нужные скиллы загружены? (урок 0001: TPR/TNR) |
| Контент скилла | Task success по сценариям скилла | Golden set сценариев внутри скилла: «по правилам SKILL.md ответ верный?» |
| Тулы за скиллом | Tool-call F1, argument validity, outcome | Как в уроке 0004: правильный тул, верные аргументы, результат в БД |
| Экономия | Token economy | Средние входные токены/диалог: скиллы vs монолит. Цель — подтвердить расчёт из Estimate |
| Латентность | p95 + round-trip count | Загрузка скилла не сломала UX |
| End-to-end | Resolution, recontact, $/диалог | Главные продуктовые метрики, как в моке M1 |
«Плюс специфика: description скилла — это промпт, и его правки идут через тот же CI-гейт (урок 0020): изменил description → прогнал skill selection golden set → не упал → канарейка. И data flywheel: каждый неверный выбор скилла из прода → в датасет выбора → переписываем description или добавляем few-shot».
Вопрос: «Как собрать golden set для выбора скиллов?»
Ответ: «Сэмпл 200–500 реальных запросов из прода, размечаю ожидаемый скилл (benevolent dictator — я + домен-эксперт). Плюс синтетические: перефразы и крайние случаи. Критично включать запросы, где выбор НЕоднозначен — два скилла подходят — чтобы понять, где description путает модель».
Вопрос: «Что делать с запросом, который не покрыт ни одним скиллом?»
Ответ: «Это отдельная метрика — coverage. Если % таких запросов растёт — пора добавить скилл. Сам запрос: честное „не знаю, перевожу на оператора" (урок 0001: отказ лучше выдумки). И это сигнал для каталога: новые скиллы рождаются из непокрытых запросов — data flywheel».
Вопрос: «Чем skill selection eval отличается от router eval в графе?»
Ответ: «По сути тем же — accuracy и confusion matrix на ожидаемых скиллах. Разница в том, что в графе router — это код (детерминированный, можно юнит-тестить), а здесь выбор — это рассуждение модели: eval обязателен, потому что нет кода, который можно проверить. Плюс появляется метрика экономии токенов, которой в графе нет — граф не экономит контекст».
Что говорит кандидат:
«Неверный выбор скилла → fallback на человека, метрика selection accuracy, data flywheel. Скилл не загрузился (файл сломан) → деградация до базовых знаний + эскалация, алерт на skill load failure. Тула за скиллом нет (устарел каталог) → алерт, проверка синхронизации каталога и файлов. Вредоносный SKILL.md (инъекция в инструкции) → скиллы только из доверенных источников, аудит (урок 0021). Контекст скилла разросся → сплит на подфайлы (progressive disclosure L3). Модель злоупотребляет одним скиллом (overreliance) → мониторинг распределения триггеров».
Что говорит кандидат:
«v0: базовые тулы + 5–10 FAQ-скиллов + compliance в базе + action-пути графом с HITL. v1: action-скиллы с тулами за ними (когда накопим статистику использования и подтвердим экономию), self-extension — модель создаёт новые скиллы из повторяющихся паттернов (фича из Pydantic AI Harness), голос поверх ядра. Сознательно не беру: скиллы для денежных action без HITL, compliance on-demand, свободный выбор для блокировки карты».
Вопрос: «С чего начнёшь в понедельник?»
Ответ: «Сэмпл 200–500 запросов, разметка ожидаемых скиллов, golden set. Потом три самых частых FAQ — в скиллы, compliance — в базу, прогон: skill selection accuracy + resolution vs текущий бот. Замер токенов до/после — подтвердить экономию. Канарейка 5–10%».
| Критерий | Ты показал |
|---|---|
| Понимание тренда | Skill-based, progressive disclosure, on-demand тулы (урок 0021) |
| Гибрид, не фанатизм | Граф для денег, скиллы для знаний, compliance в базе |
| Метрики под архитектуру | Skill selection, trigger P/R, token economy, latency impact |
| Eval-слои | Выбор → контент → тул → end-to-end, разделение вины |
| Безопасность | Compliance не on-demand, HITL на action, аудит скиллов |
| Экономика с цифрами | ×6 на входных токенах, порог окупаемости round-trip |