Typische Anfrage — interner Auskunftsdienst, von der Idee zur Einordnung
So kommen Anfragen bei uns an: bereits als Lösung formuliert. Dieser Eintrag steht stellvertretend für einen Anfragetyp, den wir regelmässig sehen — eine Organisation hat Fachwissen, das über Jahre in internen Ablagen gewachsen ist, und wünscht sich einen Chatbot darauf. Hier war es eine Schweizer Forschungsinstitution mit einem fachlichen Auskunftsdienst. Was folgt, ist unser Vorgehen: welche Fragen wir zuerst stellen, warum am Ende doch ein RAG-System passte, und an welcher Stelle wir dem Kunden widersprochen haben.
Die Anfrage, wie sie ankam
Rund zehn Personen beantworten fachliche Anfragen und recherchieren dafür in intern über Jahre gewachsenen Notizsammlungen. Wer neu dazustösst, braucht lange, bis er weiss, wo etwas steht. Der Wunsch war formuliert als «ein Chatbot, der Fragen in natürlicher Sprache beantwortet, mit Quellenangabe, mindestens 90 Prozent korrekt, ausschliesslich auf Schweizer Infrastruktur». Wie fast jede Anfrage enthielt sie damit bereits eine Lösung — und die eigentliche Frage lautete: wie kommen zehn Fachleute schneller an Wissen, das im Haus schon vorhanden ist?
Was wir zuerst geprüft haben
Drei Fragen, bevor über Architektur gesprochen wird. Erstens: Welche Fragen werden tatsächlich gestellt — und wie viele davon brauchen eine formulierte Antwort statt nur einen Fundort? Zweitens: Wie ist das Material beschaffen? Fliesstext ohne belastbare Struktur verhält sich anders als eine gepflegte Datenbank. Drittens: Gibt es Fragen nach Beziehungen und Mengen, die eine Textsuche grundsätzlich nicht beantworten kann, weil sie nicht zählen kann? Genau diese Klärung ist der Grund, warum Schritt eins der Offerte ein Requirements- und Architektur-Workshop ist und kein Prototyp.
Warum die einfacheren Wege hier nicht reichen
Eine bessere Verschlagwortung allein hilft nicht, weil die Fragen fachlich umschrieben ankommen und nicht mit den Begriffen der Notizen übereinstimmen. Eine reine Volltextsuche scheitert an derselben Stelle. Eine hybride Suche käme deutlich weiter und bleibt deshalb im Vorschlag als Fundament enthalten — sie ist die Schicht, auf der das Ganze steht. Der Ausschlag für die generierte Antwort kam von der Beschaffenheit des Materials: die Antwort auf eine typische Fachfrage steht selten an einer Stelle, sondern verteilt über mehrere Notizen, die zusammengeführt werden müssen. Ein Wissensgraph wäre der präzisere Weg, setzt aber eine Strukturierung voraus, die es nicht gibt und deren Aufbau ein eigenes Projekt wäre.
Wo wir widersprochen haben
Der Kunde nannte mindestens 90 Prozent korrekte Antworten als Erfolgskriterium für den Piloten. Wir haben in der Offerte schriftlich festgehalten, dass diese Schwelle nach dem ersten Funktionsnachweis nicht verlässlich erreichbar ist, sondern erst nach der Ausbaustufe — und dass sie von der gemeinsam gewählten, in der Schweiz betreibbaren Modellfamilie abhängt. Dazu die unbequemere Hälfte: Was «korrekt» überhaupt heisst, wird vor Projektstart gemeinsam definiert, gemessen wird gegen einen vorab gelieferten Katalog von zwanzig bis vierzig Testfragen mit Musterantworten, in einem moderierten Termin, mit einer eingerechneten Nachbesserungsschleife. Eine Zahl zu bestätigen, die man später nicht belegen kann, ist keine Kundenfreundlichkeit, sondern eine verschobene Auseinandersetzung.
Was bewusst nicht im Piloten steckt
Ablösung der bestehenden Notizsammlung durch eine zentrale Wissensdatenbank, automatischer Rücklauf von Korrekturen, Bereitstellung für Externe, erweiterte Schutzschicht gegen Prompt-Injection, Hochverfügbarkeit mit Wartungsvereinbarung, Single Sign-on, laufender Abgleich neuer Inhalte und weitere Sprachen. Ebenfalls nicht enthalten: eine Feinabstimmung des Sprachmodells — sie verändert Stil und Format, aber nicht das Auffinden von Wissen, und wäre hier reine Kostenstelle. Alle Punkte sind architektonisch mitgedacht. Ein Pilot, der alles enthält, ist kein Pilot mehr, sondern ein Projekt ohne Ausstiegspunkt.