Na tej stronie
Wyobraź sobie katalog produktów zmieniony w poniedziałek. Prompt asystenta wciąż zawiera piątkową listę. Zespół aktualizuje prompt. Druga kopia starej listy tkwi w przykładach użytych do trenowania modelu. W jednej sesji asystent podaje teraz jedną odpowiedź aktualną i jedną przestarzałą.
To ilustracyjna awaria, ale jej mechanizm jest powszechny: ten sam fakt dostał więcej niż jeden dom.
Prezentacja o promptach, pobieraniu wiedzy i wagach modeli wyznacza użyteczną granicę. Prompt mówi asystentowi, jak ma się zachowywać. Pobieranie dostarcza aktualną wiedzę z cytowalnego źródła do konkretnego zadania. Dostosowanie modelu może nauczyć trwałego wzorca. Traktowanie ich jak drabiny, na której najpierw pisze się prompt, potem dodaje wyszukiwanie, a na końcu zawsze dostraja model, gdy odpowiedź nadal jest zła, błędnie diagnozuje problemy z faktami.
Prompt jest złym katalogiem
Prompty kuszą łatwością edycji. Dodaj akapit, a następne żądanie go otrzyma. Wygoda ukrywa dwa koszty. Fakt jest wysyłany przy każdym wywołaniu, nawet gdy nie ma znaczenia. Duży prompt utrudnia też ustalenie, z której kopii reguły model skorzystał.
Trwała instrukcja, taka jak „zapytaj przed wysłaniem kampanii”, należy blisko agenta. Lista bieżących pól niestandardowych sklepu nie. Może się zmienić po dodaniu atrybutu przez administratora. Może być inna u różnych klientów. Może być widoczna w jednym obszarze roboczym i zakazana w innym.
Przewodnik po konektorze Brevo pokazuje, dlaczego definicje pól liczą się przy synchronizacji kontaktów. Jeśli atrybut nie został zadeklarowany na koncie docelowym, mapowanie sensowne na podstawie nazwy może nie utworzyć zamierzonego pola. Agent powinien sprawdzić bieżący kontrakt konta, nie przywoływać ogólną listę zapamiętaną podczas treningu.
Użyteczny wynik wyszukiwania jest dość mały, aby można go było zakwestionować. Powinien wskazywać konto lub klienta, którego dotyczy, czas odczytu oraz opisywaną operację lub pole. Jeśli dwa pobrane fragmenty są sprzeczne, system powinien ujawnić konflikt, nie wybierać po cichu tego, który brzmi płynniej. Kolejnym krokiem może być nowy odczyt lub przegląd, nie silniejsze sformułowanie promptu.
Pobieraj fakt wraz z zakresem
Użyteczny rekord wiedzy zawiera więcej niż tekst. Potrzebuje źródła, wersji lub czasu pobrania, zakresu konta i jasnego sposobu usunięcia lub zastąpienia. Definicja pola znaleziona na koncie jednego sklepu nigdy nie powinna stać się regułą uniwersalną dla innego.
Pytanie o atrybut kontaktu może więc pobrać najmniejszy fragment, który na nie odpowiada: nazwę pola, typ i konto, na którym pole istnieje. Odpowiedź może wskazać źródło. Jeśli mapowanie zawiedzie, zespół może sprawdzić, czy fakt był stary, czy zwrócono wynik z niewłaściwego konta, czy model źle zrozumiał poprawny fragment.
To różne naprawy. Zmiana promptu nie naprawi filtra pobierania, który przekracza granice klientów. Większy model nie poda definicji atrybutu, którego nikt nie pobrał.
Wyjaśnienie MCP opisuje, jak agent może pytać narzędzia. Narzędzie powinno zwracać właściwy kontrakt, a aplikacja egzekwować, kto może go zobaczyć. Tekstowa instrukcja „nie ujawniaj danych innego klienta” nie zastąpi zapytania o ograniczonym zakresie.
Ten podział przyspiesza także naprawę. Jeśli pole docelowe zmieni nazwę, popraw źródło schematu i unieważnij dotknięte mapowanie. Jeśli agent wielokrotnie źle rozumie stabilną instrukcję, zmień ją lub przetestuj celowane trenowanie. Jeśli odpowiedź jest zła, bo wyszukiwarka wybrała niewłaściwe konto, zmiana wag modelu ominie przyczynę. Każda klasa błędu ma innego właściciela i inną drogę korekty.
- Trwała instrukcja
Jak asystent powinien się zachować
- Pobieranie z zakresem konto · wersja · czas
Co jest prawdziwe teraz
- Decyzja o mapowaniu
Użyj bieżącego faktu w tym zadaniu
- Kontrolowany zapis
Kod sprawdza prawa i zakres
Ucz wzorców dopiero, gdy są trwałe
Uczciwy zarzut brzmi: „Jeśli fakt jest używany stale, czemu nie wytrenować go w mniejszym modelu?”. Samo powtarzanie nie wystarcza. Fakt musi pozostać prawdziwy między aktualizacjami modelu, a model musi odróżniać konteksty.
Stabilny styl klasyfikacji może kiedyś uzasadniać dostrojenie. Aktualna lista pól dostawcy jest słabym kandydatem. Nawet jeśli zmienia się rzadko, koszt jednej starej odpowiedzi może oznaczać złe mapowanie zastosowane do wielu rekordów. Trzymaj fakt tam, gdzie człowiek może go obejrzeć i zaktualizować.
Prezentacja ostrzega też przed używaniem wyszukiwania do rozwiązywania każdego błędu rozumowania. Jeśli model nie potrafi poprawnie porównać dwóch właściwych dokumentów, dodanie pięćdziesięciu kolejnych nie nauczy go rozumować. Najpierw zapytaj, czy przybył właściwy fragment. Potem, czy osąd tego fragmentu był dobry.
Dla osoby budującej integrację powstaje z tego kolejność naprawy: znajdź błędne twierdzenie; sprawdź pobrany fragment pola lub API; zweryfikuj konto i wersję; w razie potrzeby popraw źródło lub pobieranie; ponownie przetestuj decyzję. Dopiero wtedy rozważ zmianę modelu.
Kosztem jest utrzymywanie prawdziwej warstwy wiedzy: aktualizacji źródeł, kontroli dostępu i cytowań. Zyskiem jest fakt, który da się poprawić w jednym miejscu.
Zmieniający się kontrakt nie powinien czekać, aż model o nim zapomni.
Najczęściej Zadawane Pytania
Co należy umieścić w prompcie agenta?
Krótkie, trwałe instrukcje dotyczące zachowania i granic. Zmieniający się katalog, lista pól danego klienta czy bieżąca reguła dostawcy powinny być pobierane z uprawnionego źródła w razie potrzeby.
Dlaczego nie dostroić modelu do bieżącej dokumentacji?
Dostrajanie może utrwalić zmienny fakt w wagach trudnych do sprawdzenia i aktualizacji. Najpierw zadbaj, aby właściwy dokument był pobierany i cytowany w chwili decyzji.
Jak naprawić błędną odpowiedź o faktach?
Sprawdź dokument źródłowy, jego wersję, filtr wyszukiwania i zwrócony fragment. Popraw fakt lub drogę pobierania, zanim zmienisz model.