Edge Pipeline: 7 скиллов лучше одного монолита — Блог
$ cat edge-pipeline-7-skilov-luchshe-odnogo-monolita.md

Edge Pipeline: 7 скиллов лучше одного монолита

🤖 AI и машинное обучение
#Skills #Edge Research #Pipeline #Trading #Strategy Design #YAML Schema

Edge Pipeline: 7 скиллов лучше одного монолита

В коллекции лежат 7 скиллов с префиксом edge-* — все про превращение сырых рыночных наблюдений в валидированные стратегии для backtest’а. Это эталонный пример правильно спроектированного pipeline’а с явными handoff-контрактами. Объединять их — значит разрушить то, что делает их мощными.

Контекст: зачем вообще 7 скиллов на одну задачу?

Задача «превратить наблюдение о рынке в стратегию для бэктеста» звучит атомарно. Можно ли сделать это одним монолитным скиллом? Технически — да. Практически — нет, потому что в процессе есть 5 чётких стадий с разными входами, выходами и guarantees, и каждая из них полезна сама по себе.

Разработчики этой коллекции сделали образцовый pipeline:

OHLCV / market data
  │
  ▼
[1] edge-hint-extractor ─────► hints.yaml
  │   (raw observations → abstract hints)
  │
  ▼
[auto_detect in edge-candidate-agent] ──► tickets/{exportable|research_only}/*.yaml
  │
  ▼
[2] edge-concept-synthesizer ─► edge_concepts.yaml
  │   (tickets + hints → mechanism-level concepts)
  │
  ▼
[3] edge-strategy-designer ────► strategy_drafts/*.yaml
  │   (concepts → concrete variants with risk profile)
  │
  ▼
[4] edge-strategy-reviewer ────► review.yaml
  │   (8 weighted criteria C1-C8, PASS/REVISE/REJECT)
  │
  ▼
[5] edge-candidate-agent ─────► strategy.yaml + metadata.json
       (export + validate for trade-strategy-pipeline Phase I)

       ↑ обёрнуто в edge-pipeline-orchestrator (sequential + feedback loop)

↑ и параллельно:
[6] edge-signal-aggregator ────► ranked conviction dashboard
       (cross-skill aggregation, не входит в core pipeline)

Состав 7 скиллов

edge-hint-extractor (Stage 1, 82 строки, 76K)

Конвертирует raw market observations в структурированные hint-объекты.

Вход: market_summary.json, anomalies.json, news_reactions.csv|json (один из двух форматов) + опционально LLM для augmentation.

Выход: hints.yaml — список hint’ов с метаданными генерации.

Уникальное:

  • Rule-based + LLM augmentation: можно работать без LLM (rule-based extraction), а можно подключить LLM для ideation
  • hint schema: фиксированная структура (id, source, claim, evidence_strength, time_horizon, etc.) — это контракт для downstream

edge-concept-synthesizer (Stage 2, 75 строк, 104K)

Кластеризует тикеты в абстрактные edge-концепты с thesis/invalidation/playbook.

Вход: tickets/exportable/*.yaml + tickets/research_only/*.yaml + опционально hints.yaml.

Выход: edge_concepts.yaml — concept clusters с support stats и флагом export_ready.

Уникальное:

  • Clustering логика: --overlap-threshold, --no-dedup, --min-ticket-support параметры
  • Mechanism-level абстракция: из конкретных тикетов «TSLA gap-up 3 дня подряд» извлекается концепт «momentum persistence on high-vol names»

edge-strategy-designer (Stage 3, 66 строк, 68K)

Переводит концепты в конкретные strategy draft specs с вариантами.

Вход: edge_concepts.yaml.

Выход: strategy_drafts/*.yaml + run_manifest.json + опционально exportable_tickets/*.yaml.

Уникальное:

  • Variants generation: для каждого концепта создаёт 3 варианта — core (базовый), conservative (с дополнительными фильтрами), research-probe (для разведки)
  • Per-hypothesis exit calibration: разные типы стратегий требуют разных exit rules (mean-reversion vs momentum)
  • RR clamping: enforce min risk/reward ratio на уровне дизайна, не бэктеста

edge-strategy-reviewer (Stage 4, 108 строк, 100K)

Детерминированный quality gate: 8 критериев C1-C8.

Вход: strategy_drafts/*.yaml.

Выход: review.yaml/review.json + опционально markdown summary.

Уникальное:

  • 8 weighted критериев: C1 (sample size), C2 (expectancy), C3 (risk mgmt), C4 (robustness), C5-C8 (specific edge types)
  • PASS/REVISE/REJECT вердикт + confidence score
  • Export eligibility: только PASS-eligible стратегии попадают в Phase I pipeline
  • Revision instructions: при REVISE — конкретные указания, что изменить

edge-candidate-agent (Stage 5, 140 строк, 192K)

Export validated tickets в Phase-I-compatible format + preflight interface check.

Вход: ticket YAML + опционально OHLCV, hints.

Выход: strategies/<id>/strategy.yaml + metadata.json + validation report. Также может standalone auto-detect из OHLCV для fast-path.

Уникальное:

  • 3 отдельных скрипта: export_ticket.py, validate_strategy.py, auto_detect_candidates.py
  • edge-finder-candidate/v1 interface contract: фиксированная схема для совместимости с downstream trade-strategy-pipeline Phase I
  • Dry-run preflight: проверка совместимости до фактического export’а

edge-pipeline-orchestrator (meta, 128 строк, 148K)

Meta-controller: запускает всю цепочку с review-revision feedback loop.

Вход: tickets/ или OHLCV + опции (--llm-ideas-file, --promote-hints).

Выход: pipeline_run_manifest.json + все артефакты pipeline’а.

Уникальное:

  • Max 2-iter feedback loop: если reviewer выдал REVISE, дизайнер apply’ит revisions и стратегия уходит на re-review (макс 2 раза)
  • Resume/review-only режимы: --resume-from drafts (продолжить с указанной стадии), --review-only (только review без новых drafts), dry-run
  • Sequential executor: запускает 1→5 в правильном порядке, передавая артефакты

edge-signal-aggregator (cross-cutting, 218 строк, 124K)

Cross-skill aggregator: объединяет outputs от edge-candidate-agent + theme-detector + sector-analyst + institutional-flow-tracker.

Вход: outputs от 6 разных edge-finding skills (JSON/YAML).

Выход: edge_signal_aggregator_*.json + .md — ranked_signals + contradictions + dedup log.

Уникальное:

  • Weights config: разные источники имеют разный вес (например, institutional-flow выше, чем theme-detector для short-term)
  • Contradiction detection: если два источника дают противоположные сигналы, они помечаются и выносятся отдельно
  • Dedup log: избегает двойного учёта одной идеи от разных источников

Задачи, которые они покрывают

Типичный кейс edge research:

  1. «У меня есть дамп аномалий, что они могут значить?» → edge-hint-extractor (Stage 1)
  2. «У меня 50 тикетов, как сгруппировать их в концепты?» → edge-concept-synthesizer (Stage 2)
  3. «Концепты есть, дайте конкретные стратегии с параметрами» → edge-strategy-designer (Stage 3)
  4. «Стратегии готовы, какие из них проходят quality gate?» → edge-strategy-reviewer (Stage 4)
  5. «Прошедшие review, экспортируйте в формат для бэктеста» → edge-candidate-agent (Stage 5)
  6. «Запустите всё сразу, дайте мне итоговый набор» → edge-pipeline-orchestrator (full pipeline)
  7. «У меня сигналы от 6 разных источников, как их объединить?» → edge-signal-aggregator (cross-skill)

Метод: что общего и что уникально

Принцип 1: явные data contracts

У каждой стадии строго определён входной и выходной формат. Не «что-то JSON», а именованные YAML-файлы с фиксированной схемой:

hints.yaml
  ↓ (consumer: concept-synthesizer, candidate-agent)
edge_concepts.yaml
  ↓ (consumer: strategy-designer)
strategy_drafts/*.yaml
  ↓ (consumer: strategy-reviewer, candidate-agent)
review.yaml
  ↓ (consumer: candidate-agent, orchestrator)
strategy.yaml + metadata.json
  ↓ (consumer: trade-strategy-pipeline Phase I)

Это не случайное разделение — это versioned interface, как в GraphQL или gRPC. Каждый файл имеет свою schema, и изменение schema требует версионирования.

Принцип 2: resumability

edge-pipeline-orchestrator поддерживает --resume-from drafts. Это значит: если вы уже сделали strategy_drafts и review, и хотите только re-run candidate-agent — вы можете не пересчитывать upstream стадии. Это возможно только потому, что стадии разделены.

Если бы был один монолит, вам пришлось бы каждый раз прогонять весь pipeline, даже если изменился только последний шаг.

Принцип 3: тестируемость

Каждая стадия имеет свой tests/ и может быть протестирована изолированно:

  • Тест на hint-extractor: дать fake market_summary, проверить формат hints.yaml
  • Тест на concept-synthesizer: дать fake tickets, проверить clustering logic
  • Тест на reviewer: дать known draft, проверить verdict

В монолите тесты были бы integration-only, что медленнее и сложнее для CI.

Принцип 4: разные owners/maintainers

Hint extraction — это knowledge engineering (может делать data engineer с LLM-бэкграундом). Strategy design — это quant knowledge (нужен опыт в systematic trading). Quality review — это risk management (нужен опыт в risk). Export — это software engineering (нужен опыт в schema versioning).

Разные скиллы = разные владельцы = параллельная разработка без блокировок.

Уникальные знания в каждом скилле

edge-hint-extractor (rule-based + LLM)

  • Hint schema versioning: каждый hint имеет schema_version, чтобы downstream не ломался при изменениях
  • LLM fallback: если LLM недоступен, rule-based extraction даёт детерминированный baseline (меньше идей, но без hallucination’ов)
  • Time horizon filter: hints бывают short-term (1-3 дня), medium (1-4 недели), long-term (месяцы+); стадия 2 фильтрует по горизонту

edge-concept-synthesizer (clustering math)

  • Overlap threshold: насколько тикеты должны пересекаться по фичам, чтобы попасть в один кластер (по умолчанию 0.6)
  • Min ticket support: минимальное количество тикетов для формирования концепта (по умолчанию 3) — иначе это outlier, а не pattern
  • Mechanism description: каждый концепт получает текстовое описание механизма, не просто кластер фичей

edge-strategy-designer (variants + exits)

  • Core/Conservative/Probe variants: разные стратегии для разных целей — core (production), conservative (с дополнительными фильтрами), probe (для research)
  • Per-hypothesis exit calibration: для momentum — trailing stop; для mean-reversion — time stop; для breakout — volatility expansion filter
  • RR clamping: enforce min risk/reward (по умолчанию 1.5:1) на уровне дизайна

edge-strategy-reviewer (8 criteria)

  • C1: Sample size — достаточно ли trades в backtest для статистической значимости (по умолчанию ≥30)
  • C2: Expectancy — матожидание прибыли на trade (≥0.5R для PASS)
  • C3: Risk management — max drawdown, exposure, position concentration
  • C4: Robustness — стабильность на разных периодах (in-sample vs out-of-sample)
  • C5-C8: Type-specific — для mean-reversion (half-life), momentum (persistence), breakout (volume confirmation), и т.д.

edge-candidate-agent (interface contract)

  • edge-finder-candidate/v1 schema: фиксированный YAML с полями (id, hypothesis, instruments, parameters, expected_metrics, risk_constraints, etc.)
  • Preflight validation: перед записью проверяет, что strategy.yaml пройдёт downstream trade-strategy-pipeline Phase I
  • Metadata.json sidecar: machine-readable метаданные отдельно от human-readable YAML (для разных consumers)

edge-pipeline-orchestrator (loop logic)

  • Max 2-iter feedback loop: защита от infinite loop’а (если после 2-х итераций всё ещё REVISE → REJECT)
  • Resume mode: --resume-from drafts (продолжить с указанной стадии), --review-only (только review), --dry-run (без записи)
  • Manifest tracking: pipeline_run_manifest.json хранит все артефакты + timestamps + git hash для reproducibility

edge-signal-aggregator (cross-skill math)

  • Weights config: YAML с весами для каждого источника (например, institutional-flow: 0.35, edge-candidate: 0.30, theme-detector: 0.20, sector-analyst: 0.15)
  • Contradiction detection: если два источника сигналят противоположное — отдельный список contradictions[] с объяснением
  • Dedup log: не учитывает одну идею дважды, даже если она пришла от 3-х источников

Почему НЕ объединять

Аргумент 1: монолит = потеря resumability

Без --resume-from drafts каждый запуск pipeline’а = полный пересчёт с начала. Если у вас 4 часа на design + 2 часа на review, и вы хотите изменить только export — вам придётся ждать 6 часов вместо 20 минут.

Аргумент 2: монолит = потеря single-responsibility

Hint extraction (knowledge engineering) и strategy review (risk management) — это разные дисциплины. В монолите один скилл должен быть экспертом во всём, что нереалистично. На практике монолит превращается в 5000 строк, в которых никто не разбирается.

Аргумент 3: монолит = потеря тестируемости

Unit-тесты на hint extraction логику требуют mock’и для всего остального pipeline’а. В разделённых скиллах тесты изолированы и быстрые.

Аргумент 4: монолит = потеря ownership

Кто отвечает за bug в hint extraction? За ложный REVISE в review? За несовместимый export schema? В разделённых скиллах явный ownership — каждый скилл имеет своего maintainer’а.

Когда всё-таки можно объединить

auto_detect_candidates.py в edge-candidate-agent

Это единственное реальное пересечение: edge-candidate-agent имеет auto_detect_candidates.py, который функционально пересекается с edge-hint-extractor + edge-concept-synthesizer. Но это сознательный dual mode:

  • Standalone fast path (auto_detect): для случая, когда пользователь не хочет проходить split workflow
  • Split quality path (1→5): для production-grade research

SKILL.md явно говорит: «This skill can run end-to-end standalone, but in the split workflow it primarily serves the final export/validation stage». Orchestrator умеет вызывать auto_detect как первый stage.

Рекомендация: оставить как есть, но в SKILL.md усилить фразу «In production flow, prefer the split workflow». Это улучшит discoverability правильного пути, не убирая fast path.

Итоги

Все 7 скиллов остаются разделены. Это образцово спроектированный 2-уровневый pipeline:

  • Level 1 (core): 5 single-responsibility стадий с явными data contracts
  • Level 2 (orchestration): orchestrator (sequential) + signal-aggregator (cross-cutting)

Объединение ЛЮБОЙ пары ухудшит архитектуру: потеряется resumability, усложнится тестирование, нарушится single-responsibility. Единственное место для улучшения — документация auto_detect dual mode, не слияние.

Главный инсайт: когда вы видите 5-7 скиллов с одинаковым префиксом, не спешите объединять. Сначала проверьте, не спроектированы ли они как pipeline с явными handoff-контрактами. Если да — это здоровая архитектура, и её не надо трогать.

Ссылки

← Все статьи