Dyrektor zadaje pytanie i dostaje liczbę, definicję oraz SQL.
Użytkownik nie czeka na przygotowanie prostego raportu. Wynik można od razu sprawdzić, ponieważ obok liczby znajduje się definicja miary i zapytanie użyte do jej policzenia.
Test na 12 pytaniach
Ta wersja odpowiada na pytania o cztery zatwierdzone miary. Pokazuje definicję, wynik i wykonane zapytanie SQL. Korzysta z testowej hurtowni i nie łączy się z danymi klienta.
- Zapisany przebieg
- Test na 12 pytaniach
- Zakres testu
- Pytania do danych
- Zweryfikowano
- dane testowe
Problem, rozwiązanie i wynik
Proste pytania czekały w kolejce analityka
Proste pytanie o sprzedaż lub marżę trafia do kolejki analityka. Odpowiedź przychodzi za późno, a różne definicje tej samej miary prowadzą do sprzecznych liczb.
Jak działa system
System rozpoznaje miarę i buduje zapytanie do jednego z czterech zatwierdzonych widoków. Walidator sprawdza SQL przed wykonaniem, a konto bazodanowe ma wyłącznie dostęp do odczytu. Odpowiedź zawiera wynik, definicję i wykonane zapytanie.
Co sprawdziliśmy
Ta wersja odpowiada na pytania o cztery zatwierdzone miary. Pokazuje definicję, wynik i wykonane zapytanie SQL. Korzysta z testowej hurtowni i nie łączy się z danymi klienta.
Dla kogo
To dobry proces do automatyzacji, jeśli zarząd regularnie pyta o te same miary, a analitycy tracą czas na powtarzalne zapytania.
Pytanie → SQL → sprawdzalny wynik
- 01System korzysta tylko z zatwierdzonych widoków
- 02Konto bazy ma dostęp wyłącznie do odczytu
- 03Odpowiedź pokazuje definicję miary i wykonany SQL
- Typ firmy
- Firmy z hurtownią danych i cyklicznymi pytaniami zarządu
- Wejście
- Pytanie po polsku o przychód netto, marżę, aktywnych klientów albo średnią wartość zamówienia
- Uprawnienia bazy
- System czyta wyłącznie cztery zatwierdzone widoki i nie może niczego zapisać w bazie
- Koszt
- 0,004400 USD za pytanie; 0,052794 USD za zapisany przebieg 12 pytań.
- Bezpieczeństwo
- System może czytać tylko zatwierdzone widoki i nie ma uprawnień do zmiany danych.
- Tempo
- Czas odpowiedzi mierzymy w pilotażu na rzeczywistych miarach i wolumenie danych.
- Podstawa wyniku
- Przy każdym wyniku zapisane są pytanie, definicja miary i zapytanie użyte do obliczenia odpowiedzi.
- Budowa podobnego systemu
- od 25 000 zł netto · 4–10 tygodni
Do przeliczeń przyjęliśmy: 1 USD = 3,72 zł i 1 EUR = 4,30 zł. Kwoty w PLN są zaokrąglone, a waluta źródłowa pozostaje podana w nawiasie.
Gdzie kończy się automatyzacja
Zakres ustala analityk
System czyta wyłącznie cztery zatwierdzone widoki i nie może zapisywać danych. Pytanie spoza zakresu kończy się jasnym wyjaśnieniem. Analityk prowadzi definicje miar i decyduje o rozszerzeniu katalogu.
- Koszt
- 0,004400 USD za pytanie; 0,052794 USD za zapisany przebieg 12 pytań.
- Bezpieczeństwo
- System może czytać tylko zatwierdzone widoki i nie ma uprawnień do zmiany danych.
- Tempo
- Czas odpowiedzi mierzymy w pilotażu na rzeczywistych miarach i wolumenie danych.
Co jeszcze trzeba sprawdzić
Najwolniejsza z 12 odpowiedzi trwała 8,64 s. Ta próba jest za mała do ustalenia czasu odpowiedzi w codziennej pracy. W pilotażu sprawdzamy również pytania niejednoznaczne i szerszy schemat hurtowni.
Szacowany efekt
Policz efekt na swoim wolumenie
To szacunek oparty na podanym wolumenie. Wpisz własne liczby do formuły, aby ocenić możliwy efekt w swojej firmie. Podczas pilotażu sprawdzamy go na danych procesu.
Dziś
110 h
Po uruchomieniu
24 h
Oszczędność czasu lub kosztu
Scenariusz: 65-100 h/mies., baza 86 h
- Wolumen
- Scenariusz: 120 pytań/mies.
- Formuła
- 120 x 43 min / 60
- Status wyliczenia
- średnia
Dane na zrzutach. Nazwy, kwoty i dokumenty widoczne na zrzutach są testowe. Dane klientów pozostają prywatne. Wyniki dotyczą opisanego testu; wpływ produkcyjny sprawdzamy na danych klienta.
Ekrany
Analityk prowadzi definicje miar i obsługuje pytania spoza zatwierdzonego zakresu.
Dyrektor sam sprawdza podstawowe liczby przed spotkaniem. Analityk zajmuje się definicjami, nowymi miarami i pytaniami wymagającymi analizy. Szacunek opiera się na 120 pytaniach miesięcznie i można go przeliczyć na własny wolumen.
Trzy widoki dla osoby zadającej pytanie
Pole pytania
Pytanie zapisane zwykłym językiem, bez znajomości SQL.
Karta wyniku
Liczba, definicja miary i okres, którego dotyczy.
Podstawa wyniku
Wykonany SQL i użyty widok, gotowe do sprawdzenia przez analityka.
Ekrany systemu
Zobacz, jak system działa w praktyce
To zrzuty z działającej aplikacji w wersji komputerowej i mobilnej. Pokazują opisany proces oraz miejsca, w których decyzję podejmuje człowiek.
- Ekrany
- 12
- px
- 1440 · 390
- 021440×1132
Wykonane zapytanie SQL pod odpowiedzią. - 031440×1100
Wyjaśnienie dla pytania, którego nie da się policzyć w zatwierdzonym zakresie.
Otwórz archiwum pozostałych ekranów (9)
- 041440×1100
Pytania odrzucone - 051440×1100
Zatwierdzone miary - 061440×1100
Źródła i widoki - 071440×1100
Historia przebiegów - 081440×1503
Test i ograniczenia odtworzenia - 091440×1100
Jeden przebieg - 101440×1100
Pytanie odrzucone, drugi przypadek - 111440×1100
Próba zapisu zatrzymana przed bazą - 121440×1100
Jeden przebieg, drugi przypadek
Stos technologiczny
Model układa plan, a kod i baza pilnują zakresu
LangChain prowadzi pojedynczy plan zapytania. Walidator blokuje niedozwolony SQL. Osobna rola PostgreSQL wymusza odczyt, limit 500 wierszy i limit czasu 8 s.
- PostgreSQL 17
- hurtownia i zapis przebiegów; osobne konto ma tylko prawo SELECT w schemacie analytics
- FastAPI (Python 3.13)
- planuje zapytanie, sprawdza składnię i wykonuje je z limitami; walidator dopuszcza cztery zatwierdzone widoki
- LangChain + model Anthropic
- generuje odpowiedź w zamkniętym schemacie; wybiera miarę z katalogu i nigdy nie tworzy własnej
- Langfuse v2 (lokalny)
- zapisuje pytanie, wykonany SQL, czas i zużyte tokeny bez wysyłania danych o przebiegu poza system
- Next.js
- wyświetla rozmowę, notatnik SQL i rejestr odmów; z bazą łączy się za pośrednictwem serwera
Klient otrzymuje kod, katalog miar, dane testowe i dokumentację. Połączenie z hurtownią oraz ostateczne definicje miar powstają podczas wdrożenia.
Szczegóły techniczne i wyniki testów
Pętla pracy
Od pytania biznesowego do sprawdzalnej liczby
System wybiera miarę, buduje zapytanie i sprawdza je przed wykonaniem. Pytanie spoza zakresu kończy się wyjaśnieniem i trafia do analityka.
Pytanie biznesowe
Wybór zatwierdzonej miary
Walidacja i wykonanie SQL
Pytanie spoza zakresu → wyjaśnienie
Wynik z definicją i SQL
Architektura systemu
Katalog miar, walidator SQL i konto tylko do odczytu
Model planuje zapytanie w zamkniętym formacie. Walidator ogranicza je do czterech widoków, a uprawnienia bazy blokują zapis niezależnie od modelu.
- 01
Definicje
Każda miara ma jedną zatwierdzoną definicję
Katalog opisuje, czym jest przychód netto, marża czy aktywny klient. Model wybiera miarę z tego katalogu i nie może dopisać własnej. Definicja jest widoczna przy wyniku, więc analityk może od razu sprawdzić sposób obliczenia.
- 02
Walidacja
Kod sprawdza zapytanie przed wykonaniem
Dozwolone są wyłącznie cztery widoki analityczne. Inne relacje, CTE, funkcje systemowe, komentarze, wiele instrukcji i operacje zapisu są odrzucane przed wykonaniem.
- 03
Wykonanie
Osobne konto ma dostęp wyłącznie do odczytu
Zapytanie wykonuje osobne konto bazodanowe bez prawa zapisu, z limitem 500 wierszy i czasem wykonania ograniczonym do 8 sekund. Jego uprawnienia są zapisane w migracji bazy. Nawet jeśli niedozwolona instrukcja ominęłaby walidator, konto nadal nie może zmienić danych.
- 04
Historia zapytania
Każde pytanie ma zapis przebiegu
Pytanie, wykonany SQL, czas i zużyte tokeny trafiają do lokalnego Langfuse. Każdy przebieg zapisuje też kroki, decyzję i wywołanie narzędzia w łańcuchu skrótów w bazie. Zmiana wcześniejszego zdarzenia przerywa ten łańcuch; w teście kontrola przeszła dla 12 z 12 pytań. Koszt obliczamy po wykonaniu na podstawie zużytych tokenów i cennika dostawcy.
Dlaczego to nie jest czat z bazą
System odpowiada wyłącznie na pytania, które da się policzyć z zatwierdzonych widoków, i pokazuje sposób obliczenia. Walidator odrzuca swobodną rozmowę o danych i pytania spoza zakresu, więc zakres nie zależy od zachowania modelu. Architektura obejmuje tylko elementy potrzebne do tego procesu.
- Cztery widoki analityczne wyznaczają cały zakres
- Walidator działa niezależnie od jakości modelu
- Odmowa zawiera wyjaśnienie
- Wykonany SQL i decyzja każdego pytania wchodzą do łańcucha skrótów
Chcesz sprawdzić podobny proces w swojej firmie?
- 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
- Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
- Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.
Terminy zobaczysz w swojej strefie czasowej.
W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.