Warstwa semantyczna EDB umieszcza reguły dostępu agentów w Postgres

AWS opublikował omówienie warstwy semantycznej EDB, w którym to uprawnienia do bazy danych — a nie instrukcje w promptach — decydują o tym, co agent może odczytać. Opublikowany 3 listopada przykład łączy EDB Postgres AI z Amazon Bedrock AgentCore, usługami AWS do hostowania i łączenia agentów programowych. Jego główna teza jest konkretna: definicje biznesowe należy przechowywać blisko danych operacyjnych, a dostęp egzekwować tam, gdzie wykonywane są zapytania.

Warstwa semantyczna łączy język biznesowy ze strukturami i obliczeniami w bazie danych. W tym przypadku agent używa Strands Agents, frameworka do budowania agentów wywołujących narzędzia, aby odpowiadać na pytania dotyczące aktywności klientów. Napięcie powstaje między elastycznym generowaniem zapytań a niezawodną kontrolą. Asystent potrzebuje wystarczającej swobody, by interpretować pytania, podczas gdy właściciele baz danych potrzebują przewidywalnych ograniczeń jego dostępu.

Porównanie z Denodo, platformą wirtualizacji danych odpytującą rozproszone źródła, pomaga umiejscowić podejście EDB. Oba rozwiązania przekazują agentom kontekst biznesowy, lecz organizują go wokół różnych architektur danych. Dla deweloperów i nabywców korporacyjnych bezpośrednie pytanie brzmi: gdzie powinny znajdować się definicje i uprawnienia oraz kto ma je utrzymywać.

Warstwa semantyczna EDB sprawia, że znaczenie danych w bazie jest odkrywalne

Zmiana polega na wzorcu integracji, który umożliwia zewnętrznemu agentowi korzystanie z istniejących definicji bazy danych.

Omówienie agentowej warstwy semantycznej łączy rozszerzenie bazy danych AIDB firmy EDB z agentem działającym w AWS. Przykład dotyczący klientów wykorzystuje cztery tabele i widok pochodny, czyli zapisane zapytanie przedstawione jako obiekt bazy danych. Opisy biznesowe pochodzą z komentarzy w bazie, natomiast klucze obce, czyli ograniczenia łączące powiązane rekordy, dostarczają relacji dołączeń.

Według AWS przykład zachowuje bez zmian prompt i kod agenta, zmieniając jedynie poświadczenia bazy danych. Ograniczona rola nie może pobrać chronionej kolumny z numerem Social Security. To istotne rozróżnienie: baza danych odrzuca próbę dostępu, zanim asystent sformułuje odpowiedź.

Pozostaje to przykładem referencyjnym przygotowanym przez dostawcę. Ustanawia proponowaną implementację i opisuje przykładowe zachowanie, zamiast dostarczać niezależnych dowodów niezawodności w skali całego przedsiębiorstwa. Czytelnicy powinni rozdzielić te twierdzenia przed wyciąganiem wniosków o gotowości do wdrożenia.

Dokumentacja EDB wyjaśnia bazową semantyczną bazę wiedzy, czyli przeszukiwalny indeks struktury i opisów bazy danych. Indeksuje tabele, widoki, kolumny i komentarze, zamiast osadzać dane klientów. Embeddings, czyli numeryczne reprezentacje używane do dopasowywania podobieństwa, pomagają agentom znajdować odpowiednie obiekty bazy danych na podstawie pytań w języku naturalnym.

To rozróżnienie ma znaczenie dla oceny. Znalezienie właściwej struktury nie dowodzi, że wygenerowane obliczenie jest poprawne. Dostarcza modelowi lepszych materiałów do skonstruowania zapytania. Zespoły nadal muszą porównywać odpowiedzi z zaakceptowanymi wynikami biznesowymi.

Dla osób szukających wyjaśnienia warstwy semantycznej EDB użytecznym punktem wyjścia jest rozdzielenie odkrywania od egzekwowania zasad. Opisy pomagają agentowi zdecydować, co oznaczają dane. Uprawnienia określają, czy proponowane zapytanie może uzyskać dostęp do tych danych.

