O seu chatbot com IA não está avariado. O seu pipeline de dados está.

Pontos-chave

• A maioria dos pilotos de IA empresarial estagna antes de ficar operacional, e os problemas de qualidade de dados no pipeline subjacente são mais frequentemente a causa do que as limitações do modelo.
• Um sistema RAG, que significa geração aumentada por recuperação e designa software que puxa dados comerciais reais para as respostas de um modelo de IA, não pode corrigir dados de origem quebrados ou contraditórios por si só.
• Alimentar dados não validados numa base de dados vectorial, um tipo de índice pesquisável que os sistemas de IA usam para procurar informações, leva esses dados inválidos directamente para as respostas da IA.
• Os controlos de segurança devem ser incorporados na própria infraestrutura de dados, não delegados no modelo de IA através de instruções escritas.
• Os engenheiros de dados dizem que a disciplina de construir pipelines de dados fiáveis é agora tão importante quanto escolher qual modelo de IA utilizar.

As empresas empresariais investiram milhões em pilotos de IA nos últimos dois anos. Um número enorme desses projectos nunca chegou aos utilizadores reais. Quando algo corre mal, o primeiro instinto é culpar o modelo de IA: era demasiado lento, não conseguia processar informações suficientes simultaneamente, não era inteligente o suficiente.

Naveen Ayalla, engenheiro de dados sénior, diz que esse instinto está geralmente errado.

Escrevendo na VentureBeat, Ayalla argumenta que o modelo é quase nunca o problema raiz. O problema são os dados que lhe são fornecidos. Ele chama o padrão de "Armadilha de Limpeza": a crença errada de que pode descarregar dados comerciais confusos, contraditórios e mal organizados num sistema de IA e esperar que a IA os organize.

Não funciona assim.

Por que é que a IA não consegue apenas corrigir os dados por si própria?

Porque não consegue, já que o dano ocorre antes da IA ver sequer a informação.

Muitos sistemas de IA empresarial usam uma configuração RAG. Em termos simples: quando coloca uma pergunta à IA, ela primeiro pesquisa um grande índice dos seus próprios documentos e registos da empresa, extrai as partes relevantes e usa-as para formar a sua resposta. Esse índice é chamado base de dados vectorial.

O problema é que construir esse índice é em si um trabalho de dados. Se os dados comerciais originais contêm registos de clientes duplicados, informação desactualizada ou campos que significam coisas diferentes em sistemas diferentes, esses erros ficam incorporados no índice. A IA depois pesquisa um índice quebrado e devolve respostas quebradas.

Nenhuma quantidade de escrita de prompts inteligente, significando as instruções que dá a um modelo de IA, corrige um índice corrompido. Ayalla é directo sobre isto: "Nenhuma quantidade de engenharia de prompts pode compensar um pipeline de ingestão quebrado."

As consequências não são abstractas. Um assistente de IA trabalhando com dados de clientes obsoletos ou contraditórios dará respostas erradas com confiança. Pode expor informação a pessoas que não deveriam vê-la. Será imprevisível de formas que são difíceis de corrigir.

As prescrições de Ayalla são práticas. Valide os dados no momento em que entram no sistema, não horas depois num trabalho nocturno em lote. Execute verificações automáticas que apanhem padrões incomuns, como uma inundação súbita de campos vazios, antes de corromperem o índice. E nunca peça ao próprio modelo de IA para decidir quem tem permissão para ver quais dados. Esse controlo de acesso pertence à infraestrutura de dados, tratado por engenharia adequada, não por instruções escritas numa mensagem de chat.

Este último ponto importa para qualquer pessoa cuja empresa armazene dados sensíveis. Detalhes pessoais, registos médicos, informação financeira: se a segurança ao nível de linha for tratada dizendo à IA "não mostres isto a utilizadores não autorizados", isso é um risco de conformidade à espera de se tornar numa violação.

O que observar se a sua organização está a implementar ferramentas de IA:

• Pergunte se os dados subjacentes foram validados antes de chegarem à IA, não depois.
• Verifique se os controlos de acesso são aplicados ao nível dos dados, não apenas pelo modelo de IA.
• Se a IA der respostas inconsistentes ou confidentemente erradas, suspeite do pipeline de dados antes de culpar o modelo.