Die Fehlerquote sank von 10 % auf 0,01 % und LinkedIn teilte umfassend seine Erfahrungen bei der Implementierung von LLM-Anwendungen-KI-php.cn

Da die LLM-Technologie (Large-Scale Language Model) immer ausgereifter wird, haben verschiedene Branchen das Tempo der Implementierung von LLM-Anwendungen beschleunigt. Um den praktischen Anwendungseffekt von LLM zu verbessern, hat die Branche viele Anstrengungen unternommen. Kürzlich teilte das LinkedIn-Team seine wertvollen Erfahrungen bei der Entwicklung generativer KI-Produkte. Laut LinkedIn verlief die Entwicklung von Produkten auf Basis generativer KI nicht reibungslos und das Unternehmen stieß in einer Reihe von Bereichen auf Schwierigkeiten. Das Folgende ist der Originaltext des LinkedIn-Blogs. In den letzten sechs Monaten hat unser Team bei LinkedIn hart daran gearbeitet, eine neue KI-Erfahrung zu entwickeln, die versucht, die Art und Weise, wie sich unsere Mitglieder auf Stellen bewerben und professionelle Inhalte durchsuchen, neu zu gestalten. Das explosionsartige Wachstum der generativen KI lässt uns innehalten und darüber nachdenken, was heute möglich ist, was vor einem Jahr noch unmöglich war. Wir haben viele Ideen erfolglos ausprobiert und letztendlich herausgefunden, dass das Produkt wichtige Dinge benötigt, wie zum Beispiel einen schnelleren Zugriff auf Informationen, etwa um wichtige Punkte aus Beiträgen abzurufen oder über Unternehmensaktualisierungen auf dem Laufenden zu bleiben. Verknüpfen Sie die Informationspunkte, z. B. die Beurteilung Ihrer Eignung für eine Position. Holen Sie sich Ratschläge, z. B. zur Verbesserung Ihres Profils oder zur Vorbereitung auf ein Vorstellungsgespräch. ...

Die Fehlerquote sank von 10 % auf 0,01 % und LinkedIn teilte umfassend seine Erfahrungen bei der Implementierung von LLM-Anwendungen

Beispiel: Wie ein neu entwickeltes System funktioniert

Wir zeigen anhand eines realen Szenarios, wie ein neu entwickeltes System funktioniert. Stellen Sie sich vor, Sie scrollen durch Ihren LinkedIn-Feed und stoßen auf einen interessanten Beitrag zum Thema Barrierefreiheit im Design. Zusätzlich zu diesem Artikel finden Sie auch einige Einführungsfragen, um tiefer in das Thema einzutauchen und Sie sind neugierig, wie zum Beispiel „Welche Beispiele dafür, wie Barrierefreiheit den Geschäftswert in Technologieunternehmen steigert?“

Systemhintergrundoperationen:

Wählen Sie den richtigen Agenten: Das System nimmt Ihr Problem und entscheidet, welcher KI-Agent am besten für die Lösung geeignet ist. In diesem Fall erkennt es Ihr Interesse an Barrierefreiheit in Technologieunternehmen und leitet Ihre Anfrage an einen KI-Agenten weiter, der auf die Durchführung allgemeiner Wissenssuchen spezialisiert ist.
Informationen sammeln: KI-Agenten rufen eine Kombination aus internen APIs und Bing auf und suchen nach spezifischen Beispielen und Fallstudien, die verdeutlichen, wie Barrierefreiheit im Design zum Geschäftswert in der Technologie beiträgt.
Formulieren Sie eine Antwort: Mit den erforderlichen Informationen kann der Agent nun eine Antwort verfassen. Es filtert und synthetisiert Daten zu kohärenten, informationsreichen Antworten und liefert Ihnen klare Beispiele dafür, wie Barrierefreiheitsinitiativen Technologieunternehmen einen geschäftlichen Mehrwert bieten. Um das Erlebnis interaktiver zu gestalten, werden interne API-Aufrufe durchgeführt, um Anhänge wie Links zu Artikeln oder Profile von in Beiträgen erwähnten Personen zu verwenden. 🔜 Mit nur wenigen Klicks können Sie tiefer in jedes Thema eintauchen, umsetzbare Erkenntnisse gewinnen oder Ihre nächste Jobmöglichkeit finden.

Technische Basis:

Die meisten neuen Funktionen werden mithilfe der LLM-Technologie ermöglicht.

Gesamtdesign:

Die Systempipeline folgt Retrieval Augmented Generation (RAG), einem gängigen Entwurfsmuster für generative Systeme der künstlichen Intelligenz. Überraschenderweise war der Bau der Pipeline weniger problematisch als wir erwartet hatten. In nur wenigen Tagen hatten wir das Grundgerüst eingerichtet und liefen:

Routing: Entscheiden Sie, ob eine Anfrage in Reichweite ist und an welchen KI-Agenten sie weitergeleitet werden soll.

Abruf:

Generieren:
查 Abbildung 1: PIPELINE der Benutzerabfrage vereinfachen. KSA steht für „Knowledge Sharing Agent“ und ist einer von Dutzenden Agenten, die Benutzeranfragen bearbeiten können.
Zu den wichtigsten Designs gehören:
Feste dreistufige Pipeline;
Kleines Modell für das Routing/Abrufen,
Einbettungsbasierter Abruf (EBR), unterstützt durch eine In-Memory-Datenbank, die Antwortbeispiele direkt in Prompt einfügt; Spezifische Evaluierungspipeline bei jedem Schritt, insbesondere für Routing/Retrieval.
Entwicklungsgeschwindigkeit
Wir haben beschlossen, die Entwicklungsaufgaben in die Entwicklung unabhängiger Agenten durch verschiedene Personen aufzuteilen: gesunder Menschenverstand, Jobbewertung, Jobpunkte usw.
Durch die Parallelisierung von Entwicklungsaufgaben erhöhen wir die Entwicklungsgeschwindigkeit, allerdings geht dies auf Kosten der „Fragmentierung“. Die Aufrechterhaltung einer einheitlichen Benutzererfahrung wird zu einer Herausforderung, wenn nachfolgende Interaktionen mit Assistenten erfolgen, die über unterschiedliche Modelle, Eingabeaufforderungen oder Tools verwaltet werden.
Um dieses Problem zu lösen, haben wir eine einfache Organisationsstruktur eingeführt:
Ein kleiner „horizontaler“ Engineering-Pod, der gemeinsame Komponenten verwaltet und sich auf das Gesamterlebnis konzentriert, einschließlich:
Dienste zum Hosten des Produkts
Bewertungs-/Testtools
Globale Eingabeaufforderungsvorlagen Wird von allen Branchen verwendet (z. B. globale Identität des Agenten, Konversationsverlauf, Jailbreak-Abwehr usw.)
Gemeinsame UX-Komponenten für iOS-/Android-/Web-Clients
Servergesteuertes UI-Framework zum Veröffentlichen neuer UI-Änderungen, ohne Client-Code zu ändern oder freizugeben.
Zu den wichtigsten Designs gehören:
Teilen und erobern, aber die Anzahl der Agenten begrenzen;
Zentralisierte Bewertungspipeline mit mehreren Dialogrunden;
Gemeinsame Eingabeaufforderungsvorlagen (z. B. „Identitäts“-Definition), UX-Vorlagen, Tools und Instrumentierung; Die Qualität der Antworten erwies sich als schwieriger als erwartet. Diese Herausforderungen lassen sich grob in drei Bereiche unterteilen: Richtlinien entwickeln, Anmerkungen erweitern und automatisierte Auswertung.
Die Entwicklung einer Richtlinie ist die erste Hürde. Nehmen wir zum Beispiel Stellenbewertungen: Es nützt nicht viel, auf „Bewerten Sie meine Eignung für diesen Job“ zu klicken und „Sie passen hervorragend“ zu erhalten. Wir möchten, dass die Antworten sowohl authentisch als auch einfühlsam sind. Einige Benutzer erwägen möglicherweise einen Karrierewechsel in einem Bereich, für den sie derzeit nicht gut geeignet sind, und benötigen Hilfe beim Verständnis der Lücken und der nächsten Schritte. Für den Annotator ist es von entscheidender Bedeutung, sicherzustellen, dass diese Details konsistent sind.
Kommentare zu erweitern ist der zweite Schritt. Wir brauchen konsistente und vielfältige Kommentatoren. Unser internes Linguistenteam hat Tools und Prozesse entwickelt, um bis zu 500 tägliche Gespräche auszuwerten und relevante Kennzahlen zu erfassen: Gesamtqualitätsbewertung, Halluzinationsrate, KI-Verstöße, Kohärenz, Stil und mehr.
Automatische Auswertungsarbeiten sind noch im Gange. Ohne automatisierte Auswertung konnten Ingenieure die Ergebnisse nur visuell überprüfen und an einer begrenzten Anzahl von Beispielen testen, wobei es mehr als einen Tag dauerte, bis sie die Metriken verstanden hatten. Wir entwickeln modellbasierte Evaluatoren zur Bewertung der oben genannten Metriken und arbeiten daran, einige Erfolge bei der Erkennung von Halluzinationen zu erzielen. Eine durchgängig automatisierte Evaluierungspipeline wird schnellere Iterationen ermöglichen.

Interne API aufrufen

LinkedIn verfügt über eine Fülle einzigartiger Daten über Personen, Unternehmen, Fähigkeiten, Kurse und mehr, die für die Entwicklung von Produkten mit differenziertem Wert von entscheidender Bedeutung sind.

Der LLM wurde jedoch nicht auf diese Informationen geschult und kann sie daher nicht zur Begründung und Generierung von Antworten nutzen.

Das Standardmuster zur Lösung dieses Problems besteht darin, eine RAG-Pipeline (Retrieval Augmented Generation) einzurichten, über die eine interne API aufgerufen und deren Antwort in nachfolgende LLM-Eingabeaufforderungen eingefügt wird, um zusätzlichen Kontext zur Unterstützung der Antwort bereitzustellen.
Viele dieser Daten werden intern über RPC-APIs in verschiedenen Microservices bereitgestellt.
Wir lösen dieses Problem, indem wir „Fähigkeiten“ um diese APIs wickeln. Jeder Skill besteht aus den folgenden Komponenten:
Eine benutzerfreundliche Beschreibung dessen, was die API tut und wann sie verwendet werden soll