To umiejscowienie zmienia również zakres odpowiedzialności. Komentarz w bazie danych staje się częścią roboczego kontekstu agenta, a nie dokumentacją, do której deweloperzy zaglądają tylko okazjonalnie. Niedokładny opis zasługuje na taką samą uwagę jak wprowadzający w błąd interfejs aplikacji.

Rozważmy hipotetyczne pole zakupu, którego nazwa nie zdradza, czy zawiera kwotę jednostkową, czy łączną wartość zamówienia. Obie interpretacje prowadzą do poprawnej arytmetyki. Tylko jedna odpowiada definicji biznesowej, więc samo pomyślne wykonanie nie może ujawnić błędu.

To sprawia, że architektura jest istotna również poza przykładowym zbiorem danych. Jej wartość zależy od tego, czy zespoły potrafią przekształcić niejednoznaczne konwencje baz danych w utrzymywane i łatwe do odkrycia definicje. Połączenie z agentem ujawnia tę pracę jako warunek wstępny, zamiast ją ukrywać.

Właściciele baz danych przejmują część obciążenia związanego z agentami

Przeniesienie znaczenia do Postgres daje zespołom bazodanowym bezpośredni wpływ na jakość odpowiedzi.

Bezpośrednia presja spada na osoby odpowiedzialne za schematy, definicje raportowania i polityki dostępu. Zespół aplikacyjny może ulepszać instrukcje asystenta, ale nie rozwiąże nieustalonej definicji biznesowej samym doborem sformułowań.

Załóżmy, że sprzedaż i finanse stosują odmienne definicje aktywnego klienta. Jeden dział liczy ostatnie zakupy, drugi wymaga konta o dobrej kondycji. Agent, który bez zastrzeżeń wybiera jedną z interpretacji, tworzy odpowiedź wyglądającą na bardziej rozstrzygniętą, niż jest sama organizacja.

Przechowywanie definicji blisko danych tworzy miejsce do rozstrzygnięcia tej różnicy. Nie decyduje jednak, który dział ma rację. Ktoś nadal musi mieć uprawnienia do zatwierdzenia definicji, wyjaśnienia jej zakresu i zarządzania zmianami.

Dlatego obciążenie operacyjne zasługuje na uwagę obok samej architektury. Zespół wdrażający ten wzorzec powinien oczekiwać ciągłej pracy redakcyjnej nad znaczeniem danych w bazie. Przegląd opisów staje się częścią utrzymywania interfejsu używanego przez agentów programowych.

To samo dotyczy relacji między tabelami. Technicznie poprawne połączenie nie wyraża automatycznie relacji biznesowej wymaganej przez pytanie. Nabywcy powinni zapytać, czy ich obecna struktura bazy danych odzwierciedla potrzeby raportowe, czy jedynie obsługuje transakcje aplikacji.

Ta różnica staje się widoczna, gdy klient ma wiele adresów, właścicieli konta lub historyczne klasyfikacje. Pytanie o obecne terytorium wymaga innej interpretacji niż pytanie o terytorium w momencie złożenia zamówienia. Żadna odpowiedź nie powinna zależeć od nieudokumentowanego założenia.

Są to scenariusze oceny, a nie zgłoszone awarie implementacji EDB. Pokazują, gdzie lepsze odkrywanie schematu nadal wymaga osądu biznesowego. Użyteczny pilotaż powinien celowo obejmować pytania, których odpowiedzi zmieniają się wraz ze zmianą tych założeń.

Konsekwencja kadrowa jest bezpośrednia. Zespoły pracujące nad agentami potrzebują dostępu do osób, które już rozstrzygają spory dotyczące raportowania. W przeciwnym razie deweloperzy aplikacji ryzykują, że staną się nieoficjalnymi właścicielami metryk, których nie mają uprawnień definiować.

Nabywcy korporacyjni powinni zatem oceniać proces utrzymania obok demonstracji agenta. Kto zatwierdza zmienioną definicję? Które aplikacje od niej zależą? W jaki sposób organizacja dowiaduje się, że asystent korzysta z nieaktualnej interpretacji?

Dla zespołów inżynieryjnych przeszukiwalna baza wiedzy może zachować uzasadnienie stojące za tymi decyzjami. Definicje bazodanowe i dokumentacja pomocnicza służą powiązanym celom, nawet jeśli znajdują się w różnych systemach.

