DEV Community: Everton Paula

My LLM pipeline cited real URLs for numbers those pages never said

Everton Paula — Wed, 28 Oct 2026 18:13:31 +0000

I run PostaGen, a small SaaS for the Brazilian market, and last week I added an app idea generator to it. You pick a niche, an audience and a country. It searches the web and returns 5 to 8 app ideas, each with a score, competitors, real user complaints and a price range.

The feature rests on one rule: a number without a source is never shown as fact. If the search didn't back it up, the page labels it as an estimate.

Below: how I enforced that rule with the Claude API, the hole a manual check found in it, and the fix a reader suggested in the comments of my first post about it.

The pipeline

Research call. One request with Anthropic's server-side web search tool (web_search_20260209, up to 8 searches, user_location set to the chosen country). The prompt asks for a source for every fact and tells the model to keep its own analysis apart from facts. The answer comes back as text with citations.
Structuring call. The API won't return citations and JSON structured output in the same request, so a second call, with no search, turns the notes into JSON with a fixed schema. It receives the numbered list of URLs the search returned and may only use those.
Validation, no model involved. Every URL in the JSON must be on the list the search returned. A competitor without a valid URL is dropped. A sentence without a valid source is marked as an estimate, and so is a price range.
MVP playbook and launch plan. Generated on demand, also with a JSON schema.

One detail you have to handle: a long search sometimes stops with stop_reason: "pause_turn". You send the assistant content back as it came and the model carries on. Skip that and the research ends halfway.

What it costs

Three scans from October 27, Brazilian market:

Niche	Searches	Sources read	Time	Cost
Beauty (B2B)	8	74	103 s	US$ 0.36
Pets (consumers)	8	76	93 s	US$ 0.32
Education (creators)	8	56	89 s	US$ 0.33

Nearly all of it is input tokens, because the search results go into the context (the beauty scan used 76.8k input tokens and 12.2k output), plus US$ 0.01 per search. The playbook costs about US$ 0.02 and the launch plan about US$ 0.03.

What the manual check caught

I opened the 56 links the three scans showed. 52 loaded, 3 didn't respond and 1 blocked automated access. The market figures I checked held up: 236 thousand beauty businesses formalized in 2025 (Sebrae), R$ 75.4 billion in pet sector revenue in 2024 (Abinpet), and the fees of Hotmart, Kiwify and Eduzz.

Three things were wrong:

A sentence about the pet market said "about 160 million pets, among them 60 million dogs and 30 million cats, in about 32 million homes". The sources confirm the pets, the dogs (62.2 million) and the cats (30.8 million). The 32 million homes are in neither source. Validation passed it because both URLs were real and came from the search.
One competitor's "website" was a complaint page on Reclame Aqui, Brazil's big consumer complaint site.
A blog post comparing platform fees was listed as a competitor.

So a valid URL proves the source exists and was read. It says nothing about whether that page contains the number in the sentence.

The fix came from a comment

A reader pointed out something the first call already returns. Every web_search_result_location citation carries cited_text: the passage from the page that supports the sentence, up to 150 characters. My code kept the URL and threw the passage away.

Now the server keeps the passages per URL:

for (const block of message.content) {
  if (block.type !== "text") continue;
  for (const c of block.citations ?? []) {
    if (c.type !== "web_search_result_location") continue;
    const source = sources.get(c.url) ?? { url: c.url, title: c.title ?? c.url, excerpts: [] };
    if (c.cited_text && !source.excerpts.includes(c.cited_text)) source.excerpts.push(c.cited_text);
    sources.set(c.url, source);
  }
}

The passages also go to the structuring call next to each URL, and the prompt asks the model to write a number the way the passage writes it. After the JSON comes back, every number in a market sentence has to appear in a passage cited by that sentence's sources. If any is missing, the sentence becomes an estimate.

Most of the work is reading the numbers. Brazilian sources write "62,2" for a decimal and "236.000" for thousands, English sources do the opposite, and both mix in words like "mil", "milhões" and "billion":

const SCALES: [RegExp, number][] = [
  [/^(mil|thousand|k)$/i, 1e3],
  [/^(milh(ão|ões)|mi|mm|millions?)$/i, 1e6],
  [/^(bilh(ão|ões)|bi|billions?)$/i, 1e9],
];

// "62,2" and "62.2" are decimals; "236.000" and "1,500" are thousands
function parse(raw: string): number {
  const last = Math.max(raw.lastIndexOf(","), raw.lastIndexOf("."));
  if (last < 0) return Number(raw);
  const sep = raw[last];
  const decimal =
    raw.includes(sep === "," ? "." : ",") || (raw.indexOf(sep) === last && raw.length - last - 1 !== 3);
  return decimal
    ? Number(`${raw.slice(0, last).replace(/[.,]/g, "")}.${raw.slice(last + 1)}`)
    : Number(raw.replace(/[.,]/g, ""));
}

