Jednostki
1. Co to jest RAG i dlaczego jest konieczny? 2. Osadzanie i logika wektorowych baz danych 3. Porcjowanie i przygotowanie dokumentów 4. Strategie odzyskiwania: Top-k, Hybrid, Re-ranking 5. Architektura asystenta, która komunikuje się z danymi firmy 6. Kontrola dostępu, szablon podpowiedzi i zarządzanie rozmowami 7. Redukcja halucynacji i reprezentacja zasobów 8. Ocena i monitorowanie RAG 9. Agenci AI i użycie narzędzi 10. Przepływy pracy agentów i zadania wieloetapowe 11. Bezpieczeństwo agentów, prywatność, etyka i wdrażanie
Jednostka 9 / 11

Agenci AI i użycie narzędzi

Zyski:

  • Zdefiniowanie agenta jako „model + narzędzia + pętla” i podjęcie decyzji, kiedy jest on potrzebny
  • Zapisanie definicji narzędzia z nazwą, opisem i schematem_wejściowym
  • Monitorowanie przepływu i obsługi błędów pętli Tool_use i Tool_result

Do tej pory model zawsze wykonywał jedno zadanie: odbierał wprowadzany tekst i generował odpowiedzi tekstowe. Ale prawdziwa praca często wymaga czegoś więcej niż tylko tekstu; wykonanie obliczeń, zapytanie do bazy danych, wywołanie API, sprawdzenie aktualnego kursu wymiany. Modelka nie może zrobić tych rzeczy sama, ale może zdecydować, kiedy należy to zrobić i poprosić kogoś, aby to zrobił. To właśnie daje model użycie narzędzia i to jest podstawa agentów AI. W tej części dowiemy się, czym jest agent, jak zdefiniowane jest narzędzie i jak działa pętla Tool_use.

Co to jest agent? Model + Narzędzia + Pętla

Agent AI składa się z trzech części: modelu (mózg, który podejmuje decyzję), narzędzi (funkcje, które model może wywołać: pogoda, zapytanie do bazy danych, wysyłanie wiadomości e-mail) i pętli (pętla; model wywołuje narzędzie, otrzymuje wynik, ponownie decyduje, co zrobić itd.).

Krytyczne rozróżnienie: pojedyncze wywołanie wzorca nie jest agentem. Agent to proces, w którym model postępuje krok po kroku, na każdym kroku wybierając kolejny ruch w oparciu o wynik narzędzia. „Myśl jak człowiek, użyj rąk, spójrz na wynik, pomyśl jeszcze raz”.

Ważny fakt: sam model nie obsługuje pojazdu. Model po prostu mówi: „Chcę wywołać to narzędzie z tymi danymi wejściowymi”. Twoja aplikacja (zwana wiązką) uruchamia narzędzie i zwraca wynik do modelu. Jest to istotne ze względów bezpieczeństwa: model nie dotyka bezpośrednio Twojego systemu; Każde działanie jest pod Twoją kontrolą.

Wskazówka: Nie próbuj rozwiązywać każdego problemu za pomocą agenta. Agent; zwiększa ryzyko opóźnień, kosztów i błędów. Najpierw zapytaj: „Czy problem zostanie rozwiązany za pomocą jednej rozmowy telefonicznej, czy w ramach ustalonego przepływu pracy?” Jeśli odpowiedź brzmi „tak”, agent nie jest potrzebny. Agent przeznaczony jest do zadań otwartych, których kroki nie są znane z góry.

Definicja narzędzia: nazwa, opis, schemat_wejściowy

Aby wprowadzić narzędzie do modelu, podajesz trzy rzeczy:

  • nazwa: Identyfikator pojazdu, np. get_pogoda.
  • opis: Co robi narzędzie i kiedy je wywołać. To najważniejszy obszar, który pozwala modelowi wybrać odpowiednie narzędzie we właściwym czasie. Napisz nie tylko „co robi”, ale także „zadzwoń, kiedy”.
  • input_schema (input schema): schemat JSON określający, jakich parametrów oczekuje narzędzie i jakiego typu.