Krótkoterminowa presja polega na przygotowaniu wiarygodnego pilotażu. Długoterminowa ma charakter organizacyjny: utrzymanie spójności definicji biznesowych w miarę zmian aplikacji, wymagań raportowych i personelu. Architektura czyni tę odpowiedzialność bardziej widoczną, co jest użyteczne tylko wtedy, gdy ktoś ją przyjmie.

Zweryfikowane zapytania dają elastycznym agentom stabilny punkt odniesienia

Powtarzające się pytania biznesowe zasługują na wielokrotnie używaną logikę zapytań, nawet gdy użytkownicy formułują je innymi słowami.

EDB dokumentuje aliasy semantyczne, czyli nazwane zapytania połączone z przeszukiwalnymi opisami w języku naturalnym i zdefiniowanymi parametrami. Alias musi zawierać pojedyncze, tylko do odczytu SELECT, czyli zapytanie pobierające wyniki. EDB podaje, że weryfikuje to ograniczenie podczas tworzenia i wykonywania aliasu.

Implikacja architektoniczna to ścieżka pośrednia między stałymi interfejsami raportowymi a nieograniczonym generowaniem zapytań. Użytkownicy mogą wyrażać znane żądanie konwersacyjnie, podczas gdy system ma dostępne istniejące zapytanie jako punkt odniesienia.

W przypadku hipotetycznego raportu sprzedaży regionalnej zweryfikowana logika mogłaby już określać okres raportowania, klasyfikację klientów oraz sposób traktowania anulowanych zamówień. Te decyzje powinny przetrwać zmiany w sposobie sformułowania żądania przez użytkownika.

Różni się to od proszenia modelu o odtworzenie każdej decyzji za każdym razem. Odtwarzanie znanej logiki wprowadza kolejną okazję do zmienności. Ponowne użycie daje recenzentom mniejszy i bardziej konkretny obiekt do zbadania.

Zapisane zapytanie nie rozwiązuje jednak samodzielnie problemu interpretacji. Agent nadal musi rozpoznać właściwe zapytanie i podać odpowiednie parametry. Żądanie aktywności kwartalnej nie powinno po cichu zmieniać się w żądanie dotyczące ostatniego kwartału kalendarzowego.

Tworzy to odrębne pytania ewaluacyjne. Czy system rozpoznał zamierzone pytanie biznesowe? Czy wybrał właściwy okres i zakres? Czy zwrócone wyjaśnienie dokładnie opisuje, co mierzyło zapytanie?

Korzystny wynik z bazy danych obejmuje tylko część tego łańcucha. Asystent może pobrać właściwe rekordy i niepoprawnie je podsumować. Z kolei płynne wyjaśnienie może ukrywać zapytanie, które odpowiedziało na sąsiednie pytanie.

Praktyczną odpowiedzią jest utrzymywanie odpowiedzi referencyjnych dla powtarzalnych żądań. Zespoły mogą porównywać wygenerowane odpowiedzi z tymi punktami odniesienia, zmieniając sformułowania, daty i uprawnienia użytkowników. To testuje zachowanie, z którym użytkownicy faktycznie się spotkają.

Zweryfikowana logika tworzy też jaśniejszy proces zmian. Jeśli firma zmieni definicję, opiekunowie mogą zidentyfikować odpowiednie zapytanie i ocenić zmienione wyniki. Bez wspólnego punktu odniesienia równoważne definicje mogą rozchodzić się między aplikacjami agentowymi.

Korzyść ta ma swoje granice. Wysoce eksploracyjne pytania nadal będą wymagać interpretacji wykraczającej poza istniejący katalog zapytań. Nabywcy powinni ocenić, jak system zachowuje się, gdy nie ma bliskiego dopasowania, w tym czy prosi o doprecyzowanie.

Ważnym zachowaniem produktu jest uczciwa niepewność. Narzędzie, które rozpoznaje niejednoznaczne żądanie, daje użytkownikom możliwość skorygowania jego kierunku. Narzędzie, które z przekonaniem wybiera nieodpowiednią definicję, ukrywa tę decyzję.

