Модельге арналған құралдар тізімін неге ортақ етіп жасауға болмайды?

Әр сұрауда модельге API операцияларының толық каталогы қажет емес. Оған диалогтың ағымдағы күйінде шынымен рұқсат етілген әрекеттердің шағын жиынтығы керек. Компания екі жүз функциядан тұратын бірдей тізімді әрі үлкен reasoning-модельге, әрі арзан шағын модельге берсе, ол модель мүмкіндігін емес, жүйенің нашар дизайнға төзімділігін тексереді.

Құралдар тізімі бірден үш нәрсеге әсер етеді: дұрыс таңдау ықтималдығына, контекстегі орынға және орындау қауіпсіздігіне. Үлкен модель шамадан тыс каталогты кейде көтере алады. Шағын модель сипаттамадағы сөздердің кездейсоқ ұқсастығына қарап функцияны жиі таңдайды, міндетті параметрді өткізіп жібереді немесе мүлде қажет болмаған әрекетті шақырады. Бұл шағын модельдерден бас тартуға себеп емес. Функциялар жиынтығын жүйелік промпттың өзгермейтін бөлігі деп қарауды тоқтатуға себеп.

Бір жаһандық каталог әрекет таңдауды бұзады

Жаһандық API каталогы тек JSON Schema-ны бір рет жасап, оған қайта оралғысы келмейтін әзірлеушіге ыңғайлы. Модель үшін ол әртүрлі домендердің, рөлдердің және процестің кезеңдерінің әрекеттерін араластырады.

Интернет-дүкеннің қолдау қызметіндегі көмекшіні елестетіңіз. Жалпы реестрде get_order, cancel_order, refund_payment, create_return, change_delivery_address, apply_discount, block_account, reset_password және тағы ондаған функция бар. Пайдаланушы: «Курьер келмеді, 8241-тапсырыс үшін ақшаны қайтарыңыз», деп жазады. Модель қайтару, тапсырыстан бас тарту, жеткізуге шағымдану және қолмен жеңілдік беру операцияларын бір уақытта көрсе, оған тапсырыс нөмірін шығарып алу ғана жеткіліксіз. Ол бизнес-процесті дұрыс қалпына келтіруі керек.

cancel_order функциясы «қайтарыңыз» деген сөзге қарап лайықты көрінуі мүмкін. Бірақ тапсырыс жеткізуге беріліп қойса, одан бас тарту кеш болады. refund_payment функциясы мәртебе мен себеп тексерілгенше қолжетімсіз болуы мүмкін. Дұрыс рет әдетте тапсырысты оқудан басталады, кейін жеткізу фактісі тексеріледі, содан соң ережелерге сай шағым жасалады немесе қайтару ұсынылады. Осы ауысулардың бәрін модельге тең құқықты батырмалар жиынтығы ретінде берсеңіз, қате күтілетін нәтижеге айналады.

Мәселе құралдардың атаулары ұқсас болғанда күшейеді:

• search_customer байланыс деректері бойынша есептік жазбаны іздейді;
• get_customer жазбаны ішкі идентификатор арқылы оқиды;
• get_customer_orders тапсырыстарды қайтарады;
• get_order бір тапсырысты оқиды;
• update_customer профильді өзгертеді.

Адам құжаттаманы қысқа қарап шыққаннан кейін айырмашылықты түсінеді. Модель бір шақыру үшін өзара бәсекелес бірнеше мағыналық жақын сипаттаманы көреді. Модель неғұрлым әлсіз, ал пайдаланушы сұрағы неғұрлым қысқа болса, бұл бәсекенің құны соғұрлым жоғары.

Мұны промпттағы «дұрыс функцияны мұқият таңда» деген сөйлеммен емдеу мүмкін емес. Модель мұны онсыз да жасауға тырысады. Сұрау модельге жетпей тұрып, қолданба қате нұсқалардың санын азайтуы керек.

Контекст көлемі функцияларды ажырату қабілетіне тең емес

Үлкен контекст терезесі сұрауға көбірек схема, құжаттама және тарих орналастыруға мүмкіндік береді. Бірақ ол модельге каталог ішінен іздеуге арналған бөлек механизм бермейді және ұқсас операцияларды бір-біріне азырақ ұқсас етпейді.

