Spaces:
Running
Running
| # Alami Vision — Produkt- & Tech-Roadmap | |
| > **Stand: 2026-07-03.** Antwort auf die Handoffs `AILLMHANDOFF.md` (Mobile-Agent) | |
| > und `TRASH_INTELLIGENCE.md` (Admin-Dashboard-Agent). Dieses Repo ist das | |
| > **Standalone-Projekt "Alami Vision"**: die visuelle KI der Alami-Plattform. | |
| > Die App konsumiert nur die API — Modell, Training und Daten-Flywheel leben hier. | |
| --- | |
| ## 1. Wo wir stehen (ehrliche Bestandsaufnahme) | |
| **Was existiert und funktioniert:** | |
| - **Serving:** FastAPI + ONNX Runtime, YOLOv8-seg (TACO-trainiert, 7 Material- | |
| klassen), Temperature-Calibration, Docker-fähig, deployed als Hugging Face | |
| Space (`nangiale-alami-trash-ai-api.hf.space`). Live im Economy-Gate der App. | |
| - **Trainings-Pipeline (Colab/Scripts):** `prepare_taco` → `train_yolov8_seg` → | |
| `calibrate_temp` → `evaluate` → `export_onnx` → Bundle. Dazu | |
| `ingest_feedback.py` (Feedback → YOLO-Dataset) und `active_sampler.py` | |
| (Active Learning) — das Flywheel-Gerüst ist schon da. | |
| - **Modellstand (v20251018-220439):** mAP50 0.42, Makro-Accuracy 0.81. | |
| `organic` und `ewaste` haben **F1 = 0.0** (keine Trainingsdaten). Auf | |
| strukturlosen Bildern neigt das Modell zu False Positives (im Test: 86 % | |
| Konfidenz "paper" auf einer grauen Fläche) — relevant, weil False Positives | |
| TC auszahlen. | |
| **Was auf diesem Branch gefixt wurde:** | |
| | Problem | Auswirkung | Fix | | |
| |---|---|---| | |
| | `requirements.txt` mit unaufgelöstem Merge-Konflikt | Jeder Docker-Build schlug fehl | aufgelöst | | |
| | `names.json` fehlte im Repo (von `.gitignore` verschluckt) | Server startete aus frischem Clone **gar nicht** | byte-identisch restauriert (SHA-256 == Original-Checksum), Fallback auf `model_card.json` eingebaut | | |
| | Bounding-Box-Rückprojektion wurde berechnet und dann verworfen | Alle Boxen in 640er-Raum statt Originalbild — Overlays/Flächen falsch | behoben + Regressionstest | | |
| | `verify=False` bei Bild-Fetch | TLS-Verifikation global aus | Default an, Opt-out nur per Env | | |
| | Debug-Endpoints öffentlich | Angriffs-/SSRF-Fläche in Prod | nur noch bei `ALAMI_DEBUG=1` | | |
| | Kein Auth | Jeder kann Feedback einschleusen (Trainings-Poisoning) und Compute stehlen | optionaler API-Key (`ALAMI_API_KEYS`) | | |
| | `raw_label` fehlte im Response | Mobile-Contract (`api/alamiAi.ts`) erwartet es | additiv ergänzt | | |
| **Neu auf diesem Branch:** `/v1/analyze` + `/v1/analyze/upload` (Standalone-API- | |
| Fläche mit Materialsummary, Stückzahl, Gewichtsschätzung v0), erweitertes | |
| `/feedback` (objektgenaue Korrekturen, `source`), Testsuite (13 Tests, inkl. | |
| End-to-End auf dem echten ONNX). | |
| --- | |
| ## 2. Produktvision: von der Müll-KI zur visuellen KI | |
| **Alami Vision** ist ein eigenständiges Produkt mit einer API: | |
| ``` | |
| ┌─────────────────────────────┐ | |
| Alami Mobile ──────► │ Alami Vision API │ ◄────── externe Kunden | |
| (validate + RLHF) │ /predict /v1/analyze /feedback │ (Städte, NGOs, | |
| └──────────────┬──────────────┘ Entsorger, Marken) | |
| │ | |
| Daten-Flywheel ▼ | |
| Fotos + User-Korrekturen (Typ, Stück, kg/Liter, Geo, Zeit) | |
| │ | |
| ingest_feedback → active_sampler → retrain → deploy | |
| ``` | |
| Die `domain`-Dimension der v1-API ist der Expansionspfad: heute `trash`, | |
| morgen weitere visuelle Domänen (Sperrmüll/Recyclinghof-Klassifikation, | |
| Container-Füllstand, illegale Deponien aus Drohnen-/Satellitenbildern, | |
| generische Objekterkennung mit Gewichtsschätzung). Clients integrieren einmal | |
| und bekommen neue Fähigkeiten als neuen `domain`-Wert — keine Migration. | |
| **Der eigentliche Asset ist nicht das Modell, sondern das Flywheel:** Millionen | |
| gelabelte, geo-getaggte, deduplizierte (pHash + SHA-256), fraud-geprüfte | |
| Müllfotos mit menschlich bestätigten Typ- **und Gewichts**-Angaben. Diesen | |
| Datensatz hat sonst niemand — genau deshalb zahlt die App 1 TC pro Solo-Foto: | |
| das Foto *ist* das Produkt. | |
| --- | |
| ## 3. Phasen | |
| ### Phase 1 — Fundament härten (dieser Branch) ✅ | |
| Bugfixes, Auth, v1-API, Tests, Doku. Deploybar auf den HF Space, 100 % | |
| rückwärtskompatibel zum Mobile-Client. | |
| ### Phase 2 — Modellqualität (nächste 4–8 Wochen) | |
| 1. **False-Positive-Rate senken** — sie kostet direkt Geld (FP ⇒ unverdiente TC) | |
| und Review-Last (Trust-Score). Hebel: Hintergrund-Negativbeispiele ins | |
| Training, Kalibrierung nachziehen, ggf. `conf_thr` je Klasse. | |
| 2. **`organic`/`ewaste` trainierbar machen** (Daten via | |
| `augment_external_datasets.py`, sonst Klassen vorerst aus `names.json` | |
| nehmen statt tote Klassen auszuliefern). | |
| 3. **Feedback-Flywheel** ✅ — code-seitig geschlossen (siehe `docs/FLYWHEEL.md`): | |
| `run_flywheel.py` orchestriert sync → ingest → report (wöchentliche GitHub | |
| Action) und train → calibrate → evaluate → export → **quality gate** → | |
| promote (GPU-Box/Colab). Regression ⇒ kein Deploy; jede Modellversion | |
| traceable über Registry + `model_version` auf jeder Zeile. Scharfschalten | |
| braucht nur noch die Checkliste in FLYWHEEL.md §5. | |
| ### Phase 3 — Gewicht lernen (das Alleinstellungsmerkmal) | |
| - Heute: `material_prior_v0` (ehrlich getaggte Heuristik, s. `docs/api.md`). | |
| - Die App liefert bereits `corrected_weight_kg` über `/feedback` und Events | |
| liefern kg/Liter-Angaben ⇒ es entsteht ein **(Bild, Boxen, Gewicht)**-Korpus. | |
| - Ab ~50k gewichts-gelabelten Fotos: Regressions-Head aufs Backbone | |
| (Gewicht pro Objekt + Unsicherheit). `weight_source` wechselt von | |
| `material_prior_v0` auf die Modellversion — Clients merken den Umstieg am Feld. | |
| - **Ökonomie-Umstellung Solo → kg-basiert** ist danach möglich, bleibt aber | |
| laut Hard Contract eine **Founder-Entscheidung** (Server-RPC, nicht KI-seitig). | |
| ### Phase 4 — Brand Intelligence (Geld-Phase, braucht dein Sign-off) | |
| Deckungsgleich mit `TRASH_INTELLIGENCE.md`: Vision-LLM extrahiert Marke/ | |
| Hersteller pro sichtbarem Logo, asynchron über den Foto-Backlog (nie im | |
| Submit-Pfad), Ergebnisse in `trash_brand_detections` (Schema-Vorschlag liegt | |
| vor, **kein Schema-Change ohne dein Go**), Human-Review-Queue im Admin-Dashboard, | |
| jährlicher **Alami Trash Transparency Report**. | |
| - Technisch hier im Repo: Batch-Worker, der `/v1/analyze`-Detections mit einem | |
| Vision-LLM-Call (Logo/Brand) anreichert; Join über `trash_photo_signatures`. | |
| - Privacy wie im Proposal: PII-Blur vor Inferenz/Training, nie Reporter- | |
| Identität in Aggregaten, Cascade-Delete. | |
| ### Phase 5 — Skalierung als Plattform | |
| - **Serving:** stateless API hinter Load Balancer; HF Space ⇒ Container auf | |
| eigener Infra (Cloud Run/Fly/K8s) mit Autoscaling; GPU-Batch-Worker für | |
| Backlog-Jobs; Warteschlange (z. B. Supabase Queue/Redis) für async Analysen. | |
| - **Uptime ist Auszahlungs-kritisch** (`unavailable` ⇒ 0 TC): Health-Alerts, | |
| zweite Region/Replica, Canary-Deploys neuer Bundles (Registry existiert). | |
| - **Multi-Tenant:** API-Keys je Kunde (heute simple Env-Liste, später Tabelle | |
| mit Rate-Limits/Quotas + Usage-Metering pro Key = Abrechnungsgrundlage). | |
| --- | |
| ## 4. Monetarisierung | |
| 1. **Vision-API als Produkt** (`/v1/analyze`): Abrechnung pro Bild, Staffelpreise. | |
| Zielkunden: Kommunen/Städte (Littering-Monitoring), Entsorger (Sortier- | |
| Vorprüfung), NGOs, andere Cleanup-Apps. Multipart-Upload existiert schon — | |
| Kunden brauchen keine Bild-URLs. | |
| 2. **Brand Transparency Report** (Phase 4): jährlicher Report "welche Marken | |
| liegen in der Landschaft" — relevant für **EPR-Compliance** (Extended | |
| Producer Responsibility, EU-Verpackungsrecht), ESG-Reporting der Hersteller | |
| und Presse. Verkauf als Report + Daten-Abo pro Marke/Region. | |
| 3. **Datensatz-Lizenzierung:** der deduplizierte, gelabelte, geo-gestempelte | |
| Litter-Korpus (nur mit PII-Blur + Privacy-Regeln aus dem Proposal) für | |
| Forschung/Industrie. | |
| 4. **White-Label-Dashboards** für Städte (Karten, Trends, Materialmix) auf Basis | |
| der Aggregate aus dem Admin-Dashboard-Projekt. | |
| Reihenfolge bewusst: erst Modellqualität (2), dann Gewicht (3) — beides macht | |
| die API verkaufbar —, dann Brand (4) als margenstärkstes Produkt. | |
| --- | |
| ## 5. Hard Contracts (gelten unverändert, aus `AILLMHANDOFF.md` §5) | |
| 1. KI setzt **niemals** TC-Beträge — nur Signale (`ai_detected`, `ai_status`). | |
| 2. Der Submit-Pfad der App darf nie an der KI scheitern (`verifyPhotosWithAI` | |
| bleibt non-throwing; API-Fehler ⇒ `unavailable` + `needs_review`). | |
| 3. `ai_status`-Vokabular fix: `verified | no_detection | unavailable`. | |
| 4. Ökonomie-Zahlen leben in `tc_config`, nicht im KI-Code. | |
| 5. Fraud-Signale (`trash_photo_signatures`, pHash, `needs_review`) nicht schwächen. | |
| 6. **API-Keys erst erzwingen, wenn die Mobile-App den Header sendet** — | |
| sonst `unavailable` für alle ⇒ ehrliche Nutzer bekommen 0 TC. | |
| --- | |
| ## 7. Strategische Erweiterung — von der Müll-KI zur räumlichen Vision-KI | |
| > Founder-Vision (2026-07-15): Alami Vision soll mehr können als Müll erkennen. | |
| > Es soll **Szenen verstehen** — „das ist eine Pflanze, kein Müll", „das ist ein | |
| > Stuhl", „ich sehe 3 Plastikflaschen und eine Katze" — und diese räumliche | |
| > Objekt-Intelligenz später als **API an Industrien** verkaufen (Drohnen- | |
| > Luftbild-Erkennung illegaler Deponien im Wald, Entsorger, Kommunen, …). | |
| > Ziel: das führende Vision-KI-Modell für die physische/ökologische Welt. | |
| ### 7.1 Warum das kein Umweg ist, sondern unser aktuelles Problem löst | |
| Der teuerste Fehler des heutigen Modells ist der **False Positive**: Es „sieht" | |
| Müll auf leerem Boden (86 % „paper" auf grauer Fläche im Test) und würde dafür | |
| TC auszahlen. Ursache: Das Modell hat nie gelernt, wie **Nicht-Müll** aussieht. | |
| „Erkenne die Pflanze / den Stuhl / die Katze" ist damit **exakt die Medizin | |
| gegen unser Nr.-1-Problem** — nicht ein Nebenprojekt. Wer weiß, was eine | |
| Pflanze ist, zahlt sie nicht als Müll aus. Die Auto-Negatives (Runde 3) sind | |
| die primitive Vorstufe; echte Objekt-/Szenenerkennung ist die ausgereifte. | |
| **Synergie, kein Ablenkungsmanöver.** | |
| ### 7.2 Die zentrale Architektur-Entscheidung (hier verdienen wir Geld oder verbrennen es) | |
| Es gibt zwei Wege, „Katze/Stuhl/Haus erkennen" zu bauen — und nur einer ist für | |
| ein Startup richtig: | |
| | | ❌ Weg A: Generalisten selbst trainieren | ✅ Weg B: Spezialist auf Fundament | | |
| |---|---|---| | |
| | Was | Von Null ein Modell bauen, das die ganze Welt kennt | Ein **Open-Vocabulary-Backbone** (YOLO-World, Grounding-DINO, OWLv2, SAM) nutzen, das „Katze/Stuhl/Baum/Gebäude" schon kann, + **unseren Fach-Kopf** obendrauf | | |
| | Kosten | Millionen, Jahre, Google/Meta-Liga | Wir integrieren das Fundament, trainieren nur unsere Schicht | | |
| | Ergebnis | Schlechter als das, was es gratis gibt | Etwas, das **niemand sonst hat** | | |
| **Weg B ist die Strategie.** Zwei Schichten: | |
| - **Fundament (die Augen):** ein offenes Objekt-/Szenenmodell, das benennt, was | |
| im Bild ist — Katze, Stuhl, Baum, Auto, Flasche. Von der Stange, austauschbar. | |
| - **Alami-Fach-Kopf (das Gehirn):** was davon ist Müll, welches **Material**, | |
| welche **Entsorgung**, welches **Gewicht**, welche **Marke**, recyclebar? Diese | |
| Domänen-Intelligenz hat **nur** Alami — sie kommt aus dem Flywheel (echte Feld- | |
| fotos + menschliche Korrekturen + kg/Material/Disposal-Wissen). | |
| Ergebnis-Beispiel: *„Ich sehe 3 Plastikflaschen (Gelbe Tonne, ~60 g), 1 Pflanze | |
| (kein Müll), 1 Katze (kein Müll)."* — Fundament sagt WAS, unsere Schicht sagt | |
| was es FÜR DIE UMWELT bedeutet. Das ist der verkaufbare Unterschied. | |
| ### 7.3 Ehrliche Trennung von zwei Ambitionen | |
| Damit die Vision nicht am Kapital scheitert, zwei Dinge sauber trennen: | |
| - **Ambition A — erreichbar & riesig:** *DER* Domänen-Experte für die physische | |
| Welt aus Umwelt-/Kreislaufwirtschafts-Sicht — Müll, Material, Entsorgung, | |
| illegale Deponien, Container-Füllstand, EPR-Compliance. Hier schlägt uns unser | |
| **Datengraben** jeden Generalisten. Verkaufbar an Entsorger, Kommunen, | |
| Versicherer, Drohnen-Survey-Firmen, ESG-Abteilungen. | |
| - **Ambition B — Moonshot, andere Kapital-Liga:** ein allgemeines Vision- | |
| Fundamentmodell wie GPT-4V/Gemini. Das baut man als Startup **nicht** von | |
| Null. Aber: Wir **reiten** diese Modelle (als Backbone) und legen unsere | |
| Schicht drauf — so bekommen wir die räumliche Fähigkeit, ohne die | |
| Fundament-Kosten. Positionierung: *„Wir schlagen das Generalmodell nicht — wir | |
| sind der Spezialist, der es für Müll/Umwelt nützlich macht, mit Daten, die | |
| niemand sonst hat."* | |
| ### 7.4 Neue Produktlinie: „Alami Aerial" (Drohnen-/Luftbild — naheliegend) | |
| Die Drohnen-Idee ist **nicht** ferne Zukunft — die Daten liegen schon | |
| lizenzgeprüft im Katalog: **DroneWaste** (4.993 Luftbilder, CC BY 4.0), | |
| **UAVVaste** (Apache-2.0), **pLitterStreet** (13k Straßenszenen aus | |
| Fahrzeugperspektive, CC BY 4.0). Die `domain`-Dimension der v1-API kann | |
| `aerial-litter` als neuen Wert aufnehmen — **ohne Migration für bestehende | |
| Clients**. Zielkunden: Forstämter, Umweltbehörden, Kommunen (illegale Deponien | |
| im Wald/an Feldwegen), Drohnen-Dienstleister. Mögliche eigenständige, früher als | |
| Brand-Intelligence startende Umsatzlinie. (Gefahrgut-Hinweis „nicht anfassen, | |
| Behörde informieren" aus dem DroneWaste-Paper passt hier dazu — siehe Backlog.) | |
| ### 7.4b Dritte Domäne: „Alami Marine" (Unterwasser/Meer — Founder-Vision 2026-07-15) | |
| Damit ist Alami Vision **dreidimensional**: **Land** (Boden/Produkt) + **Luft** | |
| (Drohne) + **Wasser** (Unterwasser-Drohnen/ROV/AUV, schwimmender Meeresmüll). | |
| Das macht uns zur kompletten Umwelt-Litter-Plattform — jede Domäne ist ein | |
| neuer `domain`-Wert (`underwater-litter` / `marine-debris`), kein Client-Bruch. | |
| **Datenlage (bekannt, Lizenz-Verifikation ausstehend):** | |
| - **TrashCan 1.0** und **Trash-ICRA19** (Uni Minnesota, Hong/Fulton/Sattar) — | |
| ROV-Unterwasser-Müll, Instanz-Segmentierung/BBox. Standen bisher als | |
| „academic use"; **die genaue DRUM-Lizenz muss geprüft werden** (könnte CC BY/ | |
| CC0 sein — dann kommerziell nutzbar). Top-Priorität der Meeres-Recherche. | |
| - Weitere Kandidaten für den Sweep: **FathomNet** (MBARI, Tiefsee-Bilder mit | |
| Concept-Labels inkl. Debris), **JAMSTEC J-EDI Deep-sea Debris DB**, | |
| **MARIDA/MADOS** (Satelliten-Meeresplastik), schwimmender Fluss-/Hafenmüll. | |
| **Machbarkeit — ehrlich:** Unterwasser ist bildtechnisch *härter* (Blaugrün- | |
| Stich, Trübung, Rückstreuung, wenig Licht, Bewuchs, Größenambiguität). Die | |
| Zwei-Schichten-Strategie trägt trotzdem: offenes Backbone als Augen + unser | |
| Fach-Kopf, **fein-getunt auf Unterwasser-Daten** (Farbkorrektur à la Sea-thru | |
| als Vorverarbeitung). Kunden: Marine-Survey-Firmen, Häfen, Ocean-Cleanup-NGOs, | |
| Aquakultur, Forschungsschiffe. **Marktgröße kleiner & spezialisierter als Land/ | |
| Luft, Datenknappheit größer** ⇒ Einordnung: **nach Aerial**, nicht davor — | |
| strategisch top, aber der Reihe nach. | |
| > Ein eigener lizenzgeprüfter Meeres-Datensatz-Sweep (6 Finder + adversariale | |
| > Verifikation + Machbarkeit) ist vorbereitet und wird gefahren, sobald die | |
| > Umgebung stabil ist; Ergebnis kommt hier in §7.4b + TRAINING_DATA.md. | |
| ### 7.5 Sequenz (ohne die aktuelle Dynamik zu bremsen) | |
| 1. **Jetzt:** Basis-Detektor fertig trainieren (Kaggle-Lauf läuft), organic/ | |
| ewaste aus F1=0 holen, False Positives über Negatives dämpfen. | |
| 2. **Als Nächstes — „ist das überhaupt Müll?"-Gate:** Open-Vocabulary-Backbone | |
| als neue Fähigkeit (`domain=scene`) andocken → Objekt-Inventar + Nicht-Müll- | |
| Erkennung. Halbiert False Positives und liefert das „3 Flaschen + 1 Katze". | |
| 3. **Parallel/danach:** `Alami Aerial` (Daten da) → dann `Alami Marine` | |
| (Unterwasser, §7.4b — nach Aerial), Gewichts-Kopf (Daten wachsen), | |
| Brand (geparkt). | |
| 4. **Plattform:** Multi-Tenant-API mit Usage-Metering pro Key (Roadmap §Phase 5) | |
| = Abrechnungsgrundlage für den Verkauf an Industrien. Das | |
| Reproduzierbarkeits-Manifest (`dataset_manifest.py`) ist dafür Voraussetzung | |
| — Industriekunden/Investoren auditieren, worauf trainiert wurde. | |
| **Roter Faden:** Jede neue Domäne (Boden, Produkt-Scan, Luftbild, Szene) füttert | |
| **dasselbe Flywheel**. Der Datengraben wächst mit jeder Domäne — das ist der | |
| Grund, warum ein Spezialist mit eigenem Datenmotor einen Generalisten in dieser | |
| Nische dauerhaft schlägt. | |
| --- | |
| ## 6. Offene Fragen an dich / den Mobile-Agenten | |
| 1. **HF-Space-Code vs. Repo:** Der Space lief bisher mit einem Bundle, das | |
| dieses Repo nicht vollständig enthielt. Nach Merge dieses Branches sollte | |
| der Space aus dem Repo deployt werden (Single Source of Truth). Wer deployt | |
| den Space — CI hier, oder manuell? | |
| 2. **Brand-Pipeline Sign-off** (Phase 4): Schema `trash_brand_detections` wie | |
| im Proposal? Welcher Vision-LLM-Anbieter, welches Budget pro Bild? | |
| 3. **Mobile:** Wann kann der App-Client den `x-api-key`-Header mitschicken | |
| (kleines Change in `api/alamiAi.ts`), damit wir Auth scharf schalten können? | |
| 4. **Supabase-Logging:** `SUPABASE_URL`/`SERVICE_ROLE_KEY` am Space setzen, | |
| damit Predictions zentral in `trash_predictions` landen (heute nur JSONL im | |
| ephemeren Space-Storage — bei Restart weg)? | |