Ausgewählte Projekte

Lässt man ein LLM die Skills einfach benennen, entstehen plausible, aber ad hoc gewählte Bezeichnungen: Derselbe Skill heißt von Arbeitspaket zu Arbeitspaket anders, und die Ergebnisse lassen sich nicht vergleichen. Die Zuordnung zu einer festen Taxonomie vermeidet das, aber dann muss der Service unter rund 13.900 ESCO-Skills die passenden Einträge finden, deren formale Bezeichnungen selten dem Wortlaut eines Tickets entsprechen.

• Analyse und Anforderungen gemeinsam mit dem Produktteam
• Architektur einer agentischen Extraktionsschleife
• Prototyping der Prompt- und Tool-Strategie
• Produktionsreifer API-Service mit automatisierten Tests
• Containerisierte Auslieferung mit CI sowie Übergabedokumentation

• Ein LangGraph-Agent arbeitet mit vier Tools: Taxonomie durchsuchen, Hierarchie erkunden, Skill verifizieren und Ergebnis übermitteln. Jeder Skill wird vor der Rückgabe gegen einen lokalen Volltextindex geprüft, sodass der Service keine unverifizierbaren Skills zurückgibt.
• Der Prompt übersetzt Tech-Jargon in formale Taxonomiebegriffe, bewertet die Relevanz, schützt nicht vertrauenswürdige Eingaben gegen Prompt-Injection und arbeitet deterministisch für reproduzierbare Ergebnisse.
• Schutzmechanismen begrenzen Tool-Aufrufe und Gesamtlaufzeit und erkennen Schleifen.
• Eine asynchrone Job-API unterstützt Einreichen, Abfragen, Abrufen und Bewerten von Ergebnissen. Webhook-Callbacks nutzen Token-Authentifizierung, Wiederholungen mit Backoff und SSRF-Schutz.
• Die Härtung umfasst Token-Authentifizierung, Rate-Limiting, Security-Header, Container ohne Root-Rechte und Datenbankrollen mit minimalen Rechten. LiteLLM hält den Service unabhängig von OpenAI-, Gemini- und Anthropic-Modellen.

Ein sicherer, beobachtbarer Service, der unstrukturierte Arbeitsbeschreibungen in konsistente, maschinenlesbare Skill-Profile verwandelt, mit Taxonomie-Link, Hierarchiepfad und Relevanzwert für jeden Skill.

Duplikate sind selten gleich formuliert: Ein Ticket lautet vielleicht „Dashboard zur Kundenabwanderung“, ein anderes, Monate später, „Auswertung, welche Kunden ihre Verträge kündigen“. Ein reiner Textabgleich übersieht solche Paare. Ein LLM erkennt sie, aber es zu jedem Paar zu befragen, ist viel zu langsam und zu teuer: Ein einzelnes Arbeitspaket zu prüfen bedeutet Zehntausende Vergleiche, einen ganzen Backlog zu prüfen Hunderte Millionen.

• Methodenrecherche in der Entity-Resolution-Literatur
• Architektur einer dreistufigen Erkennungskaskade
• Prototyping und Kalibrierung der Schwellenwerte
• Produktionsreifer API-Service mit automatisierten Tests
• Containerisierte Auslieferung mit CI sowie Übergabedokumentation

• Stufe 1 grenzt die Suche ein. Fünf schnelle Abfragen laufen parallel und liefern höchstens 50 Kandidaten: identischer Text, Stichwortsuche, ähnliche Schreibweise, Nachbarn in der Projekthierarchie und Einträge mit ähnlicher Bedeutung (Embeddings). Die Suche nach Bedeutung findet auch Duplikate, die kein einziges Wort gemeinsam haben.
• Stufe 2 bewertet jeden Kandidaten. Titelähnlichkeit, gemeinsame Schlüsselbegriffe, inhaltliche Ähnlichkeit und die Position in der Projekthierarchie werden zu einem Wert zusammengefasst. Eindeutige Treffer werden übernommen, eindeutige Nicht-Treffer ohne weitere Kosten verworfen.
• Stufe 3 gibt nur die unsicheren Fälle an ein LLM, das sie alle in einem einzigen Aufruf prüft und bei Bedarf den vollständigen Text eines Arbeitspakets liest. Sein Urteil wird mit dem Wert aus Stufe 2 verrechnet.
• Alle Teilwerte werden gespeichert, sodass sich die Schwellenwerte später anpassen lassen, ohne die Erkennung erneut auszuführen.