Gemini-дің ресми құжаттамасы белсенді жиынтықты шамамен 10-20 релевантты функция шегінде ұстауға және жалпы каталог үлкен болса, функцияларды динамикалық түрде іріктеуге кеңес береді. Бұл әмбебап шек те, сиқырлы сан да емес. Бұл модельге бәсекелес нұсқалар тым көп берілгенде таңдау сапасының төмендейтінін мойындайтын пайдалы қағида. Сол құжаттарда қолжетімді шақырулар жиынтығын шектеуге арналған allowed_function_names параметрі де сипатталған.

Контексті схемалармен толтырмаудың тағы бір практикалық себебі бар. Құрал сипаттамасы тек атаудан тұрмайды. Оның ішінде мақсат мәтіні, JSON Schema, қасиеттер, тізімдер, міндетті өрістер, мысалдар және кейде қате ережелері болады. Мұқият сипатталған жүз функция пайдаланушы тарихын, алдыңғы шақырулардың нәтижелерін және шешім қабылдауға қажет құжаттарды сұраудан оңай ығыстырып шығарады.

Бұл ұзақ агенттік тізбектерде анық көрінеді. Әр шақырудан кейін тарихқа операция атауы, аргументтер, нәтиже, шақыру идентификаторы және провайдердің қызметтік деректері қосылады. Құралдар комбинациясы туралы Gemini құжаттамасы шақырулардың қайтарылған бөліктері тарихтың құрамына кіріп, сұрауларда есепке алынатынын еске салады. Контекст терезесін үлкейтуге болады. Бірақ тарихты тегін әрі қатесіз ету мүмкін емес.

Екі міндетті ажыратыңыз:

1. Контекст терезесі қадамдар арасында қанша ақпаратты бере және сақтай алатыныңызды анықтайды.
2. Tool calling сапасы модельдің қажетті операцияны таңдайтынын, рұқсат етілген аргументтерді құратынын және нәтижені түсінетінін анықтайды.

Контекст терезесі өте үлкен модельдің функция таңдау сапасы орташа болуы мүмкін. Ал терезесі қысқа шағын модельге бір-бірінен анық ажыратылған бес операция берсеңіз, дәлдігі жоғары болуы ықтимал. Агенттік тапсырмада модельдерді тек контексттегі токендер саны бойынша салыстырудың мәні жоқ.

Белсенді жиынтық тапсырма күйіне сай болуы керек

Функцияларды API-дің ұйымдық құрылымына қарай емес, процестің кезеңдеріне қарай беріңіз. Бірінші қадамда модельге көбіне іздеу немесе оқу қажет. Екінші қадамда, фактілер тексерілгеннен кейін, оған өтінім жасау керек болуы мүмкін. Ақшаға немесе құқықтарға шын мәнінде әсер ететін операция қолданба коды тексеретін шарттар орындалғаннан кейін ғана көрінуі керек.

Сол тапсырысты қайтару маршруты мынадай болуы мүмкін:

1. Пайдаланушы мәселе мен тапсырыс нөмірін хабарлайды.
2. Қолданба модельге тек get_order функциясын береді, ал нөмір болмаса, find_orders_by_contact функциясын қосады.
3. Тапсырысты оқығаннан кейін қолданба мәртебеге, елге, мерзімге және пайдаланушы рөліне қарай қолжетімді ауысуларды өзі анықтайды.
4. Бұл операцияларға рұқсат болса, модель create_delivery_claim немесе prepare_refund функциясын алады.
5. Орындаушы параметрлерді тексеріп, әрекетті іске қосады немесе растауды талап етеді.

Бұл LLM-нің пайдасын жоятын қатаң сценарий емес. Модель еркін мәтіннен дерек шығарып, рұқсат етілген тармақтардың арасынан таңдап, нақтылау сұрақтарын қойып, нәтижені түсіндіре береді. Бірақ қауіпті ауысуға сіздің жүйеңізде құқық бар-жоғын енді өзі шешпейді.

Мұндай тәсіл ішкі жүйелерге де пайдалы. Қаржылық көмекшіде талдау кезеңіндегі жиынтыққа операцияларды оқу, шартты іздеу және лимитті есептеу кіруі мүмкін. Төлемді дайындау кезеңінде оған нобай жасау функциясы беріледі. Сервер сома, өкілеттік және міндетті өрістерді тексермейінше, төлемді жіберу функциясын қоспаған дұрыс. Пайдаланушы «бірден төле» деп сұраса да, модель тиісті функция атауын көріп тұрғаны үшін ережелерді айналып өтпеуі керек.

