Parashar: Ein KI-Produkt aus Domain-Expertise bauen
Produktstrategie · AI-Loop-Engineering · Domain-zu-Consumer-Intelligence · 2024–heute
Executive Summary
Parashar ist ein KI-Consumer-Produkt, das prädiktive Analyse auf eine komplexe traditionelle Wissensdomain anwendet. Das System arbeitet mit astronomischen Positionsdaten (Swiss Ephemeris) kombiniert mit Tausenden Interpretationsregeln — eine rechenintensive Domain mit präzisen Inputs und geschichteter Reasoning. Die Produktchallenge war strategisch: welche Analysesysteme priorisieren, wie AI-Loops interdependenten Regeln korrekt anwenden, und wie dichte multidimensionale Outputs für Nicht-Experten nutzbar werden. Side Project aus echtem intellektuellem Interesse — und Realwelt-Test, wie Domain-Expertise AI-Produktdenken formt.
1. Das Problem
Die Zieldomain hat drei Eigenschaften, die Software-Service erschweren:
Regelkomplexität. Die Domain arbeitet mit Tausenden interdependenten Variablen aus astronomischen Positionsdaten (Swiss Ephemeris). Eine Analyse erfordert Querverweise mehrerer Analysesysteme mit eigenen Regeln, Ausnahmen und Kontextmodifikatoren. Experten brauchen Jahre, diese Interaktionen zu navigieren.
Rechenintensität. Eine vollständige Analyse manuell erfordert Planetenpositionen auf Bogenminuten-Präzision und geschichtete Interpretationsregeln über Dutzende Datenpunkte. Experten brauchen Stunden für eine Lesung. Die Astronomie-Schicht ist deterministisch; die Interpretationsschicht braucht Kontexturteil über konkurrierende Systeme.
Expertise-Gatekeeping. Zugang zu Qualitätsanalyse erfordert einen erfahrenen Praktiker. Keine Standardzertifizierung, enorme Qualitätsunterschiede, Wissen traditionell über Lehre. Die meisten Konsumenten unterscheiden strenge Analyse nicht von oberflächlicher Arbeit.
Die Chance
Wenn astronomische Daten präzise sind (Swiss Ephemeris) und Regeln kodierbar, kann KI sie im Maßstab anwenden. Produktthese: Zugang zu Expertenanalyse demokratisieren durch präzise wissenschaftliche Berechnung plus KI-Regelanwendung und Kontext-Reasoning.
2. Produktstrategie: Was bauen
System-Scoping
Die Domain hat 10+ Analysesysteme für unterschiedliche Dimensionen. Alles einbeziehen ist umfassend aber überwältigend; zu wenig wirkt für Experten seicht.
Strategische Frage: welche minimale Systemabdeckung liefert nützliche, glaubwürdige Analyse? Klassisches v1-Scoping — dasselbe Problem jedes PM.
Ansatz: Analysesysteme nach drei Kriterien ranken:
- Coverage — welcher Anteil der Nutzerfragen wird adressiert?
- Computational determinism — Regeln zuverlässig kodierbar oder subjektives Urteil nötig?
- Inter-system dependency — speist Output andere Systeme? (Dann Infrastruktur, nicht optional)
Systeme mit hohen Scores auf allen dreien zuerst. Schwere Kontexturteile → spätere Iterationen.
Was die KI tun soll vs. nicht
Nicht jeder Domain-Teil sollte automatisiert werden. Strategisches Framework:
KI sollte
- Astronomische Positionsberechnung
- Deterministische Regelanwendung
- Querverweis mehrerer Systeme
- Mustererkennung über Datensätze
KI sollte (noch) nicht
- Kontextsynthese über ambige Signale
- Urteile, wo Experten divergieren
- Offene Interpretationsnarrative
- Präskriptive Empfehlungen ohne Konfidenzgrenzen
Dieselbe Build-vs-Defer-Disziplin jedes KI-Produkts — wissen, wo KI Wert schafft und wo falsche Sicherheit.
3. AI-Loop-Engineering
Die Kernherausforderung
Standard-KI-Produkte lernen aus Datenmustern. Parashar muss Regelsysteme lernen — Tausende interdependent if-then, hierarchische Overrides, Kontextgewichte. Die AI-Loops sind engineered für:
- Präzise astronomische Daten ingestieren — Swiss Ephemeris liefert Positionen, Aspekte, Timing auf Bogenminuten.
- Regelkaskaden anwenden — mehrere Systeme sequentiell; Zwischenoutputs speisen das nächste.
- Konflikte lösen — bei Widerspruch folgt gewichtetes Framework Domain-Konventionen.
- Geschichteten Output erzeugen — Primärsignal, unterstützende Analyse, Edge Cases und Caveats.
Engineering-Evaluationskriterien
„Korrekt“ geht hier über statistische Genauigkeit hinaus:
- Positionsgenauigkeit — Berechnungen matchen Swiss Ephemeris auf Bogenminuten
- Regeltreue — Regeln wie ein Domain-Experte angewendet
- Systemgewichtung — Konfliktlösung matcht Expertenkonsens zur Hierarchie
- Vollständigkeit — Output deckt relevante Systeme ab ohne dimensions, die die Schlussfolgerung ändern würden
Diese Kriterien kommen aus Domain-Expertise, nicht gelabelten Datasets. Wer „korrekt“ definiert, muss Domain-Experte sein — kein ML-Engineer, der Korrektheit aus Trainingsdaten approximiert.
4. UX: Komplexität zugänglich machen
Die Domain erzeugt dichte, multidimensionale Outputs. Vollständige Analyse kann 10+ Dimensionen gleichzeitig abdecken. Alles auf einmal überwältigt; zu wenig wirkt seicht.
- Level 1 — Headline-Signal. Dominanter Befund klar. Was muss der Nutzer am meisten wissen?
- Level 2 — Supporting analysis. Die 3–4 Dimensionen, die die Headline verstärken, qualifizieren oder verkomplizieren.
- Level 3 — Full depth. Jeder System-Output, Querverweise, Konfidenzgrenzen, Edge Cases — verfügbar, nie erzwungen.
Produktmeinung: Klarheit als Default, Tiefe anbieten. Beides ohne Kompromiss.
5. Was das über Produktdenken zeigt
Domain-Expertise als strategischer Vorteil
Die meisten KI-Produkte bauen Teams, die genug Domain lernen zum Shippen. Parashar invertiert das — der Produktstratege ist Domain-Experte. Das senkt den Übersetzungsverlust, der KI-Produkte typisch schwächt:
- Keine Spec-to-Implementation-Lücke. Wer scoped, versteht Edge Cases, Systeminteraktionen und Qualitätslatte.
- Evaluationskriterien spiegeln echte Expertise. „Korrekter Output“ setzt jemand, der weiß, was ein Experte erzeugen würde.
- UX-Prioritäten sind domain-informiert. Was zuerst, Konfliktbehandlung, Progressive Disclosure hier — praxisbasiert.
Produktstrategie + AI-Engineering, nicht ML-Engineering
Die Rolle spannt Produktvision, AI-Loop-Engineering, Systemarchitektur und UX-Strategie — nicht Modelltraining oder Infra:
| Produkt + AI-Strategie (diese Rolle) | ML-Engineering (andere Rolle) |
|---|---|
| Was soll die KI tun? | Wie lernt das Modell? |
| Wie sieht korrekter Output aus? | Welche Loss-Funktion optimiert Korrektheit? |
| Wie sollen Regelkonflikte gelöst werden? | Wie behandelt das Modell Widersprüche? |
| Welche Systeme in v1? | Was ist die minimum viable accuracy? |
| Wie soll Unsicherheit präsentiert werden? | Wie wird Confidence kalibriert? |
Beides essenziell. Diese Fallstudie betrifft die linke Spalte.
6. Aktueller Status
Aktives Side Project (2024–heute). Produktvision definiert, Analysesysteme gescoped und priorisiert, AI-Loop-Architektur spezifiziert, Evaluationskriterien etabliert, UX-Strategie designed. Aus echtem intellektuellem Interesse — wissenschaftlich fundierte Computation plus regelbasierte Interpretation, Realwelt-Test von AI-Produktstrategie.
7. Key Takeaways
Domain-zu-Produkt-Übersetzung: Der härteste Teil eines KI-Produkts ist nicht die KI — es ist strategisches Scoping. Welche Regeln kodieren, welche Systeme verschieben, wo KI Wert vs. falsche Sicherheit schafft. Produktentscheidungen, keine Engineering-Entscheidungen.
AI-Loop-Engineering: Wenn KI Regelsysteme anwendet (nicht Musterfindung), verschiebt sich die Challenge von Trainingsdaten zu Regeltreue. Evaluationskriterien müssen aus Domain-Expertise kommen, nicht nur Statistik-Benchmarks.
Komplexität zugänglich machen: Progressive Disclosure ist Produktstrategie, nicht nur UX-Muster. Was auf Level 2 oder 3 wandert, entscheidet Empowerment vs. Überforderung.
Takeaway
Dasselbe Produkturteil wie Trading/Risk-AI: wissen, was deterministisch vs. interpretativ ist, und was zuerst surfaced wird, wenn der Nutzer nicht jede Schicht auditieren kann.