Was sollte ein Mensch bei einer Sprach-KI-Bestellung bestätigen?

In einem synthetischen Sprachbestellungsbeispiel wird ein wiederholter Sprach-Token zu drei Burgern. Das System bietet eine plausible Korrektur an: die Menge auf eins zu ändern. Für ein Produktteam ist die schwierige Frage, was zwischen diesem Vorschlag und der Erlaubnis zur Übermittlung der Bestellung geschieht. Ein hilfreich wirkender Ersatz hat noch nicht festgestellt, was der Kunde wollte.

Hinweis: Die folgenden Beispiele sind synthetische Bestellungen in Veriprajnas Drive-Thru Order Firewall, die strukturierte Anbieterausgaben vor einer simulierten Küchenanzeige validiert. Sie erkennt kein echtes Audio und sendet keine Bestellungen an das Kassensystem eines Restaurants.

Ich möchte, dass eine menschliche Bestätigung eine spezifische Unsicherheit auflöst. Das erfordert die Trennung von drei Beurteilungen: was der Kunde beabsichtigte, ob diese Bestellung nach den Richtlinien des Restaurants zulässig ist und ob die exakt vorgeschlagene Bestellung die Prüfungen erfüllt. Die Zusammenfassung dieser Beurteilungen in einer einzigen Genehmigungsschaltfläche macht es schwer zu erkennen, was eine Genehmigung bedeutet.

Eine Korrektur ist eine Hypothese über die Absicht

Das Test-Fixture für wiederholte Tokens enthält ein unvollständiges Transkript, drei identische Roh-Tokens und eine Menge von drei Burgern. Der gelieferte Konfidenzwert liegt bei 0.71 und damit unter dem konfigurierten Prüfschwellenwert von 0.85. Wiederholungs- und Niedrigkonfidenzregeln setzen die Bestellung daher auf HOLD. Die Wiederholungsregel schlägt einen Burger vor.

Eins ist ein plausibler Kandidat, der einem Bediener vorgelegt werden kann. Es ist kein Beweis für die beabsichtigte Menge. Das wiederholte Token erklärt möglicherweise die strukturierte Ausgabe, aber eine Regel, die Wiederholungen erkennt, kann den Kunden nicht fragen, was er meinte. Ein automatischer Ersatz von drei durch eins würde eine fragwürdige Interpretation gegen eine unbestätigte Interpretation eintauschen.

Die Ablehnung der Bestellung hat andere Kosten. Sie behandelt eine klärungsbedürftige Interpretation so, als könne keine akzeptable Bestellung wiederhergestellt werden. Ich bevorzuge an dieser Stelle ein Anhalten (Hold), da es die ursprünglichen Belege bewahrt und die beabsichtigte Menge offen lässt. In einem Produktionsdesign sollte die Bestätigung die Menge selbst erfragen, anstatt einen Bediener um die Bestätigung des allgemeinen Systemvertrauens zu bitten.

Das ist eine Designposition, kein abgeschlossener Workflow in dieser App. Die Schaltflächen Approve Correction und Escalate der Demo ändern ihre Beschriftung und deaktivieren sich selbst. Sie übermitteln die Bestellung nicht erneut, geben sie nicht frei, protokollieren keine menschliche Handlung und ändern nicht den Beleg. Ein Produktionsteam müsste die Konversation und die Statusänderung noch aufbauen, die ihrer Antwort Konsequenzen verleiht.

Eine ungewöhnliche Anfrage kann präzise verstanden werden

Interpretation ist nur ein Grund für ein Anhalten. Ein weiteres synthetisches Fixture enthält 18,000 Wasserbecher mit einem angegebenen Konfidenzwert von 0.97 und einem Menüpreis von null für den Kunden. Die Menge überschreitet die konfigurierte Wasserobergrenze von acht, sodass das Gate sie anhält. Weder der hohe Eingangswert noch der Preis von null beantworten, ob diese Menge fortgesetzt werden darf. Der Score ist eine Eingabe aus dem Fixture, keine kalibrierte Wahrscheinlichkeit einer Genehmigung.

Eine extreme Menge macht diese Unterscheidung leicht erkennbar. Die schwierigere Produktentscheidung ist eine ungewöhnliche Menge, die ein Kunde tatsächlich wünscht. Betrachten wir eine hypothetische Gruppenbestellung, die das normale automatische Limit eines Restaurants überschreitet. Wenn der Kunde die Zahl bestätigt, ist die Interpretation möglicherweise geklärt, während die Erlaubnis ungelöst bleibt. Eine Reduzierung auf die übliche Obergrenze würde die Anfrage verändern. Eine direkte Ablehnung könnte eine legitime Nachfrage verwerfen.

