DEV Community: Wildrik

Qwen3.8-Flash-Next: Alibaba abre a arquitetura do Qwen4 (125B MoE, 6B ativos)

Wildrik — Fri, 28 Aug 2026 04:55:21 +0000

A Alibaba soltou nesta semana o Qwen3.8-Flash-Next, novo modelo open-source da Qwen Team. O lançamento tem um peso a mais: segundo a equipe, ele é uma prévia da arquitetura que vai sustentar o Qwen4, liberada antes da família completa justamente pra comunidade testar e adaptar tooling.

As specs

MoE multimodal com 125B de parâmetros totais e apenas 6B ativos por token
Mais 51B de N-gram embeddings
Custo de treinamento estimado em cerca de 1/9 do Qwen3.7-Plus (TechNode)
Pesos sem restrição de uso no Hugging Face desde 24/08, com versão padrão e FP8 (também no ModelScope)

Por que importa pra quem desenvolve

Dois pontos práticos se destacam:

API compatível com as specs da OpenAI e da Anthropic. Se sua stack já fala com GPT ou Claude, dá pra apontar o endpoint pro Qwen3.8-Flash-Next e comparar custo e qualidade sem reescrever integração.
Inferência local viável. Com só 6B ativos por token, o modelo roda em hardware bem mais modesto do que um denso de 100B+ pediria. Os GGUF quantizados já começaram a aparecer no Hugging Face, o que abre a porta pra llama.cpp e afins.

Pra quem constrói produto com LLM no Brasil, é mais uma opção de flash-tier aberto pra colocar no benchmark interno, principalmente em tarefas de alto volume onde o custo por token manda.

Escrevi uma análise completa em português, com specs detalhadas, como baixar e comparação com o flash-tier de GPT, Claude e Gemini: https://www.techknow.com.br/post/qwen-3-8-flash-next

Quando o RAG erra, quase nunca é o LLM: 4 falhas de recuperação e como logar cada uma

Wildrik — Sat, 15 Aug 2026 02:09:44 +0000

Todo problema de RAG parece problema do modelo. Quase nunca é.

Demorei pra aceitar isso. Ficava trocando modelo de embedding, mexendo no prompt, achando que o Claude tava inventando coisa. O que estava quebrado era o que eu entregava pra ele, e só ficou óbvio quando comecei a logar o que voltava da recuperação.

Depois que instrumentei, os erros se separaram em quatro tipos bem diferentes.

1. Score baixo, e o pipeline responde assim mesmo

A pergunta simplesmente não tem resposta na base. Quase ninguém checa. Um piso resolve:

q_emb = vo.embed([question], model="voyage-3.5", input_type="query").embeddings[0]

cur.execute(
    "SELECT content, 1 - (embedding <=> %s) AS score "
    "FROM documents ORDER BY embedding <=> %s LIMIT %s",
    (q_emb, q_emb, top_k)
)
rows = cur.fetchall()

if not rows or rows[0][1] < 0.7:
    return "Não tenho essa informação na base."

Feio, mas corta a maior parte das respostas inventadas com cara de certeza. O 0.7 não é sagrado: é o ponto onde, na minha base, o chunk deixava de ter relação com a pergunta. Loga o score por uma semana e você acha o teu.

2. Chunk vizinho

"como resetar senha" trazendo "como resetar produto". Vetorialmente colado, na prática inútil.

Esse foi o que mais me irritou, porque parece bug do modelo e não é: busca vetorial pura não separa as duas coisas. Os dois chunks falam de resetar algo, com estrutura de frase quase idêntica, e a diferença inteira mora numa palavra que o vetor dilui.

Hybrid search (vetor + BM25) rendeu mais aqui do que qualquer troca de embedding que eu tinha tentado antes, porque o BM25 dá peso ao token literal "senha" — justamente o que o vetor perdeu. Reranker com cross-encoder na frente ataca o mesmo problema por outro lado.

3. Alucinação com o contexto certo na mão

O retrieval acertou e o modelo extrapolou mesmo assim. Isso é instrução, não recuperação: o system prompt precisa proibir na cara dura e pedir citação do trecho.

SYSTEM = (
    "Responda APENAS com base no contexto fornecido. "
    "Cite o trecho que embasa cada afirmação. "
    "Se a resposta não estiver no contexto, diga que não sabe."
)

Óbvio depois de escrito. Passei semanas culpando o retrieval por isso.

4. Chunk cortado no meio

Tabela partida, bloco de código sem fechamento. Chunking por contagem de token faz isso o tempo todo:

def chunk_text(text, size=500, overlap=50):
    words = text.split()
    return [" ".join(words[i:i + size])
            for i in range(0, len(words), size - overlap)]