Ein Produktionsservice, der Duplikate auch bei unterschiedlicher Formulierung findet, mit höchstens einem LLM-Aufruf pro geprüftem Arbeitspaket.

Die klassische Lösung ist ein Filterformular mit Dutzenden Feldern, etwa maximale Gruppengröße oder Entfernung von einer Stadt, die jeweils direkt in der Datenbank abgefragt werden. Das ist präzise, entspricht aber nicht der Art, wie Menschen beschreiben, was sie wollen, und die Plattform wollte kein solches Formular. Der übliche LLM-Ansatz, Retrieval-Augmented Generation (RAG), versteht freien Text, behandelt Fakten aber als Ähnlichkeiten: Für eine Gruppe von 21 Personen wirkt eine Aktivität für bis zu 20 Personen wie ein guter Treffer, obwohl sie gar nicht in Frage kommt. Strikte Filter scheitern in die andere Richtung: Ein Event 101 km vom Büro entfernt ist für „höchstens 100 km“ ein guter Treffer, ein Filter verwirft es trotzdem. Die Suche muss harte von ungefähren Grenzen unterscheiden, ohne dass man eigens angeben muss, welche welche ist. Außerdem musste der Entwurf ohne Vektordatenbank und ohne Neuarchitektur auskommen, mit der bestehenden relationalen Datenbank als maßgeblicher Datenquelle und strukturierten Daten als Ausgabe.

• Stakeholder-Analyse und Klärung der Rahmenbedingungen
• Drei Architekturen im Detail entworfen und verglichen
• API-Verträge, Sicherheitsanalyse und Modellauswahl
• Token-Budgets, Erfolgskriterien und mögliche Tech-Stacks
• Eine empfohlene Ausgangsvariante. Prototypen oder Produktionscode waren nicht Teil dieses Projekts.

• Alle drei Entwürfe lassen das LLM die Anfrage in Datenbankfilter für die harten Fakten übersetzen und die übrigen Angebote danach ordnen, wie gut sie zu den Wünschen passen. Weil das LLM die Anfrage im Zusammenhang liest, erkennt es, welche Grenzen ein Angebot ausschließen und welche nur ungefähr gemeint sind.
• Freitext-Agent: eine einzige Freitextanfrage, ein LLM mit typisiertem Such-Tool, das eine direkte SQL-Abfrage ausführt, und ein zweistufiges Re-Ranking, das zuerst Titel und Tags sichtet und dann die vollständigen Beschreibungen der besten Kandidaten liest.
• Geführter Ablauf in Schritten: bei jedem Schritt klicken oder tippen, das LLM wandelt Antworten in strukturierte Filter um, eine Live-Trefferzahl aktualisiert sich nach jedem Schritt, und das Re-Ranking läuft nur auf der finalen Auswahl.
• Zustandsloser, frontendgesteuerter Ablauf: dieselbe Nutzererfahrung, wobei das Frontend den Zustand hält und drei reine Backend-Endpunkte bedient. Das beseitigt das Risiko manipulierter Zustände und halbiert ungefähr den Token-Verbrauch.
• Zu jedem Entwurf gehörten Request-Lebenszyklen, JSON-Antwortschemas, Maßnahmen gegen Prompt-Injection, Rate-Limiting und eine Modellwahl für jeden Aufruf.
• Empfehlung: mit dem geführten Ablauf starten, der dem bestehenden Erlebnis am nächsten kommt und das geringste Risiko hat.

Das Team konnte einen Ansatz wählen und ihn auf dem bestehenden Stack umsetzen, ohne Vektordatenbank und mit einem klaren Sicherheits- und Kostenprofil für jede Option.