Ich bevorzuge die Verwendung eines Ausnahmeschwellenwerts, um eine Überprüfung auszulösen, wenn die Richtlinie eine Ausnahme zulässt. Der Bediener muss dann entscheiden, ob das Restaurant die bestätigte Bestellung annehmen kann, möglicherweise über einen separat autorisierten Weg. Ein Schwellenwert zur Begrenzung der automatischen Übermittlung sollte nicht stillschweigend zu einer Regel werden, die die Absicht des Kunden umschreibt.

Das kostet Aufmerksamkeit. Ein lockererer automatischer Schwellenwert lässt mehr ungewöhnliche Bestellungen durch; ein strengerer erzeugt mehr Prüfaufwand. Die Demo kann diesen Ausgleich nicht für ein Restaurant wählen. Ihre Obergrenzen stammen aus einer vorgegebenen synthetischen Bestellhistorie, und eine Verteilung beschreibt, was in dieser Historie auftrat. Sie bestimmt weder die tatsächliche Kapazität eines Standorts noch wie häufig eine legitime Gruppenbestellung vorkommt. Vor der Einführung einer solchen Richtlinie bräuchte ein Team Belege über akzeptable Ausnahmen und den praktischen Aufwand für deren Bestätigung.

Die Bestätigung muss für die exakt nächste Bestellung gelten

Selbst eine bestätigte Korrektur kann ungültig bleiben. Das Fixture mit hohem Volumen beginnt mit 40 Pommes und 40 Limonaden. Die Mengenregel schlägt vor, Pommes auf vier zu reduzieren, lässt aber 40 Limonaden unverändert. Die Obergrenze für Limonaden liegt bei sechs. Der Zustimmung, dass vier Pommes der richtige Ersatz sind, würde daher eine weitere Mengenverletzung in der vorgeschlagenen Bestellung belassen.

Aus diesem Grund halte ich Bestätigung und Validierung getrennt. Die Kundenbestätigung betrifft die Absicht. Die Ausnahmeentscheidung eines autorisierten Bedieners betrifft die Richtlinie. Die Prüfung der vollständigen vorgeschlagenen Bestellung klärt, ob die nächste Transaktion die geltenden Regeln erfüllt. Keine dieser Antworten lässt sich sicher aus den anderen ableiten.

Für einen Produktions-Workflow würde ich verlangen, dass ein bestätigter Vorschlag vor der Übermittlung erneut die Validierung durchläuft. Wenn ein Bediener eine Richtlinie außer Kraft setzen kann, sollte diese Befugnis explizit sein und an die jeweilige Regel und Bestellung geknüpft werden, die akzeptiert wird. Eine allgemeine Genehmigung sollte nicht unabhängige Fehler löschen. Dies sind Anforderungen an eine zukünftige Implementierung, keine Fähigkeiten, die durch die aktuellen Korrektursteuerungen demonstriert werden.

Beratung kann helfen, ohne die Erlaubnis zu erteilen

Die erläuternde Modellnotiz hat eine nützliche, aber engere Rolle: Sie kann den Grund für ein Anhalten leichter lesbar machen. In der begleitenden Gründeraufnahme verwendet dieser Hinweis zwischengespeicherte echte Beratungsausgaben. Es handelt sich nicht um eine frische Inferenz bei jeder Wiedergabe. Die Engine entscheidet zuerst anhand deterministischer Regeln; der nachfolgende Beratungstext kann die Entscheidung nicht ändern. Der Beratungsaufruf erfolgt synchron innerhalb der Verarbeitung, sodass diese Aufgabentrennung nicht beweist, dass Modellarbeit keine Anfragelatenz verursacht.

Die vollständige Aufschlüsselung der Bestellvalidierung zeigt diese Grenze und die synthetischen Beispiele. Sie stützen ein überprüfbares Entwurfsargument, aber keinen Beweis dafür, dass die hinterlegte Richtlinie oder der unvollendete Arbeitsablauf des Bedieners für den produktiven Einsatz bereit sind.

Hier ist die Gründeraufnahme des Beispiels zur Bestellprüfung.

Für mich besteht die entscheidende Produktprüfung darin, die vorgeschlagene Bestellung bis zu ihrer nächsten zulässigen Aktion zu verfolgen. Wer hat ihre Bedeutung bestätigt? Wer darf eine Ausnahme akzeptieren? Was hat das Gesamtergebnis überprüft? Solange sich diese Antworten nicht auf genau dieselbe Bestellung beziehen, hinterlassen eine beruhigende Korrektur und ein Genehmigungslabel die Transaktion unvollendet.