ADRs
ADR 0013 — "Чем дольше живём — тем меньше платим" как hard requirement
  • Date: 2026-05-22
  • Status: Accepted
  • Feature: URL-import
  • Affects: url_import_spec.md § IX (cost trajectory), § VIII (caching), § X (flywheel)

Context

При обсуждении стека и cost trajectory юзер сформулировал product requirement:

"Нужно придумать решение на перспективу — чем дольше живём, тем меньше платим. Это не просьба — это требование к фиче."

Это не nice-to-have, это hard requirement. URL-import не должен иметь constant cost — он должен активно дешеветь с usage scale и time.

Decision

3 независимых cost reduction множителя (если один пробуксует, остальные работают):

Multiplier 1: Cache hit rate growth

Три уровня caching:

  • L1 pHash exact — re-imports, SaaS templates (Webflow themes повторяются)
  • L2 DINOv2 ONNX CPU + pgvector (cosine > 0.95) — visual similarity
  • L3 E5-small atoms + pgvector (cosine > 0.85) — semantic composition

Conservative trajectory:

VolumeL1L2L3Total
100 URLs5%8%1%14%
1k12%18%4%34%
10k20%25%9%54%
100k25%30%13%68%

Catalog растёт → больше hits → каждый последующий URL дешевле.

Multiplier 2: Data flywheel (LoRA training)

Каждая extraction в production пишет в shadow_dataset (ToS-disclosed, см ADR 0017). Юзерские corrections = gold labels.

Quarterly LoRA fine-tune Qwen3-VL-32B (Apache 2.0, см ADR 0014) на этом dataset → in-house модель замещает paid Gemini calls.

  • Q1: ~10k training examples
  • Q2: LoRA deployed для vision tasks → ~70% paid VLM calls → in-house
  • Vision cost × 0.1 на этих компонентах

Multiplier 3: Tier routing

  • Cerebras free tier (1M tok/day) — junior code generation
  • Cerebras paid ($0.60/1M) — when free exhausted
  • Gemini Flash-Lite — vision + LLM
  • Modal Labs — burst GPU, не constant

Cheap operations route through free tier; expensive only when необходимо.

Why independent multipliers

Если каждый множитель зависит от других → катастрофа одного топит всё. Например:

  • LoRA training fails (data quality issue) → if cost reduction depended only on LoRA → стоимость не падает
  • Cache invalidation бag → if depended only on cache → стоимость не падает

Independent design: cache работает даже без LoRA, tier routing работает даже без cache, LoRA работает даже без atoms catalog seeded.

Cost trajectory result

Period$/URLЧто работает
M1-3 Bootstrap$0.06-0.10Только tier routing, cache 0%
M4-6 Ramping$0.02-0.04Cache builds, LoRA Q1 deployed
M6-12 Steady$0.005-0.01All 3 multipliers active
M12+ Mature$0.002-0.005Compound effects

3-30× total reduction over 12 months. Hard requirement satisfied.

Consequences

Pros:

  • Long-term competitive cost advantage
  • LTV economics scale (small-biz LTV $300-600 vs cost $0.002 = excellent unit economics)
  • Marketing message: "ARNO gets cheaper the more you use it"

Cons:

  • Initial implementation effort triples (cache + flywheel + routing all needed)
  • Each multiplier needs measurement infrastructure
  • LoRA training infrastructure cost $1500-5000/quarter

Acceptable because юзер explicit prefer this trade-off.

Risks и mitigations

RiskMitigation
LoRA training never reaches pareto deploymentEscape valve: relax criteria, switch teacher, then suspend (§ X.4)
Cache hit rate plateaus low (юзеры импортируют very diverse sites)Atom-level cache (L3) catches composition reuse даже когда visuals diverse
Catalog поллютится seeded atomsPre-load shadcn только (MIT, high quality), не all-of-npm

Alternatives rejected

A. "Наш стек дёшев" (изначальный)

  • ❌ Static cost — может быть competitive сегодня, через 2 года competitors с flywheel дешевле
  • ❌ Не satisfies hard requirement

B. Single optimization (cache only OR LoRA only)

  • ❌ Single point of failure — если оптимизация broken, no fallback
  • ❌ Lower total reduction (cache → ~50% saving, LoRA → ~30% saving, combined > 70%)

Cross-references