Najlepsze praktyki poprawy generowania zapytań agentów danych

Agent danych generuje lepsze zapytania, gdy ma skoncentrowany, dokładny kontekst dotyczący danych, które może wykorzystać. Nazwy obiektów i metadane schematu stanowią punkt wyjścia, ale mogą nie wyjaśniać znaczenia biznesowego, wartości oczekiwanych, relacji ani logiki zapytań potrzebnej do odpowiedzi na pytanie.

Użyj konfiguracji, która najlepiej odpowiada kontekstowi, który musisz zapewnić:

Goal Configuration
Ogranicz dane do zapytań agenta Wybór schematu
Wyjaśnij, co oznacza pojedyncza tabela, kolumna lub inny element schematu Opisy obiektów schematu
Zdefiniuj zasady biznesowe, relacje i wytyczne obowiązujące w różnych obiektach Instrukcje dotyczące źródła danych
Pokaż wzorzec zapytań dla pytania Przykłady zapytań

Aby uzyskać przegląd tych ustawień, zobacz konfiguracje agentów danych.

Używaj jasnych nazw schematów

Używaj opisowych nazw dla źródeł danych, tabel i kolumn, gdy kontrolujesz schemat. Nazwy takie jak product_unit_price, Table1 i date1 dają agentowi bardziej użyteczne sygnały niż nazwy takie jak value, order_submission_date i CustomerOrders.

Nie polegaj tylko na nazewnictwie. Nawet jasna nazwa techniczna może nie przekazywać znaczenia biznesowego obiektu, poziomu szczegółowości, jednostek czy ważnych wartości. Użyj opisów i instrukcji dotyczących źródeł danych, aby zapewnić ten kontekst.

Ogranicz wybrany schemat

Wybierz tylko tabele, kolumny, widoki i funkcje potrzebne do pytań, na które agent danych powinien odpowiadać. Obiekty nieistotne zwiększają niejednoznaczność i dają narzędziu generującym zapytania więcej możliwych ścieżek do rozważenia.

Na przykład, jeśli użytkownicy pytają o aktualne zamówienia klientów, nie uwzględniaj zarchiwizowanych tabel stażingowych ani niezwiązanych z nimi tabel finansowych. Gdy dwa wybrane obiekty zawierają podobne dane, wyjaśnij, który jest autorytatywny i kiedy używać każdego z nich.

Opisz obiekty schematu (Podgląd)

W przypadku dużych lub niejednoznacznych schematów SQL używaj opisów obiektów schematu , aby wyjaśnić, co reprezentują poszczególne tabele, kolumny i inne elementy schematu. Opisy obiektów schematu są dostępne tylko wtedy, gdy agent danych korzysta z środowiska uruchomieniowego w wersji zapoznawczej.

Opisy są przydatne, gdy:

  • Nazwy obiektów są skracane, ogólne lub podobne do siebie.
  • Poziom szczegółowości tabeli ani jej cel biznesowy nie wynikają jasno z jej nazwy.
  • Kolumna zawiera kody, flagi, jednostki lub wartości kategorii wymagające interpretacji.
  • Kolumna daty reprezentuje konkretne wydarzenie biznesowe, takie jak złożenie zamówienia, a nie realizacja.
  • Schemat jest zbyt duży, by jasno wyjaśnić każdy obiekt w instrukcjach źródła danych.

Opisz zarówno znaczenie, jak i wartości oczekiwane, gdy te informacje wpływają na generowanie zapytań. Przykład:

Obiekt schematu Skuteczny opis
AdoptionEvents Zawiera jeden wiersz dla każdej zakończonej adopcji zwierzęcia. Użyj AdoptionDate jako data zakończenia.
StatusCode Status cyklu życia adopcji. Wartości oczekiwane to AP (zatwierdzone), PD (w trakcie oczekiwania) oraz CN (anulowane).
Weight Obecna waga zwierzęcia w kilogramach. Zero oznacza, że nie ma dostępnego pomiaru.

Priorytetyzuj opisy obiektów, które trudno wywnioskować. Unikaj powtarzania oczywistej nazwy bez dodania kontekstu biznesowego.

Używanie instrukcji dotyczących źródła danych dla reguł obejmujących różne obiekty

Instrukcje dotyczące źródła danych dostarczają wskazówek dotyczących generowania zapytań dla konkretnego źródła danych. Używaj ich do kontekstu obejmującego wiele obiektów schematu lub definiującego, jak powinno być skonstruowane zapytanie, w tym:

  • Autorytatywne tabele dla danego tematu.
  • Klucze łączenia i wymagane ścieżki połączenia.
  • Reguły poziomu szczegółowości tabeli i deduplikacji.
  • Domyślne filtry, takie jak używanie tylko aktualnych lub aktywnych rekordów.
  • Logika dat, kalendarze fiskalne i założenia dotyczące stref czasowych.
  • Wymagane obliczenia lub kolumny wyjściowe.