Funciona pra prosa corrida e destrói documentação técnica. E o estrago é silencioso: o modelo responde bonito em cima de um pedaço mutilado, sem sinal nenhum de que faltou metade da tabela. Respeitar a estrutura do documento (header de markdown, seção do PDF) dá mais trabalho pra escrever e se paga na primeira semana.

O que eu faria diferente

Se fosse começar de novo, a primeira coisa que eu escreveria não era o pipeline, era o log. Score de cada chunk, quais entraram, tamanho de cada um. Sem isso você fica trocando peça no escuro, e trocar modelo de embedding é caro, demorado e quase nunca era o problema.

Escrevi o passo a passo completo no blog, com o pipeline em Python usando pgvector, Voyage e Claude, as 4 estratégias de chunking e a comparação com fine-tuning: https://www.techknow.com.br/post/o-que-e-rag

Quem já tem isso em produção: o ganho maior veio de mexer no chunking ou de botar um reranker na frente?

Spec-Driven Development: quando a especificação vira a fonte da verdade (não o código)

Wildrik — Tue, 21 Jul 2026 01:19:33 +0000

Venho usando agentes de código (Claude Code, Cursor) e bati numa parede que todo mundo conhece: o vibe coding — descrever a tarefa e deixar a IA cuspir código — escala mal. Funciona até a terceira mudança, quando ninguém mais lembra qual era a intenção original. O código virou a única fonte de verdade, e ele é péssimo pra contar por que algo foi feito.

Foi aí que caí no Spec-Driven Development (SDD): colocar a especificação antes do código. Na prática, a "spec" é um markdown versionado no repo — requisitos + critérios de aceite — que a IA lê antes de gerar qualquer linha. Ela vira o artefato principal, não um doc que apodrece numa pasta.

A tese que tirei: o gargalo de programar com IA deixou de ser "a IA escreve código bom?". Hoje é "a IA entende o que eu realmente quero?". A spec é o que fecha essa lacuna.

Três coisas que me fizeram levar a sério:

Não é waterfall. A spec é viva — você roda quatro fases em ciclos curtos: specify → plan → tasks → implement (que em ferramentas como o Spec Kit viram comandos: /speckit.specify, /speckit.plan...). Mais perto de TDD do que de cascata.
A spec guia o agente. Em vez de prompts soltos, a IA lê a especificação e o plano. No meu uso, errou menos — e me deixou revisar a intenção antes de revisar 400 linhas de diff.
Já tem ferramenta de verdade. Spec Kit (GitHub), Kiro (AWS), Tessl, OpenSpec — todas com repo aberto. E pra começar nem precisa de muito: um simples CLAUDE.md (ou AGENTS.md) na raiz do repo já é uma forma enxuta de aplicar a ideia.

Não é bala de prata. Pra script de 50 linhas, é overhead. O ganho aparece em código que vai ser mantido, em time, ou quando você delega pesado pra agentes autônomos.

Escrevi um guia mais fundo com as 4 fases em detalhe, a comparação Spec Kit vs Kiro vs Tessl vs OpenSpec (qual escolher) e o passo a passo rodando SDD com Claude Code na prática: techknow.com.br/post/spec-driven-development

Quem aqui já tá usando spec como fonte da verdade no fluxo com IA? Curioso pra saber qual ferramenta pegou — e onde travou.

OpenCode: a alternativa open source ao Claude Code (sem lock-in de modelo nem de nuvem)

Wildrik — Thu, 25 Jun 2026 16:51:59 +0000

Venho testando agentes de código (Claude Code, Cursor, Copilot) e o que mais me chamou atenção foi o OpenCode: open-source, 160k+ stars, com duas decisões de design que mudam o jogo.

Model-agnostic de verdade: roda com Claude, GPT, Gemini, DeepSeek e modelos locais via Ollama (75+ providers). Você troca de modelo sem trocar de ferramenta, o oposto do lock-in do Claude Code (só Claude) ou Cursor.
Sem lock-in de nuvem: com Ollama local e deploy air-gapped, dá pra rodar o agente sem o código sair da máquina. Relevante pra quem tem restrição de compliance (banco, gov, jurídico).

A tese: o eixo de competição saiu de "qual modelo é mais inteligente" pra "quem controla seu workflow e seus dados".

Não é bala de prata. Em qualidade bruta de modelo o Claude Code ainda lidera. É um trade-off (liberdade, custo e controle dos dados vs qualidade no topo), não superioridade.

Escrevi um comparativo completo (OpenCode x Claude Code x Cursor x Copilot, com setup e pra quem vale) aqui: https://www.techknow.com.br/post/opencode-alternativa-claude-code

Alguém já botou o OpenCode no fluxo de trabalho? Curioso sobre a experiência com modelos locais.