AI Router модельді ауыстырғанда үйреншікті OpenAI-үйлесімді сұрау форматын сақтауға мүмкіндік береді. Сондықтан белсенді жиынтық маршрутизаторын бір провайдерге байламай, өз қолданбаңызда ұстаған дұрыс. Сонда клиент кодын қайта жазбай, бір тапсырманы бірнеше модельде тексере аласыз.

Ұқсас функцияларды модель көрмей тұрып ажыратыңыз

Құрал схемаларындағы ең жиі қате required өрісінің болмауынан туындамайды. Команда ішкі CRUD-әдістерін ой қорыта алатын жүйеге арналған интерфейс ретінде ұсынуға тырысады.

Мысалы, create_ticket, update_ticket, assign_ticket деген үш операцияның орнына кейде action параметрі бар ticket_mutation жарияланады. Бұл функциялар санын азайтуы мүмкін, бірақ схеманы жиі нашарлатады: модель әрекет жолын, өрістердің үйлесімділігін және рұқсат етілген ауысуды өзі табуы керек. Операцияларды олардың мақсаты, құқықтары және өмірлік циклі бірдей болғанда ғана біріктіріңіз.

Керісінше шектен шығу да зиян. Жүйе мекенжайды бір тексерілетін объект арқылы қауіпсіз өзгерте алса, set_shipping_city, set_shipping_street, set_shipping_house, set_shipping_apartment функцияларын жеке-жеке жариялаудың қажеті жоқ. Пайдаланушы мекенжайды бір объект ретінде қабылдайды. Модель де түсінікті схемасы бар бір update_delivery_address операциясын көруі керек.

Жақсы функция бір қолданбалық сұраққа жауап береді. Оның атауы әрекетті сипаттайды, ал сипаттамасы қолданылу шекарасын түсіндіреді. Салыстырып көріңіз:

{
  "name": "refund_payment",
  "description": "Return money for a paid order only after the order record confirms that a refund is allowed. Do not use to cancel an unpaid order or create a delivery claim.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "Internal order identifier returned by get_order"
      },
      "reason": {
        "type": "string",
        "enum": ["delivery_failure", "duplicate_charge", "approved_return"]
      }
    },
    "required": ["order_id", "reason"],
    "additionalProperties": false
  }
}

Мұнда ағылшын тіліндегі тұжырымның өзі маңызды емес. Маңыздысы, сипаттама ұқсас болғанымен қате екі қолдануға тыйым салады, ал reason өрісі модельді ішкі себеп кодын ойлап табуға мәжбүрлемейді. Мәндер жиыны жабық болса, оны enum арқылы көрсетіңіз. Gemini құжаттамасы рұқсат етілген мәндер тізімі шектеулі параметрлерге де осы ережені ұсынады.

Бизнес ережелерін тек құрал сипаттамасына жасырып қоймаңыз. Мәтін модельге әрекет таңдауға көмектеседі, бірақ сервер тексеруін алмастырмайды. additionalProperties: false қолдайтын іске асыруларда артық аргумент беруге жол бермейді, алайда пайдаланушының дәл осы тапсырыс үшін ақша қайтаруға құқығы бар-жоғын тексермейді.

Шағын модельдер тар келісімді қажет етеді

Шағын модель қарапайым, жиі қайталанатын және жақсы шектелген тапсырмалар үшін жақсы диспетчер бола алады. Ол көбіне үлкен модельден арзан әрі жылдам. Бірақ оған функциялардың алып кітапханасын беріп, бизнесіңіздің жасырын логикасын қалпына келтіруді талап етсеңіз, бұл артықшылық жоғалады.

Шағын модельге төрт шектеу пайдалы. Олар тестерді алмастырмайды, бірақ кездейсоқ шешімдердің санын айтарлықтай азайтады.

• Процестің ағымдағы кезеңіне ғана қажет функцияларды беріңіз.
• Ішкі қысқартуларсыз, қысқа әрі бір-бірінен анық ажыратылатын атаулар қолданыңыз.
• Міндетті параметрлерді ашық көрсетіп, тізімдерді пайдаланыңыз.
• Шақыруға идентификатор, күн, сома немесе пайдаланушы келісімі жетіспесе, нақтылау сұрағын талап етіңіз.

