No pedido da CORR PLASTIK, o documento trazia códigos
no formato interno do ERP do cliente (por exemplo 0141000085).
Quando o assistente não encontrava um desses códigos no catálogo da
Baerlocher, acabava sugerindo produtos completamente sem relação —
como PEBEFOS FP (210085), PALLET DE MADEIRA (310085),
bisfenol, luminária e saco para plástico. A única conexão era um
fragmento numérico em comum ("085").
Esse ponto foi levantado a partir do relatório #20 (item #10A).
A busca do BORDER tinha duas etapas de fallback que, juntas, abriam espaço para falsos positivos quando a referência não existia no catálogo:
1. Busca aproximada com tolerância alta. Quando o código exato não era encontrado, o assistente buscava códigos similares usando um limite de semelhança baixo. Isso permitia que fragmentos curtos em comum (como "085") gerassem candidatos — mesmo quando o restante do código não tinha nada a ver.
2. Busca textual casando substrings numéricas. No último fallback, o assistente procurava o texto da consulta em qualquer posição dos códigos e nomes do catálogo. Com o catálogo atual contendo cerca de 11 mil itens (insumos, embalagens, materiais de manutenção e produtos comerciais), sempre existe algum item cujo código contém qualquer fragmento de 3 dígitos.
1. Busca aproximada mais rigorosa. O limite de semelhança foi aumentado de 30% para 60%. Códigos realmente parecidos (ex: "CZ-1902" vs "CZ1902") continuam casando; fragmentos curtos ("085") deixam de ser suficientes para formar um candidato.
2. Consulta puramente numérica e curta não aciona busca textual. Quando a consulta é apenas dígitos (eventualmente com hífens ou espaços) e tem menos de 8 caracteres, o assistente não tenta mais a busca textual — esse padrão é típico de código interno de ERP do cliente e dificilmente produz resultado útil, só ruído.
3. Instrução explícita ao assistente. Quando um pedido traz códigos numéricos puros do formato interno do cliente (ex: "0141000085 - 130LKOT"), o assistente foi orientado a buscar apenas o código ou nome da Baerlocher que vem junto ("130LKOT"). Se só existir o número do cliente sem nome/código reconhecível, ele pede a descrição em vez de chutar.
Uma mitigação complementar, ligada ao relatório #19 (auditoria do cadastro), reduzirá ainda mais o ruído quando aplicada: o catálogo sincronizado passará dos atuais ~11.000 itens para cerca de 1.000, eliminando naturalmente itens não comerciais (embalagens, insumos de manutenção) do universo de busca.
| Pedido contém | Antes | Agora |
|---|---|---|
| "0141000085 - 130LKOT" | Buscava o número 0141000085, achava PEBEFOS/PALLET por fragmento | Ignora o número do cliente, busca "130LKOT" — item correto |
| Só o número "0141000085", sem nome | Sugeria itens quaisquer que contivessem "085" | Pede ao cliente a descrição ou código da Baerlocher |
| "CZ-1902" (digitação com hífen) | Encontrava CZ1902 | Continua encontrando CZ1902 (busca aproximada mantém matches fortes) |
| "LUBRIFICANTES (EXTRUSÃO)" | Mesmo sem match, caía em busca textual com risco de ruído | Busca textual normal (texto com letras — não é código de ERP) |
Situacao: Quando o pedido do cliente trazia códigos
internos do ERP dele (ex: 0141000085) sem correspondência no catálogo
da Baerlocher, o assistente sugeria produtos completamente sem relação
— bastando compartilhar um fragmento numérico.
Correcao: Busca aproximada com limite mais rigoroso
(30% → 60%); consulta puramente numérica e curta deixa de acionar
busca textual; e o assistente foi instruído a ignorar códigos internos
do cliente, buscando apenas o código/nome Baerlocher que acompanha.
Impacto: Pedidos que trazem códigos do ERP do cliente
deixam de gerar sugestões aleatórias. Quando só existe o número do
cliente, o assistente pede a descrição em vez de chutar — eliminando
a maior fonte de confusão observada nos testes.