Por que dashboards de autoatendimento não funcionam

• "self-serve dashboards" na prática não funcionam bem, porque engenheiros ou cientistas de dados acabam gastando muito tempo escrevendo queries e preparando dashboards para usuários de negócio.

Por que o "self-serve BI" não funciona

• SQL é a única ferramenta real de "self-serve BI". Mas a maioria dos fornecedores de "self-serve BI" tenta disfarçar SQL como se fosse outra coisa.
• Escrever queries SQL não é a única barreira para que stakeholders de negócio consultem dados. Eles não entendem o significado dos dados, de onde vêm, como são calculados, nem sabem como interpretar e validar os resultados.

Tentativa 1: a abordagem tradicional de "menus suspensos e caixas de seleção"

• Essa interface não passa de uma tentativa de fazer "SQL-by-mouse". Não é melhor que SQL; na verdade, é mais lenta, menos confiável, mais limitada e não pode ser generalizada para outras ferramentas.
• Pessoas como um CFO não vão usar essa interface para consultar dados, porque não têm o contexto necessário para entender os dados nem confiança nos resultados.

Tentativa 2: a abordagem text-to-SQL

• LLMs são quase eficazes demais em traduzir linguagem natural para SQL. Eles vão tentar gerar uma query mesmo quando a pergunta não fizer sentido.
• Um profissional técnico perceberá quando a pergunta não faz sentido e pedirá mais contexto. Vai explicar os tipos de dados disponíveis e colaborar com a área de negócio para formular perguntas precisas e úteis.
• LLMs podem vir a ser a solução real para "self-serve BI", mas ainda não em sua forma atual. Eles precisam de mais contexto e de maior capacidade para expressar incerteza e pedir mais informações.

O que realmente funciona

• O problema do "self-serve BI" não é o SQL, mas o contexto e o significado dos dados. A solução, independentemente da interface, é ensinar às pessoas sobre os dados que estão consultando.
• Fazer com que a equipe técnica documente todo o conhecimento gera uma sobrecarga considerável e rapidamente fica desatualizado.
• A verdadeira solução para "self-serve BI" não é tornar o BI "self-serve" para pessoas não técnicas, mas permitir que profissionais técnicos deem suporte aos stakeholders de negócio com mais eficiência, usando ferramentas melhores.

Sugestões para ferramentas melhores:

1. Fornecer LLMs para profissionais técnicos, não para stakeholders de negócio.
2. Permitir que usem livremente os dados com ferramentas com as quais se sintam confortáveis, como Python, R etc.
3. Permitir que profissionais técnicos compartilhem facilmente o que produzem. Notebooks e aplicações internas de dados são difíceis de compartilhar porque precisam lidar com contêineres, dependências e infraestrutura.

[GN⁺]

Comentários do Hacker News

• Problemas com ferramentas de BI: Ao usar ferramentas de BI, já houve a experiência de configurar incorretamente a forma de join das consultas e os dados serem exibidos de forma errada. Isso leva à perda de confiança na camada de abstração para pessoas que não conhecem bem SQL.

• Utilidade de Text-to-SQL: Ainda é útil para desenvolvedores, mas para não desenvolvedores há a possibilidade de gerar consultas incorretas por não entenderem adequadamente a estrutura do banco de dados.

• Incompetência institucional: Relatórios com erros de ferramentas de BI e de IA, além de informações incorretas, estão sendo realmente usados, e algo semelhante já foi criticado na tirinha Dilbert.

• Capacidade de aprendizado dos usuários de negócios: É equivocado presumir que usuários de negócios não conseguem entender a relação entre o modelo de dados e os menus suspensos. O problema surge quando o modelador de dados não entende bem o domínio.

• Experiência fornecendo dados: Com 24 anos de experiência fornecendo dados, apenas uma minoria dos usuários realmente usa as ferramentas, e os executivos preferem dashboards de KPI.

• Vantagens do Metabase: O Metabase oferece uma boa interface entre as ferramentas de BI e permite converter o SQL gerado pela GUI em SQL puro, facilitando o uso até para pessoas com menor nível técnico.

• Limites do BI self-service: É preciso reconhecer os limites do BI self-service, e a solução é criar dashboards personalizados que não exponham SQL aos usuários de negócios.

• Experiência usando Metabase: Ao usar o Metabase e ensinar usuários não técnicos por meio de "office hours", muitas solicitações deixaram de ser encaminhadas para a equipe de engenharia.

• A ironia do uso de SQL: É irônico que a alta gestão não consiga executar consultas SQL. O SQL foi originalmente criado para permitir que gestores consultassem dados com facilidade.

• Dificuldade no ETL: Para usuários não técnicos, lidar com dados em ETL é ainda mais difícil do que em BI. Ao desenvolver o AWS Glue, ficou claro que usuários técnicos precisam de ferramentas para depurar problemas.