- AI Fresh Automate & Innovate
- Posts
- Jak Stworzyć Asystenta AI, który Rozmawia ze Switchami Cisco? Pełny Tutorial
Jak Stworzyć Asystenta AI, który Rozmawia ze Switchami Cisco? Pełny Tutorial
Adrian Magiera
May 02, 2024
Podróż przez świat interakcji człowieka z komputerami zaczyna się od oldschoolowego CLI (Command Line Interface). Dawniej to właśnie czarne ekrany z białym tekstem dominowały. CLI jest potężne, ale jednocześnie wymaga nauczenia się odpowiednich komend, aby móc coś zdziałać. Jeszcze dziś znajdą się osoby, które nie wyobrażają sobie końca ery CLI.
Następuje era GUI – Graficznego Interfejsu Użytkownika. Jest to już bardziej przystępna opcja, z ikonami i okienkami, które można kliknąć. GUI uczyniło technologię dostępną dla każdego, kto potrafi wskazać i kliknąć. Tak więc ludzie stali się klikaczami. Na całe szczęście, nie tymi z "The Last of Us".
To jeszcze nie koniec ewolucji. Wkroczenie w świat API (Application Programming Interface) pozwoliło na komunikację między programami. API to takie dodatkowe drzwi do aplikacji lub systemu, które dają dostęp do określonych funkcji lub danych.
I wreszcie nadeszła era AI, gdzie zaczynamy rozmawiać z maszynami jak z ludźmi. Sztuczna inteligencja pozwala urządzeniom zrozumieć, co do nich mówimy, i odpowiadać w sposób, jakby odpowiedział znajomy.
Wyobraź sobie, że zamiast logować się na każdy switch osobno, wystarczy, że powiesz swojemu asystentowi, co ma zrobić, a on załatwi wszystko za ciebie. Asystent mógłby monitorować stan sieci, wprowadzać zmiany konfiguracyjne (najlepiej tylko pod naszą kontrolą) czy nawet diagnozować problemy na bieżąco, rozmawiając ze switchami indywidualnie. To tak, jakby mieć własnego cyfrowego inżyniera sieciowego, który nigdy nie śpi!
Skoro o wilku mowa, stworzymy asystenta AI, który będzie komunikować się ze switchami w sieci. Materiał ten został podzielony na dwie części: podstawową oraz rozszerzoną.
W części podstawowej nauczysz się budować asystenta, który będzie zdolny do wykonania jednej funkcji, na przykład sprawdzenia pewnych informacji na switchu.
Z kolei wersja rozszerzona, oferuje dodatkową funkcjonalność pozwalającą na konfigurację switchy. Ta rozszerzona wersja demonstruje, jak można stopniowo rozbudowywać możliwości asystenta, aby mógł wykonywać szerszy zakres zadań.
Pobierz pełny kod źródłowy!
Zachęcam do pobrania kodu źródłowego, dostępnego na dole tego artykułu lub klikając TUTAJ. Dostępny jest wyłącznie dla zalogowanych użytkowników.
Będę wdzięczny za rejestrację – to dla mnie sygnał, że to, co robię, ma sens i jest wartościowe dla was.
Spis treści
Wymagania
Do zbudowania własnego asystenta AI rozmawiającego ze switchami, będziemy potrzebowali kilku rzeczy:
Python
OpenAI API Klucz - https://platform.openai.com/
Switch Cisco Nexus - jeśli nie masz własnego, to instrukcje znajdziesz tutaj
Przykład zastosowania
Kod, który , który skupia się tylko na jednym zadaniu. Podejmuje decyzje o połączeniu się do switcha, łączy się do switcha i wyciąga odpowiednie dane, które pomogą mu odpowiedzieć użytkownikowi. Znajomość, jak zaimplementować taką logikę, która podejmuje decyzje i potrafi uruchomić jakąkolwiek funkcje wewnątrz naszego programu. Ta wiedza z pewnością przełoży się na realizację Twoich pomysłów. Chociażby Tworzenie własnego lub zespołowego asystenta, który zaoszczędzi wiele czasu i da sporą frajdę podczas tworzenia. Z pewnością ten mały element w całym mechanizmie jest wart zrozumienia, jak to działa.
Sandbox i Cisco Nexus Switch Serii 9000
Istotnym elementem w całej układance jest stabilne środowisko testowe, które pozwoli skupić się na meritum, czyli pisaniu kodu. Nie będziemy zajmowali się instalowaniem EVE-NG, GNS3 lub innych narzędzi pozwalających na wirtualizację urządzeń. Prawda jest taka, że jest to czasochłonne i bardzo często zniechęcające, zwłaszcza kiedy wydaje ci się, że już wszystko działa, a w tym samym momencie Twój wirtualny Cisco LAB „krzyczy” Prima Aprilis.
Ponieważ sam miałem z tym trudności, chcę zaoszczędzić trochę Twojego czasu, co pozwoli Ci od razu zabrać się za to, po co tutaj przyszedłeś.
Kiedy jedni mówią Cisco to nie wszsytko, ja powiem dzięki Cisco za to wszystko
Wejdź na https://developer.cisco.com i zaloguj się. Jeśli nie posiadasz konta to załóż.
Następnie uruchom Sandoxa klikając Build / Lunch Sandbox. Zostaniesz przeniesiony do katalogu ze środowiskami, z których możesz skorzystać.
Wpisz w searchu nx-os i uruchom sandboxa
Sandbox, który został właśnie uruchomiony składa się tylko z jednego Cisco Nexus switcha N9k.
Dostęp do niego jest natychmiastowy i nie trzeba łączyć się po VPN, by zacząć z niego korzystać. Połącznie po VPN jest niezbędne w przypadku korzystania z innych Cisco Sandboxów.
Dane do logowania znajdują się po prawej stronie GUI Sandboxa.
W Twoim przypadku może być podany inny host, natomiast jako ciekawostkę podpowiem, że jeśli zalogujesz się na sbx-nxos-mgmt.cisco.com przez SSH, bez rezerwowania Sandboxa, powinieneś bez problemu uzyskać dostęp do Nexus v9000 Switch. Przynajmniej tak było, kiedy pisałem tego posta. Jednakże polecam dokonywanie rezerwacji za każdym razem, kiedy korzystasz z Sandboxa.
Asystent AI - Mapa logiki
Oto, jak powinniśmy zaimplementować logikę w wersji podstawowej, która pozwoli nam wykonać zadanie. Chciałbym jednak zwrócić uwagę, że przedstawione rozwiązanie nie jest idealne i służy jedynie ilustracji idei asystenta, który ma możliwość wywoływania innych funkcji. Taka logika może być realizowana przy użyciu różnych narzędzi.
Nasz guru sieci będzie wysyłał zapytania i otrzymywał odpowiedzi. Tym guru sieci jesteśmy my. Kiedy nasz asystent AI otrzyma zapytanie, zostanie ono przesłane do OpenAI. Tam zapadnie decyzja, czy OpenAI powinno bezpośrednio udzielić odpowiedzi na pytanie, czy też powinna zostać zwrócona nazwa funkcji. Użyjemy w tym celu mechanizmu wywołania funkcji (z angielskiego: function calling), który wybierze funkcję, którą następnie nasz asystent uruchomi wewnątrz naszego programu.
Zanim to się stanie, musimy sprawdzić, czy zwrócono nazwę funkcji. Jeśli nie, odpowiedź od OpenAI zostanie bezpośrednio dostarczona do naszego super network engineer, czyli do nas. Jeśli jednak otrzymamy nazwę funkcji, wszystkie dane zostaną przekazane do kolejnej funkcji odpowiedzialnej za uruchomienie tej funkcji. W naszym przypadku będzie to funkcja, która łączy się z Cisco Nexus Switchem przez API.
Następnie output ze switcha wraz z pierwotnym pytaniem trafi ponownie do OpenAI, gdzie zostanie udzielona odpowiedź na podstawie dostarczonych danych, która trafi z powrotem do nas.
Wersja rozszerzona asystenta przedstawia dodatkowy moduł zaznaczony gwiazdką na powyższym rysunku
Asystent AI wersja podstawowa - Omówienie kodu
Budowanie asystenta powinno się rozpocząć od zainstalowania niezbędnych bibliotek. Możesz to zrobić za pomocą poniższego polecenia:
Instalacja tych pakietów przygotuje środowisko do dalszej pracy.
Zarządzanie i przechowywanie klucza API
Dostęp do usług OpenAI wymaga klucza API, który znajdziesz na stronie https://platform.openai.com w zakładce API Keys. Jeśli nie posiadasz jeszcze klucza, możesz go wygenerować. Pamiętaj o bezpiecznym przechowywaniu swojego klucza API.
Klucze API, hasła i inne wrażliwe dane nigdy nie powinny być przechowywane bezpośrednio w kodzie źródłowym. Zalecam utworzenie pliku .env w katalogu z Twoim projektem, aby bezpiecznie przechowywać takie informacje. Jeśli planujesz wysłać swój kod na GitHuba, upewnij się, że plik .env nie zostanie dołączony do repozytorium.
Kiedy już skonfigurujesz plik .env, klucz, który tam umieścisz, będzie dostępny w Twoim kodzie jako zmienna środowiskowa. Możesz odnieść się do niej w swoim kodzie, korzystając z pakietu python-dotenv, który pozwoli bezpiecznie załadować wartość tej zmiennej.
Odwołanie do zmiennej w pliku .env odbywa się poniższym kodem
Decyzyjność asystenta
Żyjemy w świecie, gdzie codzienne decyzje przeplatają się z niepewnością. Co by było, gdyby asystenci AI mogli podejmować decyzje za nas? Czy mogliby wtedy całkowicie zastąpić ludzką interwencję? Odpowiedź brzmi: nie! Choć pojęcie ogólnej sztucznej inteligencji (AGI) fascynuje wyobraźnię, to jednak powinniśmy myśleć w kategoriach tego, jak AI pomaga ludziom, a nie zastępuje ich.
W ramach tego podejścia, istotną funkcją naszego asystenta AI jest wywoływanie funkcji, czyli tzw. function calling. Mechanizm ten pozwala asystentowi na dynamiczne reagowanie na zadane mu pytania poprzez wybór i uruchomienie odpowiedniej funkcji z wcześniej zdefiniowanego zestawu. Dzięki temu asystent nie tylko przetwarza dane, ale również aktywnie uczestniczy w procesie decyzyjnym, dostosowując swoje działania do kontekstu zapytania. W dalszej części omówimy, jak ten proces wygląda w praktyce.
Sekcja importów
Na początku kodu znajduje się seria importów, które są niezbędne do działania aplikacji:
Każdy z tych importów spełnia określoną rolę:
requestsijsonsłużą do zarządzania zapytaniami HTTP oraz manipulacji danymi w formacie JSON.osiload_dotenvpozwalają na ładowanie konfiguracji z plików środowiskowych, co jest kluczowe do przechowywania poufnych danych (np. klucze API) w sposób bezpieczny.OpenAIto biblioteka klienta, która umożliwia interakcję z OpenAI.
Konfiguracja klienta OpenAI
Następnie widzimy załadowanie zmiennych środowiskowych i konfigurację klienta OpenAI:
Te linie kodu odpowiadają za załadowanie danych konfiguracyjnych z pliku .env oraz inicjalizację klienta OpenAI z użyciem klucza API, który jest pobierany ze zmiennych środowiskowych.
Funkcja make_decision()
Główną funkcją w kodzie jest make_decision(), która przyjmuje dane wejściowe użytkownika i na ich podstawie korzysta z OpenAI do podjęcia decyzji.
W tym fragmencie kodu definiowane są narzędzia (tools), które OpenAI może wykorzystać do realizacji różnych zadań. Każde narzędzie określa funkcje, które można wykonać, wraz z ich parametrami. Przykład prezentuje, jak OpenAI, otrzymując od nas zapytanie, analizuje je, uwzględniając:
systemowy prompt, który zawiera opis zasad i możliwości asystenta;
sekcję
tools, w tym nazwę funkcji"name": "get_info_from_devices"oraz opis parametrówdevice_ipsishow_cmd.
Dzięki temu OpenAI rozumie cel funkcji i, jeśli pytanie dotyczy wywołania funkcji (w sposób pośredni oczywiście), zwracana jest nazwa funkcji wraz z jej parametrami.
Wywołanie modelu AI i przetwarzanie odpowiedzi
Kolejne linie kodu dotyczą wywołania modelu AI i przetwarzania jego odpowiedzi:
W tej części kodu wykonujemy zapytanie do OpenAI, przekazując mu opisane narzędzia oraz dane wejściowe użytkownika. Model AI analizuje dane i zwraca odpowiedź, która może zawierać wywołania funkcji lub bezpośrednią odpowiedź.
Jeśli przyjrzymy się temu bliżej, to można dostrzec, że w naszym programie (asystencie) za każdym razem przechwytujemy dwie rzeczy:
odpowiedź od asystenta AI (
ai_response) - Jest to bezpośrednia odpowiedź od OpenAI. Na przykład OpenAI odpowiada czym jest OSPF.informacje o wywołanych funkcjach (
tool_calls). Przykładowo, jeśli zapytamy OpenAI o sprawdzenie czy na switchu core-switch-01 jest skonfigurowany vlan 13, to OpenAI będzie wiedział, że musi zwrócić nazwę funkcji wraz z wymaganymi atrybutami .
Obsługa odpowiedzi AI
Ostatni segment kodu odpowiedzialny jest za obsługę odpowiedzi od AI:
Naszym zadaniem jest stworzenie kodu odpowiedzialnego za właściwe reagowanie na odpowiedzi otrzymane od OpenAI. Kod najpierw sprawdza, czy lista tool_calls nie jest pusta, co oznacza, że OpenAI zwróciło nazwę funkcji do wywołania. Jeśli lista zawiera elementy (if tool_calls:), wyciągamy nazwę funkcji ( function_name ) i argumenty ( arguments .
W funkcji function_run() użyłem składni **arguments, co pozwala na przekazanie argumentów w formie słownika. Zdecydowałem się na to rozwiązanie, aby uniknąć sztywnego definiowania parametrów funkcji function_run(). Opcja **arguments zapewnia elastyczność, pozwalając na przyjęcie różnej liczby argumentów. Chociaż w naszym przypadku moglibyśmy przekazać parametry bezpośrednio, np. function_run(device_ips, show_cmd, function_name), to jednak dodanie kolejnych funkcji w narzędziu tools (omawianej tutaj) z różną liczbą argumentów stanowiłoby wyzwanie. Na przykład, funkcja get_info_from_devices zwraca dwa argumenty ( device_ips i show_cmd). Gdyby inne funkcje zwracały mniej lub więcej niż dwa argumenty, to nasz program nie działałby poprawnie.
Dlatego zastosowanie składni **arguments zapewnia elastyczność na przyszłość, umożliwiając łatwe dostosowanie się do zmieniających się wymagań poprzez modyfikację kodu wewnątrz naszego programu.
Skupiając się teraz na arguments["function_name"] = function_name, można zauważyć, że do już istniejącego słownika arguments, który zawiera device_ips i show_cmd, dodawana jest function_name. W rezultacie w słowniku znajdują się trzy argumenty, które następnie są przekazywane do funkcji function_run(). Proces odwoływania się do tych argumentów oraz sposób ich przekazywania zostanie szczegółowo opisany w następnej sekcji, która wyjaśnia, jak dokonuje się wywołania funkcji zwróconej przez OpenAI.
Wywołanie funkcji zwróconej przez OpenAI
OpenAI może zdecydować, czy powinna zostać uruchomiona jakaś funkcja, jednak samo jej uruchomienie nie leży w jego kompetencjach. Jak już zdążyłeś zauważyć, drogi czytelniku, OpenAI zwraca tylko nazwę funkcji wraz z jej atrybutami. Aby uruchomić wskazaną przez OpenAI funkcję, należy napisać kod, który odpowiednio na to zareaguje. Tym właśnie zajmiemy się w tej sekcji.
Mapowanie funkcji i pobieranie nazwy funkcji
Kolejnym etapem jest stworzenie modułu odpowiedzialnego za wywołanie funkcji zwróconej przez OpenAI. Pierwszą czynnością, którą musimy wykonać, jest zaimplementowanie mapowania nazwy funkcji zwróconej przez OpenAI na rzeczywistą nazwę funkcji, która będzie wykonywana za każdym razem, gdy OpenAI zwróci określoną nazwę funkcji. Na przykład, jeśli OpenAI zwróci ciąg znaków „get_info_from_devices”, w poniższym przykładzie jest on przypisany do funkcji get_info_from_devices.
Następnie pobieramy jeden z przekazanych argumentów, nazwę funkcji zwróconej przez OpenAI, używając klucza z **arguments. Chodzi o function_name = arguments.get("function_name") z powyższego przykładu.
Obsługa wywołania funkcji
Sprawdzamy, czy nazwa funkcji zwróconej od OpenAI (function_name) znajduje się w function_map. W przeciwnym wypadku wygeneruje się błąd informujący o nieznanej funkcji.
Jeśli funkcja zostanie poprawnie rozpoznana, to przypisujemy ją do zmiennej func_to_call, która następnie wraz z argumentami ( **arguments ) opakowanymi w słownik, zostanie wywołana, a wynik zwrócony do response_from_fc. Wynikiem w tym przykładzie jest output ze switcha. Funkcja get_info_from_devices() odpowiedzialna za łączenie się ze switchem jest omówiona w następnej sekcji.
Ponowne wywołanie modelu AI i przetwarzanie odpowiedzi
Jako użytkownicy korzystający z asystenta AI oczekujemy odpowiedzi podobnej do tej, jaką moglibyśmy otrzymać od kolegi, który sprawdziłby co dzieje się na urządzeniu i odpowiedziałby w ludzkim języku, a nie tylko outputem. W związku z tym, musimy ponownie wysłać do OpenAI pierwotne pytanie wraz z odpowiedzią otrzymaną od switcha oraz dodatkowym promptem, który przypomina asystentowi o jego roli. Te dane, wraz z modelem GPT, znajdują się w słowniku follow_up_query.
W follow_up_query znajdują się trzy role:
system, która definiuje zachowanie asystenta. Zawiera ona bardzo prosty jednozdaniowy prompt.user, gdzie wysyłamy nasze pierwotne pytanieassistant, która przyjmuje odpowiedź z switcha. Ta rola obejmuje wykonywanie zadań i dostarczanie informacji opartych na wcześniejszych instrukcjach i danych wejściowych.
Odpowiedź od modelu AI
follow_up_response = client... inicjuje połączenie z OpenAI, dostarczając wszystkie potrzebne dane z follow_up_query.
Odpowiedź od OpenAI jest przechwytywana i zapisywana do zmiennej follow_up_response, która następnie przekazuje zawartość do zmiennej answer (która została stworzona na potrzeby zrobienia poprawnego scrrenshota wycinka kodu 🙂
Wynik, czyli odpowiedź jest zwracana printem do nas użytkowników.
W linii, gdzie znajduje się response_from_fc = func_to_call(**arguments)łączyliśmy się ze switchem, natomiast póki co nie zostało to omówione. Dlatego następna sekcja w pełni jest skupiona na funkcji get_info_from_devices() .
Łączenie się ze switchem
Na tym etapie już wiesz jak działa logika naszego asystenta, który potrafi rozmawiać, ze switchami. Natomist ostatnim elementem jest napisanie kodu, który wykorzustując nx-api łączy się ze switchem, żeby wyciągnąć z niego interesujący asystenta output.
Wczytywanie argumentów
Podczas wykonywania funkcji get_info_from_devices(), przekazywany słownik (**kwargs) zawiera między innymi device_ips, czyli nazwę lub IP switcha, oraz show_cmd, czyli komendę show, która jest używana do uzyskania danych ze switcha.
Mechanizm weryfikacji typu zwróconej nazwy urządzenia.
Kiedy tworzyłem ten materiał, OpenAI czasami zwracało mi nazwę switcha raz jako string, a innym razem jako listę.
przykład stringa: {'device_ips': 'sbx-nxos-mgmt.cisco.com', …}
przykład listy: {'device_ips': ['sbx-nxos-mgmt.cisco.com'], …}
Aby poradzić sobie z tym drobnym, lecz potencjalnie katastrofalnym problemem, napisałem kod, który sprawdza, czy device_ips jest listą czy stringiem.
Uwierzytelnienie się do switcha
Jeśli chodzi o uwierzytelnianie się do switcha Cisco Nexus za pomocą API, dostępne są trzy metody: za pomocą certyfikatu, loginu i hasła oraz tokena. W tym przykładzie postanowiłem skorzystać z opcji środkowej, czyli uwierzytelniania loginem i hasłem.
Podobnie jak w przypadku klucza OPENAI_API_KEY, dane do logowania (CISCO_USER) oraz hasło (CISCO_PASSWD) są przechowywane w pliku .env.
Payload
W sekcji Payload został wybrany output format jako json. Jedna istotna kwestia. Jeśli przewidujemy użycie komend zawierających pipe (kreskę pionową), powinniśmy użyć cli_show_ascii. W przypadku wyboru cli_show, symbol pipe nie będzie obsługiwany przez API. do input przekazana jest komenda show przypisana jako string do show_cmd .
Łączenie się ze switchem
Łączymy się ze switchem, przekazując url, payload, nagłówki, autentykując się za pomocą loginu i hasła. Odpowiedź ze switcha jest zapisywana w zmiennej response.
Weryfikacja odpowiedzi
Jeśli zostanie zwrócony kod 200, wtedy output ze switcha jest zwracany. W przeciwnym razie zwracany jest błąd, który również jest informacją dla OpenAI mówiącą o problemie z uzyskaniem danych ze switcha.
Uruchomienie Asystenta
Sprawdzenie kodu czy działa to jak zjedzenie torta po zdmuchnięciu świeczek. Zatem Wysłanie zapytania do asystenta odbywa się w prosty sposób, poprzez wywołanie funkcji make_decision():
Podsumowanie wersji podstawowej
Logika, którą przedstawiłem, pokazuje, jakie mechanizmy należy wykorzystać i w jaki sposób je zastosować, aby stworzyć funkcjonalność, która zapewni asystentowi dodatkowe możliwości, takie jak podejmowanie decyzji, na podstawie których nasz program (asystent) odpowiednio zareaguje. Przydałoby się zaimplementować kolejną funkcjonalność, dzięki której nasz asystent mógłby na przykład przeprowadzić konfigurację. Z pewnością wiedza o tym, jak dodawać kolejne funkcjonalności do naszego asystenta, pomoże wam zrozumieć, jakie elementy należy dodać i jakie zmienić, aby asystent działał poprawnie. Jeśli jesteś zainteresowany, zapraszam do zapoznania się z dodatkową funkcjonalnością (dostępną tylko dla zalogowanych użytkowników mojego newslettera, do którego link znajdziecie w opisie pod filmem.
Dodatkowa funkcjonalność, czyli rozszerzona wersja asystenta
W tej sekcji rozbudujemy nasz program o możliwość konfiguracji urządzeń sieciowych. Dzięki temu zobaczysz, jak asystent, wykorzystując technologię OpenAI, samodzielnie decyduje, którą funkcję zastosować. Poznanie tego procesu pozwoli Ci w przyszłości skutecznie wprowadzać nowe funkcje, identyfikować elementy wymagające zmian oraz dodawać niezbędne komponenty w kodzie naszego programu.
Wprowadzanie zmian w sercu asystenta
Zaczniemy od dodania funkcji w tools oraz zmiany systemowego promptu. Obecnie w tools mamy funkcje get_into_form_devices z dwoma atrybutami (device_ips i show_cmd). Stworzymy kolejną funkję configure_devices() odpowiedzialną za konfiguracje urządzeń.
Add configrure_devices function to tools
Podobnie jak get_info_from_devices, nowa funkcja configure_devices() będzie wymagała dwóch parametrów: device_ips reprezentującego adresy IP lub nazwy urządzeń, oraz configuration_cmd, który będzie listą komend konfiguracyjnych.
Zauważ, że atrybut configuration_cmd jest typu tablica (array), która powinna zawierać stringi. Dzięki temu każda komenda zostanie dodana jako nowy element (string) na liście.
Configuration_cmd zawiera dwa ciągi znaków (stringi), które później będziemy musieli odpowiednio zmienić, by funkcja odpowiedzialna za łączenie się z naszym switchem mogła zaakceptować format dostarczonych komend. Wrócimy do tego w momencie omawiania tamtej funkcji.
Nowy prompt systemowy
Ponieważ dodaliśmy nową funkcjonalność, to nowy prompt również musiał zostać nieznacznie zmieniony.
Zmiany między dwoma tekstami odnoszą się głównie do rozszerzenia możliwości i dostosowania zakresu działania, a także do większego nacisku na jasność i wskazówki:
Rozszerzenie możliwości: Pierwszy tekst wprowadza nowe funkcje konfiguracji urządzeń, które są dużą zmianą w porównaniu do drugiego tekstu, który wskazuje na wyraźne ograniczenia w tej dziedzinie.
Specyfika używania funkcji: Oba teksty podkreślają specyfikę użycia funkcji, ale robią to inaczej. Pierwszy tekst szczegółowo opisuje funkcje odpowiednie dla konkretnych zadań, takie jak pobieranie informacji i konfiguracja urządzeń.
Wskazówki i jasność: Zaktualizowany tekst jest bardziej szczegółowy w wyjaśnianiu, co AI może robić i jak powinno być używane, podkreślając znaczenie dostarczania pełnych informacji.
Radzenie sobie z niekompletnymi informacjami: Obie wersje podkreślają unikanie założeń, gdy dostarczone informacje są niewystarczające, ale pierwszy tekst opisuje bardziej efektywne wykorzystanie określonych informacji.
Cel i efektywność operacyjna: Zaktualizowany tekst również podkreśla rolę AI w zwiększaniu efektywności i dokładności, sugerując nacisk na doskonałość operacyjną i bezpieczeństwo.
Podsumowując, zmiany zwiększają funkcjonalność AI, pozwalają na obsługę szerszego zakresu zadań i poprawiają wskazówki dotyczące jego użycia przez użytkowników
Nowy prompt systemowy dla follow_up_querry
Nasz asystent dwukrotnie nawiązuje połączenie z OpenAI podczas interakcji ze switchem, niezależnie od tego, czy dotyczy to sprawdzania czegoś czy przeprowadzania konfiguracji. Jest to niezbędne, by uzyskać odpowiedzi, które spełniają oczekiwania na poziomie ludzkiej interakcji. Wprowadzenie funkcji konfiguracji switcha sprawiło, że pierwotny prompt okazał się niewystarczający. Zamiast jednoznacznych odpowiedzi, asystent czasami zwracał jedynie status, innym razem dostarczał szczegółowy opis wykonanych działań bez informacji o poprawności wykonanej konfiguracji. W odpowiedzi na te wyzwania, dostosowałem prompt, aby lepiej odpowiadał na nasze potrzeby.
Z tego powodu istotne jest, aby pamiętać o odpowiednim dostosowywaniu promptów do bieżących potrzeb. W przyszłości zamierzam przygotować materiał na temat tworzenia efektywnych promptów, co jest istotnym wyzwaniem, którego nie można zignorować.
Dodanie nowej funkcji do mapowania
Nowa funkcja musi być dodana w function_map, żeby mogła być wywołana, kiedy OpenAI zwróci nazwę funkcji “configure_devices”
Funkcja konfiguracji switchy
Funkcja konfiguracji switchy rózni się od funkcji get_info_from_devices przedewszystkim payloadem oraz inputem, czyli formatem przyjmowanych komend. W zasadzie chodzi o sytuacje przyjmowania wiecej niż jednej komendy konfiguracyjnej. cała reszta kodu tej funkcji jest taka sama jak get_info_from_devices. Poniższy snipped ma powstawiane … w miejscu, gdzie kod został usunięty na cel omówienia tej sekcj.
Chcemy skonfigurować switch, dlatego parametr type musi być ustawiony na cli_conf, a output_format powinien pozostać bez zmian, czyli jako json. W strukturze danych dodano nowy element - rollback, który oferuje trzy opcje:
stop-on-error, aby zatrzymać proces w przypadku wystąpienia błędu,continue-on-error, aby kontynuować mimo błędu,rollback-on-error, aby zainicjować cofanie zmian w przypadku błędów konfiguracji.
Pole input akceptuje ciągi znaków. Jeżeli jest więcej niż jedna komenda, powinny być one oddzielone średnikiem ;. Zatem ponieważ configuration_cmd to lista zawierająca komendy w postaci stringów, należy oddzielić je średnikiem.
W rezultacie, command_string powinien wyglądać następująco: vlan 13; name AI_Fresh_vlan.
Asystent konifguruje switcha - testowanie
Dotarliśmy znowu do etapu, gdzie można "zjeść torta". Sprawdźmy, co zrobi asystent, jeśli poprosimy go o skonfigurowanie VLANu numer 13 – VLAN, który konfigurowaliśmy już wcześniej. Dlatego najpierw musimy poprosić asystenta o usunięcie VLANu 13:
Wynik:
Tak jak na drogach, kiedy prowadzimy samochód, obowiązuje zasada ograniczonego zaufania, tak nie ufajmy asystentowi. Sprawdzamy więc, czy na switchu rzeczywiście nie ma już VLANu 13.
Okazuje się, że asystent jest wiarygodny. Poprośmy go teraz o skonfigurowanie VLANu 13 z nazwą AIFRESH:
Wynik ze switcha:
Asystent wykonuje polecenia poprawnie i dostarcza oczekiwane rezultaty. Otrzymaliśmy ładną odpowiedź od asystenta oraz potwierdzialiśmy, czy rzeczywiście konfiguracja przebiegła pomyślnie.
Podsumowanie dodatkowej funkcjonalności
Pamiętajmy, że nie jest to rozwiązanie produkcyjne, ponieważ z pewnością nie chcielibyśmy, aby asystent samodzielnie wybierał i wprowadzał komendy konfiguracyjne do naszych urządzeń. Taka sytuacja mogłaby mieć niepożądane konsekwencje. Oczywiście, nie oznacza to całkowitej rezygnacji z takich możliwości. Jeżeli zależy Ci na tym, aby asystent mógł dokonywać zmian na urządzeniach, powinny być wdrożone odpowiednie mechanizmy kontrolne. Następnie inżynier powinien przejrzeć przygotowaną konfigurację i zatwierdzić jej wprowadzenie. Dodatkowo, komendy konfiguracyjne powinny być opracowane z wcześniej zaprojektowanych przez nas szablonów, do których asystent będzie mógł się odwoływać.
Podnosząc temat automatyzacji i sztucznej inteligencji, warto skupić się na standaryzacji i zaczynać od prostych, powtarzalnych czynności. To nie tylko ułatwi wprowadzenie nowych technologii, ale również przyniesie wiele korzyści. Inżynierowie zostaną odciążeni od monotonnych zadań, co pozwoli zaoszczędzić czas i zmniejszyć ryzyko błędów ludzkich.
Kod Źródołowy
(dostępny wyłącznie dla zalogowanych)
Reply