Was w\u00e4re, wenn Sie komplexe Machine Learning Ranking-Modelle direkt in Ihre Suchmaschine einbetten k\u00f6nnten, externe Inferenzdienste und deren damit verbundene Netzwerklatenz vollst\u00e4ndig umgehen w\u00fcrden? Genau das haben die Entwickler bei Swiggy f\u00fcr ihre Autocomplete-Vorschl\u00e4ge erreicht und sind \u00fcber statische Regeln hinausgegangen, um deutlich relevantere Ergebnisse mit Geschwindigkeiten im Sub-Millisekunden-Bereich zu liefern. Hierbei geht es nicht nur um die Generierung von AI-Code, sondern darum, grundlegend zu \u00fcberdenken, wie AI-Tools in Kernprodukterlebnisse integriert werden k\u00f6nnen, um sie schneller und intelligenter zu machen.<\/p>\n
Lange Zeit f\u00fchlte sich der Aufbau eines wirklich intelligenten Autocomplete-Systems f\u00fcr Software-Entwickler wie ein Kompromiss an. Sie konnten blitzschnelle Antworten erzielen, indem sie sich auf einfaches lexikalisches Matching und eine Reihe sorgf\u00e4ltig manuell abgestimmter, statischer Regeln verlie\u00dfen. Oder Sie konnten auf ausgefeilte Relevanz durch Machine Learning setzen, was aber normalerweise die Einf\u00fchrung zus\u00e4tzlicher Dienste, Netzwerk-Hops und den unvermeidlichen Latenz-Overhead eines externen Inferenz-Engines bedeutete. Diese Latenz ist besonders schmerzhaft f\u00fcr Autocomplete, bei dem jeder Tastendruck eine sofortige, relevante Vorschlagsliste erfordert.<\/p>\n
Dieser traditionelle Ansatz zwang Entwickler oft zu Kompromissen. Das Engineering-Team k\u00f6nnte Wochen, sogar Monate damit verbringen, Heuristik-Regeln zu verfeinern, Gewichte anzupassen und komplexe Logiken zur Behandlung von Randf\u00e4llen zu pflegen \u2013 ein fragiler und zeitaufwendiger Prozess. Wenn dann doch ein ML-Modell eingef\u00fchrt wurde, befand es sich typischerweise au\u00dferhalb der Kern-Suchmaschine, erforderte eine eigene Deployment-Pipeline, Skalierungs\u00fcberlegungen und einen API-Endpunkt. Dies f\u00fcgte erhebliche architektonische Komplexit\u00e4t hinzu und machte eine eigentlich einfache Suchanfrage oft zu einer Herausforderung f\u00fcr die Orchestrierung mehrerer Dienste.<\/p>\n
Die Auswirkung auf die t\u00e4gliche Arbeit eines Software-Entwicklers war klar: mehr Infrastruktur zu verwalten, mehr potenzielle Fehlerquellen und weniger Zeit, sich auf das Kernproblem der Relevanz zu konzentrieren.<\/p>\n
Swiggys Durchbruch umgeht dieses Dilemma vollst\u00e4ndig. Durch die Integration eines gelernten Ranking-Modells direkt in OpenSearch haben sie den traditionellen zweistufigen Prozess des \u201eAbrufcens und dann Rangierens\u201c zu einer hochoptimierten, In-Engine-Operation zusammengef\u00fchrt. Das bedeutet, dass dieselben leistungsstarken Modelle, die f\u00fcr fortschrittliches Ranking verwendet werden, jetzt zusammen mit der anf\u00e4nglichen Kandidatengenerierung innerhalb von OpenSearch selbst ausgef\u00fchrt werden k\u00f6nnen.<\/p>\n
F\u00fcr den Software-Entwickler bedeutet dies eine vereinfachte Architektur, dramatisch reduzierte Latenz und die M\u00f6glichkeit, Machine Learning-Modelle mit derselben Agilit\u00e4t zu iterieren und bereitzustellen, mit der sie m\u00f6glicherweise Suchindexkonfigurationen anwenden. Es erm\u00f6glicht ihnen, wirklich adaptive und intelligente Sucherlebnisse ohne den typischen architektonischen Ballast zu erstellen.<\/p>\n
Betrachten Sie den typischen Workflow f\u00fcr einen Software-Entwickler, der mit der Verbesserung der Autocomplete-Relevanz beauftragt ist: Bevor ML direkt in OpenSearch integriert wird: Ein Entwickler w\u00fcrde OpenSearch f\u00fcr den anf\u00e4nglichen lexikalischen Abruf konfigurieren und eine schnelle Kandidatengenerierung sicherstellen. Wenn er Machine Learning anwenden wollte, w\u00fcrde er dann einen separaten Dienst erstellen, vielleicht eine Python-Anwendung, die ein XGBoost-Modell hostet. Dieser Dienst w\u00fcrde die anf\u00e4nglichen Kandidaten erhalten, einen Feature Store f\u00fcr Echtzeit-Signale abfragen, das ML-Modell anwenden und die Ergebnisse neu rangieren, bevor er sie zur\u00fccksendet. Dieser Roundtrip, einschlie\u00dflich Netzwerklatenz und Inferenzzeit, konnte leicht 20-50 Millisekunden pro Tastendruck hinzuf\u00fcgen \u2013 genug, um sich f\u00fcr einen Benutzer tr\u00e4ge anzuf\u00fchlen. Die aufgewendete Zeit w\u00fcrde auf die Verwaltung zweier getrennter Systeme und des Netzwerkvertrags zwischen ihnen entfallen.<\/p>\n
Nach der direkten Integration von ML in OpenSearch mit LTR: Der Entwickler arbeitet immer noch co<\/p>\n