Hugging Face's logo

Spaces:
alami-eco
/
alami-vision-api
Running

App Files Community
alami-vision-api / docs /VISION_ROADMAP.md
alami-ci
Deploy from alami-eco/alami-trash-ai@aee69796b70947e95efdb9c7483fa52f8d3b4520
76838d6
preview code
|
Raw
History Blame Contribute Delete
17.3 kB

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)?