2026-09-05

BI in linguaggio naturale vs Power BI: quando non serve un modello semantico prima

Power BI è ottimo per report pubblicati su un modello semantico curato. Quello è anche il costo: qualcuno deve governare Power Query, relazioni, misure e di solito DAX prima che un utente possa usare uno slicer.

La BI in linguaggio naturale (text-to-SQL) parte dall’altro capo. Colleghi un database MySQL, PostgreSQL, Oracle o SQL Server e chiedi: vendite del trimestre per negozio. Il motore scrive una SELECT. Non c’è un cubo da aggiornare prima.

Dove Power BI è davvero forte

• Dataset certificati in un tenant Microsoft 365.
• Report paginati e abitudine a Excel.
• Row-level security già nel dataset.
• Team che pagano già Fabric / Premium e hanno uno sviluppatore BI.

Se quello stack c’è, non smontarlo. Copilot di Power BI risponde dal modello che hai costruito, non da tabelle di produzione a caso.

Dove il text-to-SQL è più veloce

Nelle PMI i fatti stanno in tabelle OLTP e la coda è “mi tiri fuori questo?”. Modellare ogni domanda in Power BI è più lento che far chiedere all’analista in linguaggio naturale su una connessione in sola lettura.

Serve un glossario (cosa è “fatturato” nel tuo schema) e un utente DB read-only. Non serve migrare prima su un warehouse Microsoft.

BI Jedi è quello strato: chat, Builder, template o SQL Pro sulla stessa connessione. I dati non addestrano modelli. Se le fonti sono sparse, il datawarehouse interno importa CSV/FTP in schedulazione.

Una divisione pratica, non una religione

• Board pack del lunedì da un modello certificato → Power BI.
• “Perché i pending sono esplosi ieri?” su MySQL → BI in linguaggio naturale.
• Vive già in Excel + Microsoft 365 → Power BI.
• Vive in Postgres e Slack, non in Fabric → BI in linguaggio naturale.

Molti team tengono Power BI per il pack ufficiale e usano l’NLQ per esplorare. Costa meno di un ticket di modello per ogni domanda.

Prova una domanda chiusa su un database reale: spazio gratuito BI Jedi.