Forschungs- & Praxisprojekt
Erklärbares Such- und Bewertungssystem
| Autor | Johannes Teitge |
|---|---|
| Projekt | NephroFood |
| Kontext | Forschungs- / Praxisprojekt |
| Schwerpunkte |
Information Retrieval Explainable Search UX-Transparenz Medizinische Anwendungen |
| Lizenz | GPL-2.0-or-later |
Der SearchService verfolgt bewusst nicht das Ziel einer rein statistisch optimierten oder maschinell trainierten Suche.
sondern explizit auch:
- Warum wurde dieses Ergebnis angezeigt?
- Welcher Suchbegriff war verantwortlich?
- Wie stark war dessen Einfluss?
Diese Transparenz ist insbesondere relevant für medizinische, ernährungsbezogene und regulatorisch sensible Anwendungen.
Explainable Information Retrieval als primäres Systemziel
Aus informationswissenschaftlicher Sicht positioniert sich der SearchService bewusst außerhalb klassischer Black-Box-Ansätze des modernen Information Retrieval.
Während viele zeitgenössische Suchsysteme ihre Relevanzbewertung implizit über statistische Modelle, Vektorraumberechnungen oder neuronale Netze realisieren, verfolgt dieses System einen deterministischen, regelbasierten und vollständig erklärbaren Ansatz.
Der zentrale Entwurfsgrundsatz lautet dabei:
Relevanz ist keine Eigenschaft eines Ergebnisses, sondern eine erklärbare Beziehung zwischen Suchanfrage und Datenobjekt.
Abgrenzung zu Black-Box-Systemen
In klassischen Machine-Learning-basierten Suchsystemen entsteht Relevanz häufig als emergente Eigenschaft hochdimensionaler Modelle. Diese Modelle liefern zwar häufig gute Ranglisten, sind jedoch:
- nicht deterministisch nachvollziehbar
- nicht reproduzierbar im strengen Sinne
- für Endnutzer:innen nicht erklärbar
- in medizinischen Kontexten regulatorisch problematisch
Der SearchService verzichtet bewusst auf diese Intransparenz und implementiert stattdessen eine explizite Relevanzmodellierung, bei der jeder Score aus klar definierten Einzelbeiträgen besteht.
Zielkonflikt: Relevanz vs. Erklärbarkeit
Ein zentrales Forschungsproblem moderner Suchsysteme besteht im Spannungsfeld zwischen maximaler Ranking-Performance und maximaler Erklärbarkeit.
Der SearchService trifft hier eine bewusste Designentscheidung:
Diese Entscheidung ist insbesondere im medizinisch-ernährungsbezogenen Anwendungskontext essenziell, da Nutzer:innen nicht nur Ergebnisse konsumieren, sondern diesen vertrauen müssen.
Didaktische und regulatorische Motivation
Die Zielsetzung des Systems ist daher nicht ausschließlich funktional, sondern auch:
- didaktisch (Nachvollziehbarkeit für Nutzer:innen)
- auditierbar (regelbasierte Entscheidungsfindung)
- regulatorisch anschlussfähig (medizinische Kontexte)
- wissenschaftlich analysierbar (klassisches IR-Modell)
Damit versteht sich der SearchService nicht als rein technisches Artefakt, sondern als verantwortungsbewusstes Informationssystem, dessen Zielsetzung explizit über reine Ranking-Qualität hinausgeht.
Der SearchService ist strikt geschichtet:
- Trennung von Kandidatenfindung und Bewertung
- Mehrstufiges Matching (direkt, Prefix, Fuzzy mit adaptiver Toleranz)
- Skalierbarkeit durch Prefix-Index
- Keine Machine-Learning-Blackbox
- Explainability by Design
Deterministische Sucharchitektur als erklärbares Verarbeitungssystem
Aus softwarearchitektonischer Sicht ist der SearchService nicht als monolithische Suchfunktion konzipiert, sondern als deterministische Verarbeitungspipeline mit klar abgegrenzten Verantwortlichkeiten.
Jede Phase der Pipeline erfüllt eine wohldefinierte Aufgabe und ist konzeptuell wie implementatorisch von den übrigen Phasen getrennt. Dadurch entsteht ein System, dessen Verhalten sowohl lokal analysierbar als auch global erklärbar bleibt.
1. Pipeline statt monolithischer Suche
Klassische Suchimplementierungen vermischen häufig:
- Kandidatenselektion
- Relevanzbewertung
- Filterlogik
Der SearchService vermeidet diese Vermischung bewusst und modelliert die Suche als lineare, aber semantisch getrennte Pipeline:
Diese Struktur erlaubt es, jede Phase isoliert zu testen, zu modifizieren und zu begründen – ein zentrales Kriterium für erklärbare Systeme.
2. Trennung von Recall und Precision
Informationstheoretisch folgt die Architektur der klassischen Trennung von:
- Recall-orientierter Kandidatenselektion
- Precision-orientierter Bewertung
Die Kandidatenfindung (Prefix-Index, Supplement-Scan, Fuzzy-Fallback) ist bewusst großzügig ausgelegt, um False Negatives zu vermeiden.
Die eigentliche Präzision entsteht erst im Scoring- und Matching-Schritt, der streng deterministisch arbeitet.
Architekturprinzip: Lieber erklärbar zu viel finden, als unerklärbar relevante Ergebnisse verlieren.
3. Determinismus als Entwurfsprinzip
Ein zentrales Designziel ist vollständiger Determinismus:
- Gleiche Eingabe → gleiche Kandidaten
- Gleiche Kandidaten → gleicher Score
- Gleicher Score → gleiche Rangfolge
Damit unterscheidet sich der SearchService fundamental von probabilistischen oder modellgetriebenen Suchsystemen, bei denen Relevanz als emergente Eigenschaft entsteht.
Im vorliegenden System ist Relevanz hingegen das Ergebnis einer expliziten, nachvollziehbaren Rechenvorschrift.
4. Explainability als architektonische Eigenschaft
Erklärbarkeit ist im SearchService kein nachträgliches UI-Feature, sondern eine direkte Folge der Architektur.
Da jede Pipeline-Stufe klar definiert ist, kann für jedes Ergebnis rekonstruiert werden:
- warum es überhaupt Kandidat wurde
- welche Suchbegriffe es gematcht hat
- welche Regel welchen Score-Beitrag geliefert hat
Damit erfüllt die Architektur zentrale Anforderungen erklärbarer Informationssysteme, wie sie in sensiblen Domänen (Medizin, Ernährung, Entscheidungsunterstützung) gefordert werden.
Architektur ist hier kein Implementierungsdetail, sondern der primäre Träger von Erklärbarkeit.
Die Methode norm() stellt sicher, dass alle Texte
auf eine vergleichbare Ebene gebracht werden.
- UTF-8-sicher
- Umlaute → ASCII (ä → ae)
- Entfernung von Sonderzeichen
- Vereinheitlichung von Whitespace
➜ Voraussetzung für deterministische und reproduzierbare Scores.
Normalisierung als formale Voraussetzung deterministischer Informationsverarbeitung
Die Normalisierung textueller Eingaben stellt in erklärbaren Information-Retrieval-Systemen keinen optionalen Vorverarbeitungsschritt dar, sondern bildet die formale Grundlage sämtlicher Vergleichs-, Matching- und Bewertungsoperationen.
Die im SearchService implementierte Methode norm() kann
formal als Abbildung auf der Menge aller endlichen Zeichenketten beschrieben werden:
Dabei bezeichnet \( \Sigma \) ein endliches Alphabet, \( \Sigma^\* \) die Menge aller endlichen Zeichenketten über diesem Alphabet (Kleene-Abschluss).
1. Ausgangsproblem: Heterogene Textrepräsentationen
Natürliche Sprache ist inhärent variabel. Ohne explizite Normalisierung entstehen bereits auf der String-Ebene Unterschiede, die keinerlei semantische Relevanz besitzen:
- Groß- vs. Kleinschreibung
- Unicode-Normalformen (z. B. „ä“ vs. „ä“)
- Diakritische Zeichen
- Interpunktion und Sonderzeichen
- inkonsistenter Whitespace
In einem deterministischen Suchsystem würden diese Unterschiede zu nicht erklärbaren Abweichungen im Matching- und Scoring-Verhalten führen und damit die Nachvollziehbarkeit des Systems untergraben.
2. Formale Eigenschaften der Normalisierungsfunktion
Die Normalisierungsfunktion des SearchService erfüllt zentrale funktionale Eigenschaften, die sie für den Einsatz in wissenschaftlich nachvollziehbaren Systemen qualifizieren:
-
Determinismus
Für alle \( x \in \Sigma^\* \) gilt:$$ \mathrm{norm}(x) = \mathrm{norm}(x) $$ -
Idempotenz
Mehrfache Anwendung verändert das Ergebnis nicht:$$ \mathrm{norm}(\mathrm{norm}(x)) = \mathrm{norm}(x) $$ -
Kontextfreiheit
Die Abbildung ist unabhängig von externem Zustand, Konfiguration oder Aufrufkontext.
Diese Eigenschaften garantieren, dass jede nachgelagerte Vergleichs- oder Bewertungsoperation auf einer stabilen und wohldefinierten Repräsentation basiert.
3. Konkrete Transformationsschritte
Die im SearchService implementierte Normalisierung umfasst unter anderem:
- UTF-8-sichere Kleinschreibung
- Transliteration sprachspezifischer Zeichen (ä → ae, ß → ss)
- Eliminierung nicht-alphanumerischer Zeichen
- Reduktion multipler Whitespaces auf einfache Trennzeichen
Wichtiges Designprinzip:
Alle textbasierten Operationen erfolgen ausschließlich auf
normalisierten Repräsentationen.
4. Normalisierung als Voraussetzung für Vergleichsoperationen
Sämtliche Vergleichs- und Distanzoperationen im SearchService setzen normalisierte Eingaben voraus:
- Label-Vergleiche
- Token-Matching
- Substring-Prüfungen
- Levenshtein-Distanzen
Formal bedeutet dies:
Dadurch wird ausgeschlossen, dass Unterschiede in der Eingaberepräsentation unbeabsichtigt in die Relevanzbewertung einfließen.
5. Reproduzierbarkeit und wissenschaftliche Nachvollziehbarkeit
Reproduzierbarkeit stellt ein zentrales Qualitätskriterium akademischer Systeme dar.
Die explizite Normalisierung gewährleistet:
- identische Scores für identische Anfragen
- plattform- und encodingunabhängiges Verhalten
- vollständige Rekonstruierbarkeit von Ranking-Entscheidungen
Dies ist insbesondere relevant für:
- systematische Evaluation
- Debugging und Fehleranalyse
- regulatorische Dokumentation
- didaktische Vermittlung algorithmischer Entscheidungen
Normalisierung fungiert im SearchService nicht als technische Hilfsroutine, sondern als formaler Garant für Systemintegrität.
Die KeyMap erlaubt natürliche Sprache, Abkürzungen und Fachterminologie bei gleichzeitig konsistenter Filterlogik.
Die KeyMap als semantische Abbildungsfunktion zwischen Benutzer- und Systemebene
Die KeyMap stellt im SearchService ein zentrales Bindeglied zwischen natürlicher Sprache und internem Datenmodell dar. Sie fungiert als explizite, deterministische Übersetzungsfunktion zwischen benutzerzentrierten Suchbegriffen und kanonischen Systemschlüsseln.
Im Gegensatz zu impliziten oder statistischen Mapping-Ansätzen wird diese Zuordnung vollständig regelbasiert und transparent implementiert.
1. Formale Definition
Formal lässt sich die KeyMap als partielle Funktion definieren:
wobei:
- Σ* die Menge aller normalisierten Zeichenketten darstellt
- K die endliche Menge kanonischer Systemschlüssel (z. B.
kalium_mg) - die Abbildung nicht total ist (nicht jeder Begriff ist mapbar)
Wichtig: Die KeyMap ist bewusst nicht invertierbar – mehrere Alias-Begriffe können auf denselben kanonischen Schlüssel zeigen.
2. Motivation: Entkopplung von Sprache und Datenmodell
In vielen Suchsystemen sind Filterparameter direkt an interne Feldnamen oder technische APIs gebunden. Dies führt zu einer kognitiven Überforderung der Nutzer:innen und zu fragiler UX.
Die KeyMap löst dieses Problem durch eine explizite Abstraktionsschicht:
- Benutzer:innen formulieren Anfragen in natürlicher Sprache
- das System übersetzt diese deterministisch
- die interne Logik bleibt vollständig stabil
Dadurch wird die Benutzeroberfläche von der internen Datenrepräsentation entkoppelt.
3. Eigenschaften der KeyMap
- Deterministisch – identische Eingaben erzeugen identische Zuordnungen
- Kontextfrei – keine Abhängigkeit vom Suchkontext oder Ranking
- Explizit – jede Zuordnung ist im Code nachvollziehbar definiert
- Erweiterbar – neue Aliase können ohne Seiteneffekte ergänzt werden
- Auditierbar – vollständig prüfbar für regulatorische Kontexte
Diese Eigenschaften sind entscheidend für medizinische und ernährungsbezogene Anwendungen, in denen implizite Bedeutungsverschiebungen nicht akzeptabel sind.
4. Abgrenzung zu impliziten Mapping-Ansätzen
In Machine-Learning-basierten Suchsystemen entstehen semantische Zuordnungen häufig implizit (z. B. durch Embeddings oder Vektorraumnähe).
Diese Verfahren liefern zwar flexible Assoziationen, sind jedoch:
- nicht deterministisch erklärbar
- nicht reproduzierbar im strengen Sinn
- für Endnutzer:innen nicht transparent
- regulatorisch schwer belegbar
Der SearchService entscheidet sich bewusst gegen diese Intransparenz und implementiert mit der KeyMap eine regelbasierte semantische Kontrolle.
5. Rolle der KeyMap im Gesamtsystem
Die KeyMap ist kein isoliertes Feature, sondern ein systemtragendes Element:
- sie ermöglicht robuste Filterinterpretation
- sie stabilisiert die Scoring-Pipeline
- sie erhöht die Erklärbarkeit der Ergebnisse
- sie verhindert semantische Drift
Die KeyMap ist damit nicht nur ein Komfortmerkmal, sondern ein formaler Garant für semantische Konsistenz.
Die Matching-Logik des SearchService stellt eine harte, boolesche Filterstufe dar, die der eigentlichen Relevanzbewertung strikt vorgeschaltet ist.
Die Fehlertoleranz im Fuzzy-Matching ist dabei nicht statisch, sondern adaptiv an die Länge des Suchbegriffs gekoppelt. Kurze Begriffe werden sehr streng geprüft, längere Begriffe erlauben kontrollierte Abweichungen.
Die zentrale Aufgabe dieser Stufe ist es nicht, Relevanz zu graduieren, sondern eindeutig zu entscheiden, ob ein Dokument überhaupt als Kandidat für das Ranking zulässig ist.
- keine Score-Kompensation
- keine probabilistische Abschwächung
- keine impliziten Heuristiken
➜ Besonders relevant für medizinische, ernährungsbezogene und regulatorisch sensible Suchanwendungen.
Deterministisches Term-Matching als boolesche Filterebene
Determinismus bedeutet in diesem Kontext regelbasierte Vorhersagbarkeit, nicht notwendigerweise konstante Parameter. Die adaptive Fehlertoleranz folgt festen, konfigurierten Regeln und ist daher vollständig reproduzierbar und auditierbar.
Die Matching-Stufe entscheidet ausschließlich darüber, ob ein Dokument d die notwendigen semantischen Bedingungen erfüllt, um in die nachgelagerte Scoring-Phase aufgenommen zu werden.
1. Formale Problemstellung
Gegeben sei eine Suchanfrage als endliche Menge normalisierter Suchbegriffe:
sowie ein Dokument d mit folgenden textuellen Repräsentationen:
- Label
- Tokens
Erfüllt Dokument d die notwendigen semantischen Bedingungen, um für die Anfrage Q zulässig zu sein?
2. Default-Verhalten: Implizite AND-Semantik
Ohne explizite logische Operatoren interpretiert der SearchService mehrere Suchbegriffe stets als logische Konjunktion (AND).
Ein Dokument wird nur dann akzeptiert, wenn jeder einzelne Suchbegriff mindestens einmal erfolgreich gematcht wird.
Diese AND-Semantik ist der deterministische Default-Modus des SearchService.
2.1 Effektive Suchbegriffe & leere Termräume
Die AND-Semantik bezieht sich auf die Menge der effektiv im Index belegbaren Suchbegriffe.
Suchbegriffe, für die keinerlei Kandidaten im Index existieren, werden nicht als harte Ausschlussbedingung interpretiert. Ziel ist es, vollständige Leerausgaben zu vermeiden, wenn einzelne Begriffe aktuell nicht im Datenbestand vorkommen.
Die AND-Semantik wird ausschließlich über die Menge \( Q_{\mathrm{eff}} \) angewendet.
Dadurch bleibt das System robust gegenüber unvollständigen oder im Index noch nicht vertretenen Begriffen.
🔎 Beispiel: „Apfel, Zimt“
| Dokument | Apfel | Zimt | Ergebnis |
|---|---|---|---|
| Apfel mit Zimt | ✔ | ✔ | ✅ Treffer |
| Apfelmus | ✔ | – | ✅ Treffer |
| Zimtstange | – | ✔ | kein Kandidat |
➜ Die AND-Semantik greift ausschließlich über effektiv belegte Suchbegriffe.
3. OR-Semantik (konzeptionell)
Die folgende Darstellung beschreibt die konzeptionelle Zielarchitektur. Eine explizite OR-Auswertung ist aktuell nicht Bestandteil des produktiven Query-Parsings.
4. Negation / NOT (konzeptionell)
Negationen sind als restriktive Operatoren geplant, werden derzeit jedoch nicht explizit geparst.
5. Architektonische Konsequenz
Matching entscheidet über Zulässigkeit –
Scoring entscheidet über Rangfolge.
Diese strikte Trennung verhindert, dass schwache Teiltreffer durch hohe Scores andere Suchbegriffe semantisch überdecken.
Die Matching-Logik ist damit kein technischer Zufall, sondern eine bewusst domänenspezifische Designentscheidung.
Der Scoring-Algorithmus des SearchService ist strikt additiv, deterministisch und vollständig regelbasiert.
Er kommt ausschließlich nach erfolgreichem Matching zum Einsatz und entscheidet nicht über die Zulässigkeit eines Dokuments, sondern ausschließlich über dessen Rangfolge.
Grundprinzip:
Matching filtert – Scoring sortiert.
1. Additives Gewichtungsmodell
Der Gesamtscore eines Dokuments ergibt sich als Summe wohldefinierter Einzelbeiträge aus verschiedenen Trefferarten.
| Trefferart | Gewicht |
|---|---|
| Exaktes Label | +50 |
| Label beginnt mit | +20 |
| Label enthält | +10 |
| Exaktes Token | +25 |
| Token beginnt mit | +6 |
| Token enthält | +2 |
➜ Jeder Treffer trägt einen klar definierten, isoliert erklärbaren Score-Beitrag bei.
Deterministisches Scoring als additive Bewertungsfunktion
Der Scoring-Schritt ordnet zulässige Dokumente entlang einer ordinalen Rangskala. Er trifft keine Ja/Nein-Entscheidungen, sondern bewertet ausschließlich relative Relevanz.
1. Formale Definition
Formal lässt sich der Score eines Dokuments d für eine Suchanfrage Q wie folgt beschreiben:
Dabei bezeichnet:
- \( Q \): Menge der effektiven Suchbegriffe
- \( K \): Menge definierter Trefferarten
- \( w_k \): festes Gewicht der Trefferart
- \( \mathbf{1}_{k} \): Indikatorfunktion (Treffer ja/nein)
Es existieren keine negativen Gewichte und keine nichtlinearen Kombinationen.
2. Trefferkanäle und Redundanz
Jeder Suchbegriff wird über mehrere, bewusst redundant ausgelegte Kanäle bewertet:
- Label-basierte Treffer
- Token-basierte Treffer
Diese Redundanz erhöht die Robustheit gegenüber sprachlicher Variation, ohne semantische Beliebigkeit einzuführen.
Wichtig: Mehrere Trefferarten können gleichzeitig auf denselben Suchbegriff wirken.
3. Optionaler Fuzzy-Boost
Optional kann ein Fuzzy-Boost aktiviert werden, der auf Basis einer adaptiven Levenshtein-Distanz zusätzliche Punkte vergibt. Die maximale Distanz ist abhängig von der Wortlänge und dem Suchkontext (z. B. Suggest vs. Suche).
mit:
- \( \mathrm{lev} \): Levenshtein-Distanz
- \( B \): konfigurierbarer Maximalbonus
Der Fuzzy-Boost ist vollständig konfigurierbar und kann auf direkte Treffer beschränkt werden.
4. Score-Normalisierung (0–100)
Zur Darstellung im Frontend werden Rohscores auf eine normierte Skala abgebildet:
Diese Normalisierung beeinflusst ausschließlich die Darstellung, nicht die Rangfolge.
5. Explainability pro Suchbegriff
Der Score wird intern zusätzlich pro Suchbegriff aufgeschlüsselt.
➜ Jeder Suchbegriff liefert einen isoliert erklärbaren Beitrag zur Gesamtbewertung.
6. Architektonische Konsequenz
Scoring ist erklärbar, weil es additiv ist –
und vertrauenswürdig, weil es deterministisch bleibt.
Der Scoring-Algorithmus verzichtet bewusst auf statistische Modelle, Black-Box-Gewichtungen oder implizite Korrelationen.
Relevanz entsteht hier nicht durch Training, sondern durch nachvollziehbare Regeln.
Eine zentrale Besonderheit des SearchService ist die Fähigkeit, Relevanz nicht nur global, sondern pro Suchbegriff separat erklärbar zu machen.
Jeder Suchbegriff liefert einen eigenen, isolierten Beitrag zum Gesamtscore – vollständig nachvollziehbar und maschinenlesbar.
Explainability ist hier kein UI-Zusatz, sondern ein strukturelles Ergebnis der Architektur.
1. Struktur des Explainability-Outputs
Für jedes Suchergebnis wird zusätzlich zum Gesamtscore eine per-Term-Aufschlüsselung erzeugt:
match: normalisierter Gesamtscore (0–100)match_terms: Score-Beitrag pro Suchbegriffmatched_terms: effektiv gematchte Begriffe
➜ Die Daten sind vollständig frontend- und auditfähig, ohne zusätzliche Berechnungen.
Explainability durch additive, termweise Relevanzmodellierung
Klassische Suchsysteme liefern typischerweise einen einzelnen, undurchsichtigen Relevanzwert. Der SearchService geht bewusst einen anderen Weg.
1. Formale Idee
Der Gesamtscore eines Dokuments entsteht als Summe unabhängiger Beiträge einzelner Suchbegriffe.
Jeder Term \( q \) liefert einen eigenen, rekonstruierbaren Beitrag.
2. Praktisches Beispiel
Suchanfrage:
| Suchbegriff | Score | Interpretation |
|---|---|---|
| Kaffee | 82 | starker Treffer |
| Apfel | 0 | kein semantischer Bezug |
Das Dokument ist zulässig, weil das Matching erfolgreich war, wird aber ausschließlich durch „Kaffee“ getragen.
3. Abgrenzung zu Black-Box-Erklärungen
Viele moderne Suchsysteme versuchen, Erklärbarkeit nachträglich zu approximieren (z. B. Feature-Importance, SHAP, Attention-Maps).
Der SearchService benötigt diese Techniken nicht, da Relevanz bereits konstruktiv erklärbar ist.
- keine nachträgliche Approximation
- keine probabilistische Interpretation
- keine Modellinferenz
4. Nutzen für UX, Debugging & Regulierung
Die termweise Explainability des SearchService ermöglicht eine direkte, nachvollziehbare Übersetzung algorithmischer Entscheidungen in benutzerverständliche UI-Komponenten.
- UI-Overlays („Warum sehe ich dieses Ergebnis?“)
- visuelle Hervorhebung gematchter Begriffe und Einflussfaktoren
- gezieltes Debugging einzelner Score-Beiträge
- auditierbare Entscheidungsprotokolle auf Nährstoff- und Regel-Ebene
Besonders in medizinischen und ernährungsbezogenen Anwendungen ist diese Transparenz entscheidend für Nutzervertrauen, fachliche Korrektheit und regulatorische Akzeptanz.
Dieses Overlay ist keine nachträgliche Visualisierung, sondern eine direkte Projektion der internen Datenstruktur (Scoring-Regeln, Schwellenwerte, Tageslimits).
Die Benutzeroberfläche erklärt keine Entscheidungen – sie zeigt deterministische Entscheidungen an, die bereits vollständig im System modelliert sind.
5. Architektonische Konsequenz
Explainability ist kein Feature –
sie ist eine direkte Folge der Algorithmik.
Durch additive Scores, striktes Matching und per-Term-Aufschlüsselung entsteht ein Suchsystem, dessen Entscheidungen vollständig rekonstruiert werden können.
Damit erfüllt der SearchService zentrale Anforderungen erklärbarer Informationssysteme im akademischen Sinne.
Die grafische Benutzeroberfläche des SearchService ist nicht als rein visuelle Präsentationsschicht konzipiert, sondern als integraler Bestandteil der erklärbaren Systemarchitektur.
Sie übernimmt eine aktive Rolle bei der Übersetzung algorithmischer, regelbasierter Bewertungslogik in eine für Nutzer:innen nachvollziehbare Entscheidungsgrundlage. In medizinischen und ernährungsbezogenen Anwendungskontexten entsteht Vertrauen nicht durch visuelle Dominanz oder Vereinfachung, sondern durch Transparenz, Zurückhaltung und erklärbare Struktur.
Jede UI-Komponente erfüllt dabei eine klar abgegrenzte kommunikative Funktion:
- farbcodierte Nährwert-Pills transportieren qualitative Einschätzungen ohne numerische Überforderung
- der aggregierte Bewertungs-Daumen verdichtet komplexe Regelwerke zu einer sofort erfassbaren Orientierungsebene
- Tooltips, Hover-Zustände und Detailansichten ermöglichen jederzeit eine vertiefende, kontextabhängige Erklärung
Zentrale Entwurfsprinzipien der Oberfläche sind:
- progressive Offenlegung statt Informationsüberladung
- keine impliziten Entscheidungen ohne erklärenden Kontext
- klare Trennung von Orientierungsebene (Scanbarkeit) und Analyseebene (Details)
- bewusster Verzicht auf alarmistische oder manipulative UI-Signale
Die Benutzeroberfläche trifft damit keine Entscheidungen für die Nutzer:innen, sondern unterstützt sie dabei, informierte, nachvollziehbare und situationsabhängige Entscheidungen selbst zu treffen.
Benutzeroberfläche als kognitive Vermittlungsschicht
Aus Sicht der Human-Computer-Interaction (HCI) fungiert die Benutzeroberfläche des SearchService als kognitive Vermittlungsschicht zwischen deterministischer Algorithmik und menschlicher Entscheidungsfindung.
Die Oberfläche übersetzt formale Regeln, Schwellenwerte und Scores nicht direkt in numerische Ausgaben, sondern in wahrnehmbare, vergleichbare und erklärbare Signale. Damit übernimmt sie eine aktive Rolle im Entscheidungsprozess, ohne diesen zu steuern.
1. Qualitative Codierung statt numerischer Überlastung
Zahlreiche Studien aus der kognitiven Psychologie zeigen, dass rein numerische Information bei komplexen Entscheidungen zu Überforderung, Heuristiken und Fehlinterpretationen führt.
Der SearchService begegnet diesem Effekt durch eine bewusste qualitative Codierung:
- Farben wirken als präattentive Orientierungssignale
- Symbole reduzieren kognitive Last
- Details bleiben jederzeit explizit abrufbar
Wichtig: Farben ersetzen keine Information – sie strukturieren sie.
2. Progressive Offenlegung als Entwurfsprinzip
Die Oberfläche folgt konsequent dem Prinzip der progressiven Offenlegung:
Erst Orientierung, dann Analyse – niemals beides gleichzeitig.
Nutzer:innen erhalten zunächst eine grobe Einschätzung und können bei Bedarf gezielt in tiefere Erklärungsebenen wechseln. Dies reduziert Entscheidungsstress und erhöht nachweislich das Vertrauen in das System.
3. Aggregation ohne Intransparenz
Der aggregierte Bewertungs-Daumen stellt eine kognitive Abkürzung dar, ohne eine Blackbox zu erzeugen. Seine Aussage ist jederzeit auflösbar und erklärbar.
Aggregation dient hier nicht der Vereinfachung von Wahrheit, sondern der Reduktion von Einstiegshürden.
4. Verzicht auf manipulative Interaktionsmuster
Der SearchService verzichtet bewusst auf gängige, aber problematische UI-Muster:
- keine alarmistischen Warnfarben
- keine emotionalisierenden Call-to-Actions
- keine gamifizierten Belohnungsmechaniken
Dieser Verzicht ist eine ethische Designentscheidung. In medizinischen Kontexten kann Interaktionsdesign selbst zum Interventionsfaktor werden.
5. Favoriten als kognitiver Arbeitsraum
Das Favoriten-Konzept ist nicht als soziale oder algorithmische Bewertungsfunktion gedacht, sondern als persönlicher Arbeits- und Denkraum.
Durch lokale Speicherung, fehlende Bewertungshierarchien und den Verzicht auf Vergleichsdynamiken unterstützt es individuelle Entscheidungsprozesse statt sie zu normieren.
Die Benutzeroberfläche erklärt keine Entscheidungen – sie macht deterministische Entscheidungen sichtbar.
- klassisches, regelbasiertes Information Retrieval
- sauber getrennte Matching-, Filter- und Scoring-Pipeline
- vollständig deterministische und reproduzierbare Algorithmik
- keine statistische oder neuronale Blackbox
- Explainability als systemisches Designziel
- direkte Praxisrelevanz im nephrologischen Kontext
Nach Einschätzung eines langjährig tätigen Nephrologen im Dialyseumfeld existiert derzeit kein vergleichbares System, das in dieser Form:
- medizinisch relevante Nährstoffbewertung
- deterministische Such- und Filterlogik
- pro-Suchbegriff-Erklärbarkeit
- und vollständig transparente Bewertungsmodelle
in einem integrierten, auditierbaren Gesamtsystem vereint.
Insbesondere die Kombination aus erklärbarer Suche, nachvollziehbarer Nährstoffbewertung und patientenzentrierter UX stellt nach aktuellem Kenntnisstand eine neuartige systemische Lösung dar, die über klassische Lebensmittel- oder Nährwertdatenbanken deutlich hinausgeht.
Das System versteht sich nicht als Entscheidungsersatz, sondern als transparente Entscheidungsunterstützung für Patient:innen, Fachpersonal und beratende Instanzen.
Wenn Sie sich für diese Arbeit interessieren – sei es aus fachlichem, medizinischem oder technischem Blickwinkel – freue ich mich über jede Form der Rückmeldung.
Ob wertschätzendes Feedback, konstruktive Kritik, fachlicher Austausch, ideelle Unterstützung, eigene Mitarbeit oder auch eine finanzielle Honorierung: Jede Nachricht ist willkommen und trägt zur Weiterentwicklung des Projekts bei.
Besonders schätze ich den offenen Dialog – denn selbst kritische Hinweise sind wertvoller als Schweigen.