Napisz bezpośrednie instrukcje, które określają, co agent powinien zrobić. Na przykład użyj "Join EmployeeStatusFact to EmployeeDim on EmployeeID" zamiast "Unikaj błędnego łączenia tabel pracowników".

Zachowaj fokus na instrukcjach. Umieść definicje specyficzne dla obiektów w opisach obiektów schematu zamiast używać ograniczonej przestrzeni instrukcji jako słownika dla każdej tabeli i kolumny.

Zdefiniuj warunki biznesowe i wartości oczekiwane

Zdefiniuj terminologię, którą użytkownicy mogą uwzględniać w swoich pytaniach, ale która nie odpowiada bezpośrednio schematowi. Przykłady to skróty takie jak "MAU", specyficzne dla organizacji znaczenia "aktywnego klienta" oraz rozróżnienia na przykład rok fiskalny i rok kalendarzowy.

Dokumentuj także wartości, których agent potrzebuje, aby poprawnie konstruować filtry:

  • Czy kolumna stanu używa "CA", czy "California".
  • Czy wartość boolowska jest przechowywana jako 1 i , Y0i N, lub tekst.
  • Niezależnie od tego, czy wartości walut są przechowywane w dolarach czy centach.
  • Które wartości statusu oznaczają ukończone, anulowane lub aktywne rekordy.
  • Czy wartości null, zero lub data wartownicza mają specjalne znaczenie.

Umieść definicję w opisie obiektu schematu, gdy dotyczy ona jednego obiektu. Umieść go w instrukcjach źródła danych, gdy stosuje się w całym źródle danych lub wpływa na logikę zapytań wieloobiektowych.

Wyjaśnij relacje i granularność tabeli

Dokładne łączenia zależą od czegoś więcej niż tylko dopasowania nazw kolumn. Zidentyfikuj ziarno ważnych tabel, prawidłowe ścieżki relacji i klucze, które nie są oczywiste z metadanych.

Na przykład, wyjaśnij, czy tabela sprzedaży zawiera jeden wiersz na każde zamówienie, linię zamówienia lub łączną sumę produktu dziennie. Jeśli połączenie dwóch tabel faktów spowoduje zdublowanie wierszy, polec agentowi, aby zagregował każdą tabelę przed połączeniem lub użył odpowiedniej tabeli wymiarowej.

Uwzględnij wskazówki dotyczące relacji, takie jak:

- Join `OrderItems` to `Orders` on `OrderID`.
- Join `Orders` to `Customers` on `CustomerID`.
- Aggregate `OrderItems` to one row per `OrderID` before joining to order-level payment totals.

Używaj przykładowych zapytań do logiki złożonej

Używaj przykładowych zapytań , gdy pokazujesz, że zapytanie jest jaśniejsze, niż opisując logikę w prozie. Dobrym przykładem jest zestawienie reprezentatywnego pytania w języku naturalnym z poprawnym zapytaniem, które pokazuje oczekiwany wzorzec.

Priorytetyzuj przykłady pokazujące:

  • Łączenia wielotabelowe lub wymagana wstępna agregacja.
  • Obliczenia specyficzne dla biznesu.
  • Daty względne, okresy fiskalne lub logika migawkowa.
  • Filtry, które odwzorowują terminologię użytkownika na zapisane wartości.
  • Ranking, funkcje okienkowe lub inne złożone wzorce zapytań.

Niech każdy przykład koncentruje się na jednym wzorcu wielokrotnego użytku. Unikaj nakładających się lub sprzecznych przykładów i sprawdź, czy każdy z nich nadal pasuje do aktualnego schematu.

Przetestuj i dopracuj kontekst

Testuj pytania reprezentatywne, przeglądaj wygenerowane zapytanie i identyfikuj, jaki kontekst był niezrozumiany lub brakował. Zaktualizuj konfigurację najbliższą problemowi:

  • Usuń nieistotne obiekty lub dodaj brakujące w wyborze schematu.
  • Wyjaśnij znaczenie lub oczekiwane wartości jednego obiektu w jego opisie schematu.
  • Dodaj międzyobiektową logikę biznesową lub logikę łączenia do instrukcji dotyczących źródła danych.
  • Dodaj przykładowe zapytanie, gdy agent musi nauczyć się konkretnego wzorca zapytania.

Powtarzaj ten proces, gdy schemat i pytania użytkowników się rozwijają. Aby uzyskać ustrukturyzowany workflow testowania, zobacz Rozwój agenta danych przy użyciu procesu iteracyjnego.

Dalsze kroki

  • Last updated on