export function numbersIn(text: string): number[] {
  const re =
    /(?<![\p{L}\d])(\d+(?:[.,]\d+)*)(?:\s?(mil|milh(?:ão|ões)|bilh(?:ão|ões)|mi|bi|mm|k|thousand|millions?|billions?)(?![\p{L}]))?/giu;
  const out: number[] = [];
  for (const [, raw, scale] of text.matchAll(re)) {
    const value = parse(raw);
    if (!Number.isFinite(value)) continue;
    // A bare year dates the fact, and a 150-character excerpt rarely repeats it
    if (!scale && /^\d{4}$/.test(raw) && value >= 1900 && value <= 2100) continue;
    const factor = scale ? (SCALES.find(([r]) => r.test(scale))?.[1] ?? 1) : 1;
    out.push(value * factor);
  }
  return out;
}

export function numbersMatch(sentence: string, excerpts: string[]): boolean {
  const wanted = numbersIn(sentence);
  if (!wanted.length) return true;
  const found = excerpts.flatMap((e) => numbersIn(e));
  return wanted.every((n) => found.some((f) => Math.abs(f - n) <= Math.abs(n) * 1e-9));
}

The test I wrote from the pet sentence:

const excerpt =
  "O Brasil tem 160 milhões de animais de estimação, sendo 62,2 milhões de cães e 30,8 milhões de gatos";

numbersMatch("160 milhões de pets, 62,2 milhões de cães e 30,8 milhões de gatos, em 32 milhões de lares.", [excerpt]); // false
numbersMatch("160 milhões de pets, 62,2 milhões de cães e 30,8 milhões de gatos.", [excerpt]); // true

What it still gets wrong

150 characters is short. A number can be on the page and outside the passage, and the sentence gets marked as an estimate for nothing. The reader and I agreed that this is the right side to err on: a good number labeled as an estimate costs less than an invented one presented as fact.
Rounding fails the check. The original sentence said "60 million dogs" while the source says 62.2 million. Under the new rule that sentence becomes an estimate, which is why the prompt now asks for numbers written as the passage writes them.
A number can be in the passage and still be misused, with the wrong year or the wrong unit. The check is necessary, not sufficient. Opening the links is still on the reader.
I didn't use blocked_domains. The reader also suggested blocking Reclame Aqui at the search. I kept it, because complaint pages are where the user pain that justifies an idea comes from. The rule went into validation instead: a complaint page is a valid source for a complaint and never a competitor's website.

I haven't rerun the three scans yet, so I don't know how many sentences now drop to estimates on real data. That's the next measurement.

Try it

The page shows the three scans with their sources, the ranking, the build prompt and the launch weeks, with no signup: postagen.ia.br/gerador-de-apps. The interface and the output are in Portuguese, though a scan can target the US market. The free plan gives 1 scan, 2 playbooks and 1 launch plan per month.

Stack: Next.js 16 on Vercel, Supabase with RLS (the owner can only read; writes go through the server) and the Claude API with web search.

If you check LLM-cited numbers some other way, I'd like to hear how in the comments.

CPF válido em teste automatizado: o dígito verificador, o CPF repetido e o DDD que não bate

Everton Paula — Wed, 28 Oct 2026 18:03:45 +0000

Quase todo sistema brasileiro tem um formulário que pede CPF. E quase toda suíte de teste desse sistema tem, em algum canto, um "123.456.789-09" fixo no código.

Funciona por um tempo. Depois aparecem três problemas, quase sempre nesta ordem.

1. O CPF repetido

123.456.789-09 passa no dígito verificador. O problema começa quando o segundo teste cadastra outro usuário com o mesmo CPF e o banco devolve duplicate key value violates unique constraint. A saída de sempre é uma lista de CPFs "que funcionam" num arquivo compartilhado, que ninguém sabe de onde veio e que acaba no meio dos dados de produção.

2. O número com cara de CPF que não é CPF

A segunda tentativa costuma ser gerar onze dígitos aleatórios e aplicar a máscara. O formato fica certo, mas o validador do back-end rejeita: só 1 em cada 100 sequências aleatórias acerta os dois dígitos verificadores.

Gerar um CPF válido é curto. Os dois últimos dígitos saem de uma soma ponderada módulo 11:

function gerarCPF(): string {
  const n = Array.from({ length: 9 }, () => Math.floor(Math.random() * 10));
  // 111.111.111-11 e afins passam na conta, mas são recusados
  if (n.every((d) => d === n[0])) return gerarCPF();

  const digito = (base: number[]) => {
    const peso = base.length + 1;
    const soma = base.reduce((acc, d, i) => acc + d * (peso - i), 0);
    const resto = soma % 11;
    return resto < 2 ? 0 : 11 - resto;
  };

  n.push(digito(n)); // pesos 10 a 2
  n.push(digito(n)); // pesos 11 a 2
  return n.join("").replace(/(\d{3})(\d{3})(\d{3})(\d{2})/, "$1.$2.$3-$4");
}

Se o seu teste só precisa de CPF, pode parar aqui: copie a função e siga em frente.

3. Os campos que não batem entre si