# Definicja pojazdu (koncepcyjna — schemat JSON){ "name": "get_order_status", "description": "Pobiera aktualny status wysyłki zamówienia. Wywołaj, gdy użytkownik zapyta, gdzie znajduje się numer zamówienia lub kiedy dotrze.", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "Numer zamówienia, np. SP-1024"} }, "wymagane": ["numer_zamówienia"] }}

Zasady dobrego opisu narzędzia: jasna i zwięzła nazwa, opis z informacją „kiedy używać”, opis każdego parametru, podanie tych naprawdę obowiązkowych. Utrzymuj koncentrację na liczbie pojazdów; Dziesiątki podobnych modeli pojazdów zaskakują.

obszar

Co to robi?

dobry przykład

zły przykład

imię

Identyfikator pojazdu

status_zamówienia_getir

przynieść

opis

Co robi + kiedy zadzwonić

"Zwraca status ładunku; zadzwoń, gdy użytkownik zapyta, gdzie jest zamówienie"

„pobiera dane”

schemat_wejściowy

Typ parametru i wymagania

{order_no: string, z adnotacją}

brak schematu/brak opisu

narzędzie_use → wynik_narzędzia Pętla

Cykl wygląda następująco, krok po kroku:

  1. Wysyłasz pytanie użytkownika + opisy narzędzi do modelu.
  2. Model albo odpowiada bezpośrednio, albo generuje blok Tool_use: „wywołaj Order_durumu_getir z Order_no=SP-1024”.
  3. Twoja aplikacja faktycznie uruchamia narzędzie (zapytanie bazy danych).
  4. Wynik wysyłasz z powrotem do modelu jako wynik_narzędzia.
  5. Dzięki temu wynikowi model albo generuje ostateczną odpowiedź, albo wywołuje inne narzędzie. Cykl trwa, dopóki model nie powie: „Skończyłem”.

# Pętla agenta (koncepcyjna)messages = [user_question]while True: odpowiedź = model.uret(wiadomości, narzędzia=definicje_narzędzia) if respond.tur == "tool_use": wynik = Harley.run(odpowiedź.nazwa_narzędzia, odpowiedź.entries) # APLIKACJA uruchamia komunikaty += [odpowiedź, wynik_narzędzia(wynik)] # zwróć wynik else: przerwa # ostateczna odpowiedź; pętla się kończy

Nowoczesne pakiety SDK oferują narzędzia do uruchamiania tej pętli za Ciebie; po prostu piszesz funkcje narzędzia. Ale właśnie to dzieje się za kulisami.

Zarządzanie błędami

Narzędzia mogą zawieść: nie znaleziono zamówienia, przekroczono limit czasu API, dane wejściowe są nieprawidłowe. Jeśli nie możesz uruchomić narzędzia, zwróć błąd do modelu jako opisowy wynik_narzędzia („błąd: nie znaleziono numeru zamówienia SP-9999”) i flagę błędu. Model może to zobaczyć i delikatnie wyjaśnić użytkownikowi lub spróbować inaczej. Nie przełykaj błędu i nie zwracaj pustych wyników; Modelka musi wiedzieć, co poszło nie tak.

Słaby/silny opis pojazdu

Słabe (rzeczownik nieokreślony, bez „kiedy”):

nazwa: „dane”, opis: „pobiera dane”# Model nie wie, kiedy i jak wywołać; Albo w ogóle nie dzwoni, albo dzwoni błędnie.

Silny (nazwa sieci + kiedy + opis parametru):

nazwa: "musteri_bakiyesi_getir"description: "Zwraca aktualny stan konta klienta. Dzwoń, gdy użytkownik poprosi o debet, kredyt lub saldo. NIE DOKONUJE płatności."input_schema: {custeri_id: string ("Customer ID")}# Model wywołuje we właściwym czasie, z właściwymi parametrami, znając swój limit.

Trzy mini etui

Przypadek 1 — Niepotrzebny agent. Jeden zespół zbudował biznes „podsumowania tekstu” za pomocą agenta wielofunkcyjnego; Każde podsumowanie zajmuje 4 rozmowy z modelami i 9 sekund. Ta praca była właściwie pracą na jedną rozmowę. Gdy usunęliśmy agenta i ograniczyliśmy go do jednej rozmowy, czas skrócił się do 1,5 sekundy, a koszt do jednej czwartej. Lekcja: używaj agenta, gdy jest to naprawdę konieczne.