Шағын модельді бір жауапта сегіз шақырудан тұратын ұзын тізбекті жоспарлауға мәжбүрлемеңіз. Орындауды қысқа қадамдарға бөліңіз: модель әрекетті таңдайды, қолданба оны орындайды, нәтижені қайтарады, содан кейін белсенді жиынтық қайта құрылады. Мұндай цикл желілік сұрауларды көбейтеді, есесіне қатені оқшаулайды. Модель сұрауды қате жіктесе де, бір жауаптың ішінде клиент жасап, шартты өзгертіп және хабарлама жібере алмайды.

Құрал таңдау режимі де маңызды. OpenAI API-де қолданба құралдарға тыйым салатын, модельге автоматты таңдауды қалдыратын, шақыруды талап ететін немесе нақты құралды мәжбүрлеп көрсететін режимдер бар. Мәжбүрлі шақыруды барлық сұрауға арналған амал ретінде емес, кодыңыз детерминистік түрде шешім қабылдағаннан кейін қолданыңыз. Серверге тек get_order қажет екені анық болса, модельді он операцияның арасынан қайта таңдауға мәжбүрлемеңіз.

Қатаң схема аргументтердің пішініне көмектеседі, бірақ ниетке көмектеспейді. Модель қате функция үшін мінсіз JSON құра алады. Сондықтан бағалауда таңдау қатесін және параметр қатесін әрдайым бөлек есептеңіз. Әйтпесе команда жарамды JSON үлесі жоғары екенін көріп, агент әрекеттерге дайын деп қате шешеді.

Жүздеген операциядан тұратын каталогты модельдің назары емес, код іздеуі керек

Сізде жүздеген функция болса, оларды тіпті күшті модельге де түгел бермеңіз. Іріктеу қабатын жасаңыз. Ол күрделі векторлық дерекқор болуы міндетті емес және LLM-ге өз қолжетімділігін кеңейту құқығын бермеуі керек.

Практикалық маршрутизатор кандидаттарды бірнеше белгі бойынша құрады: ағымдағы өнім модулі, пайдаланушы рөлі, нысан күйі, сұрау тілі және анық танылған ниет. Содан кейін осы күйге рұқсат етілген шағын функциялар жиынтығын сұрауға қосады. Сипаттамалар бойынша семантикалық іздеу кандидаттарды табуға көмектеседі, бірақ қауіпті әрекеттер үшін жалғыз сүзгі болмауы керек.

Марштизатор мен модель шақыруы арасындағы келісімнің мысалы:

{
  "conversation_state": "order_delivered_claim",
  "user_role": "support_agent",
  "allowed_tools": [
    "get_order",
    "create_delivery_claim",
    "prepare_refund"
  ],
  "blocked_tools": [
    "refund_payment",
    "cancel_order",
    "change_delivery_address"
  ]
}

blocked_tools өрісін модельге жіберудің қажеті жоқ. Ол шешім журналында және маршрутизатор тестерінде пайдалы. Бір айдан кейін мынадай жағымсыз сұраққа жауап бере аласыз: қайтару функциясы модель оны есіне түсірмегендіктен жоқ болды ма, әлде қолданба оны дұрыс бұғаттағандықтан ба?

«Модельге барлық құралды беріңіз, қайсысы қашан керек екенін өзі түсінеді» деген кең таралған, бірақ нашар кеңес бар. Бұл тәсіл жиынтық шағын, операциялар зиянсыз, ал пайдаланушы сұрағы мінсіз тұжырымдалған демоларда жақсы көрінеді. Өндірістік ортада ол екі түрлі ақау туғызады. Алдымен модель ықтимал көрінгенімен қате функцияны таңдайды. Содан кейін команда одан да ұзын сипаттамалар қосады, ал каталог ауыр, қымбат әрі түсініксіз бола түседі.

Платформаңыз MCP қолданса, ереже өзгермейді. MCP клиент пен құрал сервері арасындағы үйлесімділікті шешеді, бірақ қолжетімділікті басқару мәселесін шешпейді. Сервер жүздеген операция жариялай алады, алайда клиент ағымдағы әңгімеде қайсысы қолжетімді екенін өзі таңдауы керек. Remote MCP туралы Gemini құжаттамасы сервер құралдарын шектеу үшін allowed_tools параметрін тікелей қарастырады.

Тек соңғы жауапты емес, маршрутты бағалаңыз

«Модель дұрыс мәтін қайтарды» деген тест агенттің жарамдылығы туралы дерлік ештеңе айтпайды. Пайдаланушы сыпайы хабарлама алуы мүмкін, тіпті модель қате операцияны таңдап, қолданба оны қабылдамай, кейін модель сәтті түрде кешірім сұраса да.

