Za dużo narzędzi dla AI — co się dzieje, gdy lista robi się długa
Każde narzędzie to opis, który model czyta przy każdym zapytaniu. Co się psuje przy kilkudziesięciu, po czym to poznać i trzy sposoby na skrócenie listy.
Podłączasz do asystenta AI system zadań. Działa. Dokładasz pocztę, bo skoro już. Potem kalendarz, potem dysk z dokumentami.
Po trzech miesiącach ten sam asystent odpowiada gorzej niż na początku, rachunek jest wyższy, a nikt nie potrafi wskazać momentu, w którym coś się zepsuło. Zwykle nic się nie zepsuło. Lista narzędzi po prostu urosła.
Skąd bierze się długa lista
Podłączenie jednego systemu to nie jest jedno narzędzie.
Serwer wystawiający bazę zadań udostępnia zwykle kilkanaście osobnych operacji: wypisz zadania, wyszukaj zadanie, pobierz jedno, utwórz, zaktualizuj, usuń, dodaj komentarz, załącz plik, wypisz pola, zmień uprawnienia. Każda z nich jest osobną pozycją na liście, którą widzi model.
Drugi system dokłada swoje kilkanaście. Trzeci kolejne. Nikt w firmie nigdy nie podejmuje decyzji „dodajmy pięćdziesiąte narzędzie” — decyzje brzmią „podłączmy jeszcze kalendarz” i każda z osobna jest rozsądna.
Ile miejsca zajmuje jedno narzędzie
Model nie widzi twoich systemów. Widzi ich opis.
Każde narzędzie to nazwa, zdanie lub dwa o tym, do czego służy, i schemat parametrów: jak się nazywają, jakiego są typu, które są obowiązkowe, co dokładnie oznaczają. Bez tego model nie umiałby narzędzia poprawnie wywołać.
Ten opis trafia do modelu przy każdym zapytaniu, zanim padnie pierwsze słowo pytania. Również wtedy, gdy pytasz o coś, co z danym narzędziem nie ma nic wspólnego.
Przyjmijmy dla ilustracji, że jeden opis zajmuje tyle, co pół strony tekstu. Przy pięciu narzędziach model czyta dwie i pół strony wstępu, zanim usłyszy pytanie. Przy sześćdziesięciu — trzydzieści stron. Za każdym razem, przy każdej wiadomości. Liczby są przykładowe, proporcja nie.
Wynikają z tego dwie rzeczy naraz. Pierwsza to koszt: płacisz za ten wstęp przy każdym zapytaniu, niezależnie od tego, czy cokolwiek z listy zostanie użyte. Druga jest poważniejsza — im dłuższa lista, tym trudniej wybrać z niej właściwą pozycję. Model porównuje opisy, a przy kilkudziesięciu operacjach z czterech systemów wiele z nich brzmi podobnie.
Jak poznać, że to już jest problem
Objawy są rozpoznawalne, ale żaden z nich nie wygląda na problem z liczbą narzędzi. Wyglądają na pogorszenie jakości modelu.
Model wybiera operację sąsiednią. Prosisz o znalezienie konkretnego zlecenia, dostajesz listę wszystkich. „Wyszukaj” i „wypisz” to dla ciebie dwie różne rzeczy, dla modelu — dwa podobnie brzmiące opisy.
Ten sam typ pytania działa wolniej i kosztuje więcej niż miesiąc temu. Pytania się nie zmieniły. Zmieniło się to, co model czyta przed nimi.
Model gubi ustalenia z początku rozmowy. Miejsce zajęte przez wstęp nie jest już dostępne dla dalszego ciągu rozmowy.
Zadanie, które szło jednym krokiem, idzie trzema. Model próbuje, trafia w niewłaściwą operację, poprawia się. Każda próba to osobne wywołanie i osobny koszt.
Test zajmuje pół godziny: zapisz pięć typowych pytań razem z dzisiejszymi odpowiedziami, odłącz połowę podłączonych systemów, zadaj te same pięć pytań. Jeżeli odpowiedzi przy krótszej liście są lepsze, masz odpowiedź, gdzie leży problem.
Warto go zrobić, zanim zaczniesz szukać winy w samym modelu albo rozglądać się za innym dostawcą. To najtańsza hipoteza do sprawdzenia i zaskakująco często trafna.
Trzy sposoby na skrócenie listy
W kolejności od najmniejszego nakładu pracy. Nie wykluczają się — najczęściej sensownie jest połączyć pierwszy z jednym z pozostałych.
Zestaw pod rolę
Nie każdy potrzebuje wszystkiego. Serwis pracuje na zleceniach i harmonogramie, handel na klientach i ofertach, księgowość na dokumentach.
Zamiast jednej konfiguracji dla całej firmy — kilka mniejszych, po jednej na rolę. To najprostszy z trzech sposobów, nie wymaga niczego poza decyzją i w firmie 11–200 osób zwykle wystarcza.
Warunek: ktoś musi te zestawy okresowo przeglądać. Role się zmieniają, a listy same się nie skracają.
Podział na serwery
Zamiast jednego serwera wystawiającego wszystko — kilka wąskich, podłączanych osobno. Naturalna linia podziału biegnie po obszarach pracy, a nie po dostawcach: zlecenia osobno, dokumenty osobno, poczta i kalendarz osobno.
Zaleta jest praktyczna: całe obszary włącza się i wyłącza jednym przełącznikiem, zamiast edytować listę pozycja po pozycji. Łatwiej też odpowiedzieć na pytanie, co właściwie jest w tej chwili podłączone.
Koszt: więcej rzeczy do skonfigurowania i utrzymania.
Wyszukiwanie narzędzi na zadanie
Zamiast wysyłać modelowi całą listę, wysyłasz mały stały zestaw — a w nim jedno narzędzie, którym model odnajduje pozostałe. Kiedy zadanie wymaga czegoś spoza stałego zestawu, model wyszukuje to zapytaniem i doładowuje opisy tylko tego, co jest w danej chwili potrzebne.
Wstęp zostaje krótki niezależnie od tego, ile narzędzi jest podłączonych. To jedyny z trzech sposobów, który nie przestaje działać przy dalszym wzroście.
Koszt: dodatkowa runda, zanim model zacznie robić to, o co prosisz. Przy pięciu narzędziach to strata czasu. Przy kilkudziesięciu — oszczędność, i to rosnąca z każdym kolejnym.
Krótsza lista to nie to samo co mniejszy dostęp
Warto tych dwóch rzeczy nie mylić, bo mylą się często, a akurat tu pomyłka jest kosztowna.
Model nie dostaje dostępu do bazy. Dostaje listę narzędzi i może poprosić o ich wywołanie; wywołuje je aplikacja, w imieniu zalogowanego użytkownika. Uprawnienia są więc uprawnieniami konta, którego poświadczeń użyto — sam protokół niczego z siebie nie ogranicza. Samą tę wymianę rozkładamy na kroki w tekście o podłączaniu danych firmy do klienta AI.
Zdjęcie narzędzia z listy zmniejsza szansę, że zostanie wywołane przez pomyłkę. Nie zmniejsza tego, co tym kontem da się zrobić. Jeżeli chcesz realnie ograniczyć zakres, robisz to po stronie konta i uprawnień w systemie źródłowym, a nie przez skracanie listy widocznej dla modelu.
Podsumowanie
Każde podłączone narzędzie zajmuje miejsce i uwagę modelu przy każdym zapytaniu, niezależnie od tego, czy zostanie użyte. Przy kilkunastu narzędziach nie ma to znaczenia. Przy kilkudziesięciu ma, i widać to najpierw jako pogorszenie jakości, a dopiero potem na rachunku.
Sygnałem nie jest liczba, tylko zachowanie: mylone podobne operacje, wolniejsze odpowiedzi na te same pytania, zadania rozbijane na próby. Zacznij od zestawów pod rolę, bo to kosztuje jedną decyzję. Podziel na serwery, jeżeli obszary w firmie są wyraźne. Po wyszukiwanie narzędzi sięgnij wtedy, gdy lista rośnie szybciej, niż ktokolwiek nadąża ją porządkować.
Szerszy kontekst — jak w ogóle podłącza się model do firmowych danych i czyimi uprawnieniami wtedy działa — opisujemy w przewodniku o integracji AI z danymi firmy.
Częste pytania
- Ile narzędzi to za dużo dla modelu AI?
- Nie ma progu, który da się podać liczbą — zależy to od tego, jak długie są opisy i jak bardzo podobne do siebie. Sygnałem jest zachowanie, nie liczba: model zaczyna mylić bliskie operacje, odpowiedzi są wolniejsze przy tych samych pytaniach, a rachunek rośnie bez wzrostu użycia.
- Dlaczego podłączenie kolejnego systemu podnosi koszt pytań, które go nie dotyczą?
- Bo opisy wszystkich podłączonych narzędzi trafiają do modelu przy każdym zapytaniu, zanim padnie samo pytanie. Model musi wiedzieć, czym dysponuje, żeby cokolwiek wybrać, więc płacisz za pełną listę także wtedy, gdy pytasz o coś zupełnie innego.
- Czy skrócenie listy narzędzi zwiększa bezpieczeństwo?
- Trochę, ale nie tak, jak się wydaje. Uprawnienia w takim połączeniu są uprawnieniami konta, którego poświadczeń użyto — zdjęcie narzędzia z listy zmniejsza szansę na wywołanie przez pomyłkę, ale nie zmienia tego, co tym kontem da się zrobić.
Czytaj dalej
Automatyzacja bez programisty — gotowy konektor i granice
Między integracją u programisty a wklejaniem danych do czatu jest trzecia droga: gotowy konektor w platformie automatyzacji. Co potrafi i gdzie się kończy.
Jak podłączyć dane firmy do Claude i innych klientów AI przez MCP
Co się dzieje przy podłączeniu serwera MCP do klienta AI: co model widzi, co może zrobić, na jakim koncie działa połączenie i co sprawdzić przed produkcją.
MCP a integracja przez API — kto decyduje, co się wydarzy
Integracja przez API to ścieżka zapisana z góry przez programistę. MCP daje modelowi zestaw operacji i to on wybiera. Co to zmienia w kosztach i testach.