Agenci różnią się od AI tym, że mogą wywoływać narzędzia (tools). W Databricks istnieje określony sposób na definiowanie narzędzi, tak aby były one dobrze zarządzane (governance), żeby uzyskiwał do nich dostęp tylko ten kto powinien, oraz aby Agent mógł odnajdywać potrzebne dla niego narzędzia.
Zazwyczaj tool, to po prostu funkcja, tyle że z bardzo dobrymi metadanymi, opisującymi ludzkim językiem do czego ta funkcja służy, jakie parametery przyjmuje i co zwraca. Te funkcje są rejestrowane w Unity Catalog, który poniekąd z automatu załatwia sprawę governance.
Same funkcje, jak to funkcje mogą robić różne rzeczy: wykonywać skomplikowane obliczenia, wywoływać zapytania SQL, odpytywać zdalne API, konwertować dane z jednej postaci do drugiej, tworzyć podsumowania, analizować obrazy, tłumaczyć dokumenty i wiele innych.
Ponieważ istnieje wiele narzędzi, którymi „możemy robić AI”, może wyjaśnijmy czym są tools, a czym nie są.
- Tools nie są Machine Learning Modelem (MLM). MLM to model, który np. nauczył sie oceniać czy mail jest spamem czy nie. Tool może korzystać z MLM i może przesyłać do MLM wiadomości do oceny, ale tool sam w sobie nie jest MLM
- Tools nie są ChatBotami. ChatBot odpowiada za konwersację z użytkownikiem. Podczas takiej konwersacji ChatBot może potrzebować dodatkowej informacji, np. o ostatnich zdarzeniach politycznych, albo aktualnej pogodzie. Wtedy, jeśli tylko takie narzędzie jest dostępne, to wywoła to narzędzie, aby uzyskać niezbędne informacje. ChatBot sobie dalej z nich może skorzystać do udzielenia odpowiedzi
- Tools to nie API. API jest specyficzne dla serwisu, który owo API obsługuje, a co za tym idzie, funkcja, która korzysta z API musi komunikować się ze zdalną usługą zgodnie z regułami zdefiniowanymi w tym API. Tools to funkcja, która może łączyć sie do zadanego API. Tools na wejściu przyjmie pytanie, które ma być przesłane do API i w ten sposób ukryje szczegóły implementacyjne przed innymi programistami.
Tools mogą być wykorzystywane w Databricks w wielu miejscach. W szczególności:
- Tools mogą być zdefiniowane jako funkcje zarejestrowane w Unity Catalog i jest to dość często widziany scenariusz. Dzięki temu cały governance jest oddelegowany do Unity Catalog
- Tools mogą też być zaimplementowane bezpośrednio w kodzie agenta. Po prostu autor agenta wiedział, że będzie on często korzystać z pewnej funkcjonalności i wyposażył w nią agenta. Bardzo to wygodne, ale na pewno nie będzie tam całej wymaganej funkcjonalności, a ta która jest nie podlega zarządzaniu przez Databricks czy Unity Catalog
- Tools mogą wreszcie być dostępne przez serwery Model Context Protocol (MCP). Można sobie wyobrazić, że MCP to usługa w której można rejestrować różne tools i opisywać je w odpowiedni sposób pewnymi metadanymi. Kiedy agent ma do wykonania jakieś zadanie może zgłosić się do serwera MCP i w opariu o jego dane wybrac sobie te właściwe narzędzia do określonego zadania. Mając namiar na tools, można go następnie wywołać już w standardowy sposób. Istotne jest tylko, że zarówno agent jak i tool muszą być zaimplementowane zgodnie z protokołem MCP.
- Mamy serwery MCP managed – zarządzane przez Databricks, bez możliwości tworzenia private endpoints, ale gotowe do użycia w workspace
- Mamy serwery MCP external – czyli utworzone gdzieś całkiem na zewnątrz Databricks. Daje to największą elastyczność, bo usługa jest konfigurowana gdzieś indziej i Databricks nie nakłada dodatkowych warunków.
- Mamy wreszcie MCP custom – uruchamiane jako aplikacja w Databricks, co daje pełną kontrolę nad rozwiązaniem, podczas gdy wszystko zostaje w obrębie Databricks
Jeśli wydaje ci się, że serery MCP to coś dziwnego i jakby nadmiarowego to może i masz rację. Dawniej, gdy takich wynalazków nie mieliśmy, to każdą funkcję trzeba było napisać samodzielnie, a potem pisząc większy program wywoływać te funkcje. Problemem było to, że te funkcje trzeba było znać, rozumieć ich szczegóły implementacji itp. MCP ma być pewnym rozwiązaniem na tą bolączkę, bo… Ty piszesz tylko funkcje i je rejestrujesz podając mnóstwo metadanych. To Agent wybiera sobie sam, którą funkcję kiedy wykorzystać. Oczywiście praca wykonywana przez programistę ręcznie była zdecydowanie tańsza, bo przy MCP to Agent, a więc drogi AI, będzie każdorazowo wybierał właściwą funkcję do realizacji zadania, a przez niedeterministyczność AI może wybrać nie te dane co należy. Jest więc drożej, bardziej skomplikowanie, mamy większe ryzyko błędów, ale… tak jest modniej i być może takie podejście lepiej się skaluje, bo funkcji można sobie tworzyć tysiące, a potem można je sobie do woli modyfikować, a Agenci… no cóż, będą zużywać swoje cenne tokeny, żeby wybrać tę właściwą funkcję/tool i przesłać do niego poprawne argumenty. Tak to zostało wymyślone – i na pociechę, jeśli nie chesz to nie musisz z nich korzystać 😉