Podejście EDB najlepiej oceniać zatem jako sposób organizowania wielokrotnie używanego znaczenia i logiki zapytań. Jego użyteczność zależy od współdziałania jakości wyszukiwania, obsługi parametrów i praktyk przeglądu. Żadnego z tych elementów nie należy wyprowadzać z udanej demonstracji innego.

Denodo uwydatnia granicę lokalnego znaczenia danych w bazie

Porównanie EDB vs Denodo opiera się na umiejscowieniu danych i odpowiedzialności operacyjnej.

Wcześniejsza architektura wirtualizacji danych AWS wykorzystuje Denodo do łączenia informacji o klientach z Amazon Aurora, Amazon Redshift i lokalnej bazy danych PostgreSQL. Wirtualizacja danych przedstawia rozproszone źródła przez wspólną warstwę zapytań. To omówienie umieszcza widoki biznesowe i polityki dostępu w Denodo.

Przykład EDB koncentruje natomiast znaczenie wewnątrz operacyjnej bazy danych Postgres. To porównanie nie wskazuje zwycięzcy pod względem wydajności. Pokazuje odmienne warunki wyjściowe przy podejmowaniu decyzji, gdzie powinna znajdować się definicja biznesowa.

Dla zespołu, którego istotne dane znajdują się już w jednym miejscu, warto rozważyć definicje lokalne dla bazy danych. Organizacyjna atrakcyjność jest oczywista: obecni opiekunowie bazy danych mają znane sobie miejsce do sprawdzania obiektów kształtujących odpowiedzi.

Dla zespołu, którego informacje o klientach obejmują niezależne systemy, główny problem jest szerszy. Należy uzgodnić identyfikatory, znaczenia i uprawnienia między tymi systemami. Dodanie interfejsu agenta nie eliminuje tych decyzji integracyjnych.

Przydatne pytanie EDB vs Denodo dotyczy zatem granicy pytania biznesowego. Czy organizacja może na nie odpowiedzieć na podstawie zarządzanej bazy danych, którą już obsługuje? Czy odpowiedź wymaga koordynacji między kilkoma źródłami?

Rozważmy hipotetycznego opiekuna klienta pytającego, którzy klienci wymagają uwagi w związku z odnowieniem umowy. Sama historia zakupów może nie wystarczyć. Status umowy, nierozwiązane zgłoszenia wsparcia i przypisanie właściciela konta mogą wpływać na odpowiedź.

Jeśli te rekordy znajdują się gdzie indziej, pilotaż skoncentrowany na bazie danych powinien wyraźnie pokazać to ograniczenie. W przeciwnym razie udana odpowiedź oparta na dostępnych rekordach może zostać uznana za kompletną ocenę konta. Brakujące źródło staje się ryzykiem biznesowym ukrytym pod pozorem sukcesu technicznego.

Podejście rozproszone ma własne wymagania ewaluacyjne. Połączenie źródeł nie oznacza automatycznie, że ich definicje są zgodne. Kupujący nadal muszą sprawdzić, jak system uzgadnia sprzeczne identyfikatory i okresy raportowania.

Centralne napięcie pozostaje takie samo w obu podejściach: elastyczni agenci potrzebują utrzymywanego znaczenia i egzekwowalnego dostępu. Wybór architektury określa, gdzie gromadzą się te obowiązki, zamiast je eliminować.

Dlatego liczba konektorów jest niepełnym kryterium zakupu. Konektor tworzy drogę do informacji. Nie ustanawia jednak, że konkretne pytanie ma uzgodnione znaczenie we wszystkich podłączonych źródłach.

Zespoły powinny porównywać architektury przy użyciu reprezentatywnego żądania biznesowego i pełnego zestawu jego zależności. Należy uwzględnić właścicieli źródeł, zatwierdzoną metodę obliczeń, ograniczenia dostępu i oczekiwane wyjaśnienie. To ujawnia więcej niż ogólna dyskusja o możliwościach agentów.

Dla EDB szansą jest uczynienie istniejącej struktury bazy danych niezawodnym fundamentem dla agentów. Granica jest równie jasna: organizacja musi ustalić, jak daleko ten fundament obejmuje pytania, które faktycznie zadają jej użytkownicy.

Uprawnienia nadal zależą od tożsamości docierającej do Postgres

