Modelle, Kontext und falsche Antworten

Trennen Sie Fähigkeiten von verfügbaren Informationen

Ein Sprachmodell nutzt erlernte Muster und die während einer Aufgabe bereitgestellten Informationen. Moderne Modelle können anspruchsvolle Schlussfolgerungen ziehen und nützliche Softwarearbeit leisten. Sie können aber auch eine ausführliche Antwort erzeugen, die auf einer falschen Annahme beruht.

„Frontier-Modell“ bezeichnet ein sich wandelndes Leistungsniveau. Der Begriff belegt nicht, dass ein Modell Ihr Repository gelesen hat. Er zeigt auch nicht, dass es Ihre Abhängigkeitsversionen oder ungeschriebenen Geschäftsregeln kennt. Die Aufgabenumgebung muss diese Fakten bereitstellen.

Ein Agent mit geeigneten Werkzeugen kann Informationen abrufen. Ein Chat ohne Zugriff kann das Repository nicht untersuchen. Stellen Sie bei einer offenbar falschen Antwort zwei Fragen: Kann das Modell das Problem mit den richtigen Informationen lösen? Hat es diese Informationen erhalten?

Ein anderes Modell kann beim ersten Problem helfen. Eine fehlende Richtlinie oder die Prüfung einer Abhängigkeit kann das zweite lösen.

Bestimmen Sie den Kontext für diese Aufgabe

Kontext sind die Informationen, die für die aktuelle Antwort verfügbar sind. Dazu gehören Anweisungen, bereitgestellte Dateien, relevante Gesprächsinhalte und Werkzeugergebnisse. Produkte wählen diese Informationen unterschiedlich aus und bewahren sie unterschiedlich auf. Sie können frühere Inhalte auch zusammenfassen.

Gehen Sie nicht davon aus, dass ein Modell jede Datei eines hochgeladenen Ordners liest. Nehmen Sie auch nicht an, dass eine frühe Anweisung während einer langen Sitzung durchgehend verfügbar bleibt. Bitten Sie das Werkzeug, die verwendeten Dateien und Anweisungen zu nennen.

Mehr Kontext verbessert eine Antwort nicht immer. Eine aktuelle Architekturentscheidung kann hilfreicher sein als nicht relevante Quelldateien. Ein veralteter Migrationsleitfaden kann zu einer falschen Antwort führen, weil er verbindlich erscheint.

Betrachten Sie eine fiktive Funktion für Kontoeinstellungen. Stellen Sie die Route, die Autorisierungs-Middleware, das relevante Datenmodell und einen vorhandenen Test bereit. Ergänzen Sie eine konkrete Vorgabe: „Ein Mitglied darf seinen Anzeigenamen ändern. Ein Mitglied darf seine Organisationsrolle nicht ändern.“ Das Modell hat nun eine ausdrückliche Regel, die es einhalten muss.

Prüfen Sie die Aussagen einer Erklärung

Eine Antwort könnte behaupten, ein Endpunkt sei sicher, weil Middleware die Eigentümerschaft prüft. Prüfen Sie jeden Teil dieser Aussage.

1. Prüfen Sie, ob der Endpunkt die angegebene Middleware verwendet.
2. Prüfen Sie, ob die Middleware die Eigentümerschaft kontrolliert und nicht nur die Authentifizierung.
3. Ermitteln Sie die Quelle der Nutzeridentität.
4. Führen Sie einen Negativtest als anderer Nutzer durch.

Ein Repository-Verweis zeigt, wo Sie nachsehen können. Er belegt nicht, dass die Erklärung mit dem Code übereinstimmt.

Gehen Sie bei einer API-Empfehlung genauso vor. Generierter Code kann eine Methode aufrufen, die Ihr installiertes Paket nicht exportiert. Prüfen Sie Paketversion und offizielle Dokumentation, bevor Sie Abhängigkeiten ersetzen. Sonst kann eine unbelegte Annahme eine unnötige Migration auslösen.

Machen Sie aus Unsicherheit eine Prüfung

„Seien Sie genau“ ist kein Prüfplan. Benennen Sie die Annahme, den benötigten Nachweis und die Folgen eines falschen Ergebnisses.

Zum Beispiel: „Für diesen Endpunkt haben wir die Mandantentrennung noch nicht geprüft. Untersuchen Sie den Request-Handler. Ergänzen Sie einen Test, bei dem ein Nutzer eines anderen Mandanten denselben Datensatz anfordert.“ Diese Anweisung gibt dem Agenten eine konkrete Untersuchung und ein beobachtbares Ergebnis vor.

Bei Implementierungsfragen untersuchen Sie die tatsächliche Systemversion. Ein Dokument kann das beabsichtigte Verhalten beschreiben. Codeprüfung und Tests helfen, das aktuelle Verhalten festzustellen. Bei Widersprüchen halten Sie die Abweichung fest, bis eine verantwortliche Person sie klärt. Wählen Sie nicht stillschweigend die bequemere Antwort.

Führungskräfte können diese Methode nutzen, ohne jede Codeänderung zu lesen. Fragen Sie, welche Annahmen das Team geprüft hat. Benennen Sie offene Annahmen und die jeweils Verantwortlichen. Diese Informationen unterstützen eine Freigabeentscheidung unmittelbarer als der Modellname.