O terceiro problema aparece quando o sistema começa a cruzar dados. Antifraude, KYC e checkout com cartão olham se as peças fazem sentido juntas:

o DDD do celular é de uma cidade e o CEP é de outro estado;
o e-mail não tem nada a ver com o nome;
o cartão está no nome de outra pessoa;
a chave Pix não é o CPF, o e-mail nem o celular do cliente.

Cada campo isolado é válido, mas o cadastro como um todo é estranho, e o teste falha em lugar que não deveria. Ou pior: passa, porque o fixture nunca chegou perto do caso real.

Daí para frente a função de CPF vira um projeto: CNPJ (e o CNPJ alfanumérico, que a Receita começou a emitir em julho de 2026), cartão com Luhn, Pix nos quatro formatos do BACEN, DDD por cidade, banco com código COMPE de verdade.

O que eu acabei construindo

Passei por esses três problemas e montei o FakeForge, um gerador de dados brasileiros para teste com API. Aviso logo que o projeto é meu, então leve isso em conta. A API responde sem cadastro:

curl -s "https://fakeforge.com.br/api/generate?type=cpf&quantity=3"

{
  "type": "cpf",
  "quantity": 3,
  "data": ["286.908.784-59", "814.125.695-59", "016.709.862-41"]
}

Para o problema 3, há os presets: cada item é um cliente inteiro, com os campos coerentes entre si.

curl -s "https://fakeforge.com.br/api/generate?preset=customer&quantity=1"

{
  "nome": "Vinícius Campos Cunha",
  "cpf": "236.726.684-00",
  "email": "vinicius_campos694@hotmail.com",
  "telefone": "(85) 96986-1744",
  "endereco": {
    "cep": "60034-397",
    "street": "Avenida Presidente Kennedy, 1194",
    "neighborhood": "Dionísio Torres",
    "city": "Fortaleza",
    "state": "Ceará",
    "stateCode": "CE"
  }
}

DDD 85, CEP de Fortaleza e e-mail derivado do nome. O preset fintech vai além: as chaves Pix são o CPF, o e-mail e o celular do próprio cliente, e o cartão sai no nome dele.

Também dá para pedir em SQL ou CSV, com &format=sql ou &format=csv. O SQL já vem com o CREATE TABLE e o endereço achatado em colunas (endereco_cep, endereco_city...).

Nos testes

Existem SDKs para Node e Python, os dois sem dependência (npm install fakeforge-br e pip install fakeforge-br). A chave de API é lida da variável FAKEFORGE_API_KEY; sem ela, o SDK funciona no modo sem cadastro.

Playwright

import { test, expect } from "@playwright/test";
import { FakeForge } from "fakeforge-br";

const ff = new FakeForge();

test("cadastro com cliente novo a cada execução", async ({ page }) => {
  const [cliente] = await ff.customer(1);

  await page.goto("/cadastro");
  await page.fill("#nome", cliente.nome);
  await page.fill("#cpf", cliente.cpf);
  await page.fill("#email", cliente.email);
  await page.fill("#telefone", cliente.telefone);
  await page.fill("#cep", cliente.endereco.cep);
  await page.click("button[type=submit]");

  await expect(page.getByText("Conta criada")).toBeVisible();
});

Um cliente novo a cada execução acaba com o erro de CPF repetido sem precisar limpar o banco entre os testes.

pytest

# conftest.py
import pytest
from fakeforge import FakeForge

ff = FakeForge()

@pytest.fixture
def cliente():
    [c] = ff.customer(1)
    return c

# test_cadastro.py ("api" é o cliente HTTP do seu projeto)
def test_cadastro_aceita_cpf(api, cliente):
    resposta = api.post("/clientes", json=cliente)
    assert resposta.status_code == 201

Seed do banco no GitHub Actions

- name: Seed com 100 clientes
  env:
    FAKEFORGE_API_KEY: ${{ secrets.FAKEFORGE_API_KEY }}
  run: |
    curl -s -H "X-API-Key: $FAKEFORGE_API_KEY" \
      "https://fakeforge.com.br/api/generate?preset=customer&quantity=100&format=sql" \
      > seed.sql
    psql "$DATABASE_URL" -f seed.sql

A autenticação é pelo cabeçalho X-API-Key, não por Authorization: Bearer.

Limites

Prefiro deixar os limites claros antes que alguém descubra no meio do pipeline:

Sem chave: 50 chamadas por dia por IP e até 50 itens por chamada.
Com chave grátis: as mesmas 50 chamadas por dia, com até 100 itens por chamada.
Presets (clientes, pedidos): sem chave ou no plano grátis vem uma amostra de 3. O seed de 100 clientes acima precisa do plano pago.

Para testar um formulário ou rodar uma suíte pequena, o grátis sobra. Para seed grande ou CI rodando o dia todo, aí entram os planos pagos.

Qual é a sua?

O que mais quebra nos seus testes com dado brasileiro? Me conta nos comentários. Estou decidindo o que vem depois (inscrição estadual, RG por estado, CNH, boleto) e prefiro decidir com base em quem usa.