Reguła dostępu do bazy danych chroni zamierzonego użytkownika tylko wtedy, gdy zapytanie jest wykonywane pod odpowiednią rolą.

Serwer MCP server firmy EDB korzysta z Model Context Protocol, standardowego interfejsu, za pośrednictwem którego agenci wywołują zewnętrzne narzędzia. Dokumentacja stwierdza, że wywołania narzędzi są wykonywane jako uwierzytelniona rola Postgres. Uprawnienia bazy danych określają następnie, co ta rola może uruchomić.

Tworzy to konkretny punkt kontroli dla zespołów produkcyjnych. Uwierzytelnienie osoby na granicy aplikacji i wybór tożsamości bazy danych niższego poziomu to odrębne obowiązki. Recenzenci powinni prześledzić oba, zanim zaakceptują twierdzenie o dostępie specyficznym dla użytkownika.

Hipotetyczne współdzielone konto raportowe ilustruje ten problem. Jeśli każde żądanie dociera do bazy danych pod tym kontem, reguły bazy oceniają uprawnienia tego konta. Spersonalizowany interfejs aplikacji sam w sobie nie ustanawia spersonalizowanego egzekwowania zasad w bazie danych.

Nie oznacza to, że współdzielone konta są zawsze nieodpowiednie. Oznacza to, że ich uprawnienia muszą odpowiadać zamierzonej granicy usługi. Wąsko określony asystent raportowy ma inne wymagania niż asystent obsługujący użytkowników o odmiennych prawach dostępu.

Zasady zabezpieczeń na poziomie wierszy w PostgreSQL ograniczają, do których rekordów rola może uzyskać dostęp. Gdy są włączone bez mającej zastosowanie zasady, zabezpieczenia wierszy domyślnie odmawiają dostępu. Jednak superużytkownicy i role z BYPASSRLS omijają te ograniczenia, a właściciele tabel zwykle je omijają, chyba że zostaną zmuszeni do ich przestrzegania.

Te udokumentowane wyjątki mają znaczenie podczas testowania połączenia agenta. Demonstracja z użyciem konta administracyjnego nie może potwierdzić izolacji zwykłych użytkowników. Ewaluatorzy muszą zweryfikować efektywną rolę i jej uprawnienia dla rzeczywistej ścieżki żądania.

Ograniczenia kolumn i ograniczenia wierszy odpowiadają również na różne pytania. Ukrycie wrażliwego pola nie potwierdza, że rekord innego klienta jest niedostępny. Przekonująca ocena powinna testować te wymiary dostępu, które obiecuje aplikacja.

Taka ocena powinna obejmować próby dostępu za pośrednictwem alternatywnych pytań. Bezpośrednie pytanie o wrażliwe pole jest użyteczne, ale żądania biznesowe mogą łączyć dozwolone atrybuty w nieoczekiwany sposób. Recenzenci powinni sprawdzać, co aplikacja zwraca i jak wyjaśnia ograniczenia.

Egzekwowanie uprawnień nie potwierdza również poprawności odpowiedzi. Rola może być upoważniona do odczytu rekordów, które agent łączy nieprawidłowo. Ocena bezpieczeństwa i ocena analityczna powinny pozostać odrębne, z dowodami dla każdej z nich.

Dostęp tylko do odczytu zasługuje na podobną precyzję. Zapobieganie zapisom ogranicza to, co agent może zmienić tą drogą. Nie określa, czy autoryzowany wynik zawiera informacje, które aplikacja powinna wyświetlić w określonym kontekście.

Te zastrzeżenia definiują zakres twierdzenia, zamiast je odrzucać. Egzekwowanie zasad przez bazę danych daje recenzentom coś konkretnego do sprawdzenia. Mogą analizować role, uprawnienia, zasady i wykonane zapytania, zamiast polegać wyłącznie na deklarowanych intencjach asystenta.

Pozostała praca polega na zweryfikowaniu, że aplikacja konsekwentnie dociera do tego punktu egzekwowania zasad pod zamierzoną tożsamością. Jest to odpowiedzialność wdrożeniowa i powinna być widoczna w dowodach odbiorowych.

Obserwuj izolację tożsamości, zmiany definicji i powtarzalne odpowiedzi