Әр жағдай үшін рұқсат етілген және тыйым салынған функциялар, қажетті аргументтер және рұқсат етілген реттілік белгілі болатын тапсырмалар жиынтығын жасаңыз. Әдейі қолайсыз мысалдарды қосыңыз: толық емес тапсырыс нөмірі, бір хабарламадағы екі тапсырыс, пайдаланушының ережені бұзуды сұрауы, бір-біріне қайшы күндер, тарихтағы ескірген мәртебе және атаулары ұқсас өнімдер.

Әр іске қосу үшін мынадай жазба сақтаңыз:

{
  "case_id": "refund_after_failed_delivery_017",
  "active_tools": ["get_order", "create_delivery_claim", "prepare_refund"],
  "expected_first_tool": "get_order",
  "model_tool": "prepare_refund",
  "arguments_valid": true,
  "policy_allowed": false,
  "executor_result": "blocked_missing_status_check"
}

Бұл жазба жиі бір көрсеткішке біріктірілетін үш оқиғаның айырмасын көрсетеді: модель жарамды JSON жасады, модель орынды функцияны таңдады, жүйе әрекетке рұқсат берді. Мысалда JSON жарамды, бірақ шақыру тым ерте жасалған. Тек схема жарамдылығын есептесеңіз, қауіпті ақауды байқамай қаласыз.

Кемінде төрт нәтижеге назар аударыңыз:

• бірінші функцияны таңдау дәлдігі;
• серверлік қалыпқа келтіруден кейінгі аргументтер дәлдігі;
• артық шақырулар үлесі;
• тыйым салынған немесе мерзімінен бұрын орындалған әрекеттер үлесі.

Негізді нақтылау сұрақтарын бөлек есептеңіз. Идентификатор болмаған кезде тапсырыс нөмірін сұрайтын модель оны ойдан шығарып, функция шақыратын модельден жақсы. Банк, медицина және мемлекеттік қызметтер сияқты қауіпті домендерде бұл айырмашылық жауаптың орташа ұзындығынан маңызды.

Параллельдік пен автономияның шекарасы анық болуы керек

Операциялар бір-біріне тәуелсіз болса, параллель шақырулар кідірісті азайтады. Клиент профилі мен оның тапсырыстарының тізімін екі функция да тек дерек оқып, бір-біріне тәуелді болмаса, бір уақытта алуға болады. OpenAI құжаттамасы parallel_tool_calls параметрін сипаттайды, ал Gemini құжаттамасы параллель және бірізді шақыруларды қолдайды. API қолдауы кез келген операция жиынтығын қауіпсіз түрде қатар іске қосуға болады дегенді білдірмейді.

Оқу нәтижесі өзгерту әрекетінің заңдылығын анықтаса, бір нысанды оқу мен өзгертуді қатар орындамаңыз. Ортақ лимитті жұмсайтын екі шақыруды іске қоспаңыз. Код бұл әрекеттердің үйлесімді екенін тексермейінше, модельге бір уақытта қайтарым жасап, өтем ретінде жеңілдік қолдануға рұқсат бермеңіз.

Құралдарды үш класқа бөлу пайдалы:

• күйді өзгертпейтін оқу;
• нобай немесе есеп жасайтын дайындау;
• ақшаға, құқықтарға, деректерге немесе сыртқы міндеттемеге әсер ететін орындау.

Модель оқумен салыстырмалы түрде еркін жұмыс істей алады. Дайындау контекст тексеруін және идемпотентті идентификаторды қажет етеді. Орындау серверлік рұқсатты, журнал жүргізуді және бірқатар процесте адамның растауын талап етеді. Бұл модель айналасындағы артық бюрократия емес. Бұл әрекет ұсынысы мен әрекеттің өзі арасындағы қалыпты инженерлік шекара.

Модельді tool calling бойынша бір әдемі мысалға қарап таңдамаңыз. Өз операцияларыңызды алыңыз, белсенді жиынтықты шынымен рұқсат етілген функцияларға дейін қысқартыңыз, ұқсас әрекеттерге арналған тестерді қосып, шақыру трассаларын қараңыз. Сонда сізге қай жерде күштірек модель, ал қай жерде шағын модель жеткілікті екені көрінеді. Көбіне алғашқы түзету модельді ауыстыру емес, каталогтың тоқсан пайызын оның көру аймағынан алып тастау болады.