Konfiguration für den Aufruf der RPC-API (Endpunkte, Eingabemodi, Ausgabemodi usw.)

LLM- benutzerfreundliche Eingabe- und Ausgabemodi
Primitive Typwerte (String/Boolean/Zahl)
Beschreibung des Eingabe- und Ausgabeschemas für JSON-Schema
Geschäftslogik für die Zuordnung zwischen LLM-freundlichem Schema und echtem RPC-Schema
Diese Fähigkeiten sind Entwickelt, um LLM die Durchführung verschiedener produktbezogener Vorgänge zu ermöglichen, z. B. das Anzeigen von Profilen, das Suchen nach Artikeln/Personen/Positionen/Unternehmen und sogar das Abfragen interner Analysesysteme.

Die gleiche Technik wird auch zum Aufrufen von Nicht-LinkedIn-APIs wie der Bing-Suche verwendet.

図 3: スキルを使用して内部 API を呼び出す。

特定のジョブを解決するためにどのスキルを使用するかを LLM に決定するよう求めるプロンプトを作成し (計画によるスキル選択)、スキルを呼び出すためのパラメーターを出力します (関数呼び出し)。呼び出しのパラメータは入力パターンと一致する必要があるため、LLM に構造化された方法でパラメータを出力するように依頼します。ほとんどの LLM は、構造化された出力のために YAML と JSON でトレーニングされます。 YAML は冗長性が低く、JSON よりも消費するトークンが少ないため、YAML を選択しました。私たちが遭遇した課題の 1 つは、約 90% の確率で LLM 応答に正しくフォーマットされたパラメーターが含まれるのに対し、約 10% の確率で LLM が間違って、無効なフォーマットのデータを出力することが多く、最悪の場合は有効な YAML さえも出力されないことです。。

これらのエラーは人間にとっては些細なものですが、それらを解析するコードがクラッシュする可能性があります。 10% という数字は無視できないほど高い数字であるため、私たちはこれに対処することにしました。

この問題を解決する標準的な方法は、問題を検出し、LLM にエラーを修正し、追加のガイダンスを提供するよう再度要求することです。このアプローチは機能しますが、追加の LLM 呼び出しによりかなりのレイテンシが追加され、貴重な GPU 容量が消費されます。これらの制限を回避するために、最終的には内部の防御的な YAML パーサーを作成することになりました。

さまざまなペイロードの分析を通じて、LLM によって犯される一般的な間違いを特定し、解析する前にこれらのエラーを適切に検出してパッチを適用するコードを作成しました。また、パッチ適用の精度を向上させるために、これらの一般的なエラーの一部に対するヒントを挿入するようにヒントを変更しました。最終的に、これらのエラーの発生率を約 0.01% に減らすことができました。

私たちは現在、生成 AI 製品の LLM 対応スキルとしてパッケージ化された API/エージェントの動的な検出と呼び出しのための統合スキルレジストリを構築しています。

容量とレイテンシ

容量とレイテンシは常に主な考慮事項です:

品質とレイテンシ: 思考の連鎖 (CoT) などのテクノロジーは、品質の向上と錯覚の軽減に非常に効果的ですが、必要があります。トークン化されないため、レイテンシが増加します。

スループットとレイテンシー: 大規模な生成モデルを実行する場合、使用率が増加するにつれて TimeToFirstToken (TTFT) と TimeBetweenTokens (TBT) が増加するのが一般的です。
コスト: GPU クラスターは簡単に入手できず、高価です。消費されるトークンが多すぎるため、最初に製品をテストするスケジュールを設定する必要さえありました。
エンドツーエンドのストリーミング: 完全な回答が完了するまでに数分かかる場合があるため、知覚される遅延を減らすためにすべてのリクエストをストリーミングします。さらに、実際にはパイプライン内でストリーミングをエンドツーエンドで実行します。たとえば、どの API を呼び出すかを決定する LLM 応答は段階的に解析され、パラメータの準備が完了すると、完全な LLM 応答を待たずに API 呼び出しがトリガーされます。最終的な包括的な応答も、リアルタイムメッセージングインフラストラクチャを使用してクライアントまで送信され、「責任ある AI」などに基づいて段階的に処理されます。
非同期ノンブロッキングパイプライン: LLM 呼び出しの処理には時間がかかる場合があるため、I/O スレッドをブロックしてリソースを無駄にしない完全非同期ノンブロッキングパイプラインを構築することでサービススループットを最適化しました。
興味のある読者は、ブログの原文を読んで、研究内容をさらに詳しく知ることができます。元のリンク: https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product

Das obige ist der detaillierte Inhalt vonDie Fehlerquote sank von 10 % auf 0,01 % und LinkedIn teilte umfassend seine Erfahrungen bei der Implementierung von LLM-Anwendungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!