Kolejne użyteczne dowody pokażą, czy nadzór przetrwa zmiany użytkowników, definicji i wolumenu żądań.

W nadchodzących miesiącach kupujący powinni zwracać uwagę na oceny łączące te wymiary. Dodatkowe demonstracje znanych pytań dostarczają mniej informacji niż testy zaprojektowane wokół granic architektury.

Pierwszym sygnałem jest izolacja tożsamości na całej wdrożonej ścieżce żądania. Należy szukać dowodów, że użytkownicy z różnymi uprawnieniami otrzymują odpowiednio różne wyniki. Dowody powinny wskazywać efektywną rolę bazy danych, a nie jedynie pokazywać różne nazwy w interfejsie.

Test izolacji powinien obejmować próbę działania wykraczającego poza uprawnienia użytkownika oraz wynikające z niej zachowanie bazy danych. Konsekwentne egzekwowanie zasad wzmocniłoby argument za tą architekturą. Niewyjaśnione współdzielenie poświadczeń osłabiłoby twierdzenia o nadzorze specyficznym dla użytkownika.

Drugim sygnałem jest wpływ zmian definicji na odpowiedzi. Metryka biznesowa rzadko pozostaje niezmieniona przez cały okres działania aplikacji. Zespoły powinny szukać demonstracji, które aktualizują definicję, a następnie weryfikują późniejszą interpretację asystenta.

Znaczące dowody obejmują samą zmianę. Czy asystent stosuje zaktualizowane znaczenie? Czy recenzenci mogą określić, która definicja wspierała wcześniejszą odpowiedź? Czy zmienione odpowiedzi referencyjne są aktualizowane w ramach wyraźnego procesu?

Skuteczna obsługa zmian wzmocniłaby argument za utrzymywaniem znaczenia blisko zarządzanych obiektów bazy danych. Niejasna odpowiedzialność lub nieaktualne interpretacje pokazałyby, że sama współlokacja nie zapewnia spójności.

Trzecim sygnałem jest powtarzalna poprawność przy reprezentatywnym użyciu. Oceny powinny zmieniać sposób formułowania pytań, uprawnienia użytkownika i poziom jednoczesnej aktywności. Kupujący muszą zobaczyć, czy system pozostaje użyteczny, gdy warunki różnią się od pierwotnej demonstracji.

Nie wymaga to traktowania każdego pytania biznesowego jak rywalizacji benchmarkowej. Wymaga zadeklarowanego zestawu oczekiwanych zachowań. Poprawne obliczenia, właściwe odmowy, zrozumiałe ograniczenia i akceptowalne czasy odpowiedzi powinny mieć dowody.

Dla zespołów poszukujących wyjaśnienia warstwy semantycznej EDB w kategoriach operacyjnych, te sygnały zapewniają praktyczne ramy decyzyjne. Przekształcają propozycję architektoniczną w pytania, na które może odpowiedzieć pilotaż.

Pozwalają także uniknąć niepopartej prognozy dotyczącej tego, która platforma wygra. Najsilniejsze wdrożenie będzie zależeć od rozmieszczenia danych, wymagań dotyczących tożsamości i zdolności organizacji do utrzymywania definicji. Podejście skoncentrowane na bazie danych powinno być oceniane w tych warunkach.

Zacznij od pytania biznesowego, na które Twój zespół już niezawodnie odpowiada, a następnie udokumentuj jego definicję, oczekiwany wynik i granice dostępu. Przekaż recenzentom wystarczająco dużo informacji, aby mogli odtworzyć wynik bez zaufania do wyjaśnienia asystenta. Uruchom to samo żądanie przy użyciu odpowiednio ograniczonych tożsamości i sprawdź zachowanie bazy danych wraz z odpowiedzią. Następnie zmień istotną definicję i zweryfikuj, że odpowiedź uwzględnia zatwierdzoną zmianę. Wykorzystaj warstwę semantyczną EDB do przetestowania konkretnej propozycji operacyjnej: Twoja organizacja może utrzymywać wspólne znaczenie, jednocześnie egzekwując dostęp w czasie wykonywania zapytania. Przed rozszerzeniem pilotażu zapytaj, czy potrafisz wyjaśnić każdą ważną odpowiedź i każdą ważną odmowę.