Ein Prototyp auf eine verwaltete Inferenz umstellen

Annahmen, die sich schlecht verallgemeinern

Ein Prototyp ist normalerweise eine dünne Hülle um einen Anbieter. Das ist die richtige Wahl für einen Prototyp und die falsche Grundlage für einen Dienst, da mehrere Eigenschaften, die wie Fakten über LLMs erscheinen, tatsächlich Eigenschaften der Implementierung des ersten Anbieters sind.

• Tokenisierung. Derselbe Text ist eine unterschiedliche Anzahl von Token auf einem anderen Tokenizer. Kostenschätzungen, Kontextlimits und Trunkierungslogik, die davon ausgehen, dass dies nicht der Fall ist, brechen leise und produzieren eine Trunkierung in der Mitte eines abgerufenen Passus.
• Werkzeugaufruf. Die Anforderungs- und Antwortform für Werkzeuge ist anbieterspezifisch, ebenso wie die Strenge, mit der das Modell aufgefordert wird, gültige Argumente zu produzieren. Ein Schema, das ein Anbieter durchsetzt, kann bei einem anderen Anbieter nur empfohlen sein.
• Strukturierte Ausgabe. Einige Plattformen unterstützen durchgesetzte JSON-Schemata, und einige fördern sie nur in der Prompting-Aufforderung. Code, der die Antwort ohne Fallback parsen kann, funktioniert, bis er das erste Mal nicht funktioniert.
• Streaming. Chunk-Grenzen, Nutzungsberichterstattung und Abschluss-signale unterscheiden sich und die Unterschiede zeigen sich als intermittierende Rendering-Fehler anstelle von Ausnahmen.
• Sicherheitsfilterung. Welche Eingaben und Ausgaben blockiert werden und ob der Block ein Fehler oder eine Substitution ist, variiert. Ein Prototyp, der noch nie eine Ablehnung gesehen hat, kann sie häufiger bei anderen Anbietern sehen.

Zwei Quellcode-Änderungen, die die Migrationskonfiguration erleichtern

Setzen Sie einen Adapter vor den Modellanruf. Ein Modul, das eine interne Anforderungsform annimmt und eine interne Antwortform zurückgibt, mit einer Implementierung pro Anbieter. Der Rest der Anwendung wird dann gegen Ihre Form geschrieben, und das Hinzufügen eines Anbieters ist eine neue Implementierung und nicht eine Änderung an vierzig Stellen.

Machen Sie die Anforderungsform explizit und versioniert. Felder für das Modell, den Kontext, die Werkzeuge, die maximale Ausgabelänge, die Temperatur und die Korrelationskennung – mit der anbieterspezifischen Übersetzung, die innerhalb des Adapters stattfindet. Ein Versionskennzeichen auf der Form bedeutet, dass eine Änderung daran ein überprüfbares Ereignis und nicht eine unsichtbare Refaktorisierung ist.

Regeln, die vor der ersten Produktionsanfrage geklärt werden sollten

• Datenverarbeitung. Ob Prompts und Ausgaben aufbewahrt werden, wie lange sie aufbewahrt werden und ob sie zur Verbesserung der Modelle des Anbieters verwendet werden. Dies ist eine vertragliche Frage mit einer schriftlichen Antwort, und sie gehört in das Sicherheitspaket.
• Ratenlimits und Kontingente. Die Limits des Anbieters in den Regionen, die Sie bedienen, und das Verhalten Ihres Clients, wenn diese Limits erreicht werden. Ein Client, der bei Erreichen des Ratenlimits ohne Budget neu anfragt, wandelt ein weiches Limit in ein Kostenereignis um.
• Fallback. Welcher Anbieter verwendet wird, wenn der primäre Anbieter beeinträchtigt ist, im Voraus entschieden, mit dem bereits implementierten Adapter. Ein Fallback, der während eines Ausfalls entworfen wird, ist ein zweiter Ausfall.
• Modellversion-Festlegung. Ob Sie eine Modellversion festlegen oder dem neuesten Stand des Anbieters folgen und wer die Änderung des Verhaltens überprüft, wenn der Anbieter die festgelegte Version zurückzieht.
• Kostenzuordnung. Welches Team zahlt und wie die Nutzung gekennzeichnet wird, damit die Antwort nicht eine monatliche Rekonstruktion aus Protokollen ist.

Was zuerst migriert werden sollte

Migrieren Sie den kritischsten Pfad zuerst – ein internes Tool, ein Batch-Job, ein Endpoint mit geringem Verkehr – und verwenden Sie es, um den Adapter, die Tokenabrechnung und den Fallback zu validieren. Der Zweck besteht darin, das anbieterspezifische Verhalten auf einer Arbeitslast zu entdecken, deren Ausfall günstig ist, bevor dieselben Entdeckungen von Kunden gemacht werden.