Przypadek 2 – Słabe wyjaśnienie, błędne wezwanie. W agencie wsparcia model losowo wywoływał mało znane narzędzie zwane fetch, zarówno w pytaniu dotyczącym salda, jak i pytania o wysyłkę. Po podzieleniu pojazdów na Balance_getir i cargo_durumu_getir oraz dodaniu wyjaśnień „zadzwoń, kiedy” liczba błędnych wyborów pojazdów spadła z 18 do 1 na 50 przykładów.

Przypadek 3 – Błąd przełknięty. Agent zwracał puste wyniki, gdy nie znaleziono zamówienia; Model zinterpretował to jako „zamówienie zostało dostarczone” i wprowadził klienta w błąd. Kiedy komunikat o błędzie jest jawnie zapisany w narzędziu_result („nie znaleziono zamówienia”), model poprawnie mówi: „Nie mogłem znaleźć tego numeru, czy możesz go sprawdzić?” zaczął mówić.

Typowe błędy

  • Zwrócenie wszystkiego na agenta: chociaż jedno połączenie wystarczy, agent zwiększa koszty i opóźnienia.
  • Niejasny opis pojazdu: Model nie wie, kiedy zadzwonić; wybiera źle.
  • Myślenie, że model steruje pojazdem: Uprząż steruje pojazdem; model po prostu chce.
  • Przełknięcie błędu: model musi wiedzieć, co poszło nie tak; Podaj błąd jako otwarty wynik_narzędzia.
  • Zbyt wiele podobnych pojazdów: model się myli; Utrzymuj zestaw narzędzi skupiony i minimalny.
Uwaga: To, że model mówi „zadzwoń do tego pojazdu”, nie oznacza, że ​​należy podjąć działanie. W przypadku narzędzi destrukcyjnych (usuwanie, sprawdzanie, e-mail) aplikacja nie powinna na ślepo wykonywać wywołania — jest to sedno tematu bezpieczeństwa w następnej części.

Podsumowując

  • Agent = model (decyzja) + narzędzia (funkcje) + pętla (wywołaj narzędzie, uzyskaj wynik, zdecyduj ponownie).
  • Pojedyncze wywołanie wzorca nie jest agentem; agenta to proces krok po kroku.
  • Model nie prowadzi pojazdu; Twoja aplikacja działa (wiązka przewodów) i zwraca wynik jako wynik_narzędzia.
  • Narzędzie jest identyfikowane po nazwie, opisie (w szczególności „wywołaj, kiedy”) i schemacie_wejściowym.
  • Pętla trwa, gdy użycie_narzędzia → przebieg wiązki → wynik_narzędzia → model trwa, dopóki model nie powie „gotowe”; błędy są jawnie zgłaszane do modelu.

Zadanie aplikacji

Zaprojektuj 3 narzędzia z własnej firmy, które możesz przekazać agentowi. (1) Wpisz nazwę, opis z „zadzwoń, kiedy” i schemat_wejściowy dla każdego; Niech przynajmniej jedno będzie narzędziem do nieniszczącego czytania, a drugie narzędziem do obliczeń. (2) Wybierz realistyczne pytanie użytkownika i ręcznie napisz krok po kroku (w pętli), które z tych narzędzi model wywoła, z jakimi danymi wejściowymi i co zrobi po nadejściu wyniku narzędzia. (3) Przygotuj scenariusz, w którym jedno z narzędzi zawiedzie, i pokaż, w jaki sposób komunikat o błędzie powróci do modelu.

lista kontrolna

  • [ ] Mogę zdefiniować agenta jako „model + narzędzia + pętla” i decydować, kiedy jest on potrzebny.
  • [ ] Wiem, że wiązka steruje pojazdem, model po prostu tak chce.
  • Potrafię napisać solidny opis pojazdu zawierający [ ] nazwę, opis („zadzwoń, kiedy”) i input_schema.
  • Mogę krok po kroku śledzić cykl [ ] użycie_narzędzia → wynik_narzędzia.
  • [ ] Zgłaszam błędy narzędzi do modelu jako otwarte narzędzie_result.
Dawny Następny