Was wäre, wenn Sie komplexe Machine Learning Ranking-Modelle direkt in Ihre Suchmaschine einbetten könnten, externe Inferenzdienste und deren damit verbundene Netzwerklatenz vollständig umgehen würden? Genau das haben die Entwickler bei Swiggy für ihre Autocomplete-Vorschläge erreicht und sind über 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 überdenken, wie AI-Tools in Kernprodukterlebnisse integriert werden können, um sie schneller und intelligenter zu machen.
Lange Zeit fühlte sich der Aufbau eines wirklich intelligenten Autocomplete-Systems für Software-Entwickler wie ein Kompromiss an. Sie konnten blitzschnelle Antworten erzielen, indem sie sich auf einfaches lexikalisches Matching und eine Reihe sorgfältig manuell abgestimmter, statischer Regeln verließen. Oder Sie konnten auf ausgefeilte Relevanz durch Machine Learning setzen, was aber normalerweise die Einführung zusätzlicher Dienste, Netzwerk-Hops und den unvermeidlichen Latenz-Overhead eines externen Inferenz-Engines bedeutete. Diese Latenz ist besonders schmerzhaft für Autocomplete, bei dem jeder Tastendruck eine sofortige, relevante Vorschlagsliste erfordert.
Dieser traditionelle Ansatz zwang Entwickler oft zu Kompromissen. Das Engineering-Team könnte Wochen, sogar Monate damit verbringen, Heuristik-Regeln zu verfeinern, Gewichte anzupassen und komplexe Logiken zur Behandlung von Randfällen zu pflegen – ein fragiler und zeitaufwendiger Prozess. Wenn dann doch ein ML-Modell eingeführt wurde, befand es sich typischerweise außerhalb der Kern-Suchmaschine, erforderte eine eigene Deployment-Pipeline, Skalierungsüberlegungen und einen API-Endpunkt. Dies fügte erhebliche architektonische Komplexität hinzu und machte eine eigentlich einfache Suchanfrage oft zu einer Herausforderung für die Orchestrierung mehrerer Dienste.
Die Auswirkung auf die tägliche Arbeit eines Software-Entwicklers war klar: mehr Infrastruktur zu verwalten, mehr potenzielle Fehlerquellen und weniger Zeit, sich auf das Kernproblem der Relevanz zu konzentrieren.
Swiggys Durchbruch umgeht dieses Dilemma vollständig. Durch die Integration eines gelernten Ranking-Modells direkt in OpenSearch haben sie den traditionellen zweistufigen Prozess des „Abrufcens und dann Rangierens“ zu einer hochoptimierten, In-Engine-Operation zusammengeführt. Das bedeutet, dass dieselben leistungsstarken Modelle, die für fortschrittliches Ranking verwendet werden, jetzt zusammen mit der anfänglichen Kandidatengenerierung innerhalb von OpenSearch selbst ausgeführt werden können.
Für den Software-Entwickler bedeutet dies eine vereinfachte Architektur, dramatisch reduzierte Latenz und die Möglichkeit, Machine Learning-Modelle mit derselben Agilität zu iterieren und bereitzustellen, mit der sie möglicherweise Suchindexkonfigurationen anwenden. Es ermöglicht ihnen, wirklich adaptive und intelligente Sucherlebnisse ohne den typischen architektonischen Ballast zu erstellen.
Betrachten Sie den typischen Workflow für einen Software-Entwickler, der mit der Verbesserung der Autocomplete-Relevanz beauftragt ist: Bevor ML direkt in OpenSearch integriert wird: Ein Entwickler würde OpenSearch für den anfänglichen lexikalischen Abruf konfigurieren und eine schnelle Kandidatengenerierung sicherstellen. Wenn er Machine Learning anwenden wollte, würde er dann einen separaten Dienst erstellen, vielleicht eine Python-Anwendung, die ein XGBoost-Modell hostet. Dieser Dienst würde die anfänglichen Kandidaten erhalten, einen Feature Store für Echtzeit-Signale abfragen, das ML-Modell anwenden und die Ergebnisse neu rangieren, bevor er sie zurücksendet. Dieser Roundtrip, einschließlich Netzwerklatenz und Inferenzzeit, konnte leicht 20-50 Millisekunden pro Tastendruck hinzufügen – genug, um sich für einen Benutzer träge anzufühlen. Die aufgewendete Zeit würde auf die Verwaltung zweier getrennter Systeme und des Netzwerkvertrags zwischen ihnen entfallen.
Nach der direkten Integration von ML in OpenSearch mit LTR: Der Entwickler arbeitet immer noch co