[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-function-calling::ru":3,"gloss-cluster-function-calling::ru":20,"gloss-next-function-calling::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"function-calling","core-ai","Вызов функций (Function Calling \u002F Tool Use)","Вызов функций (function calling, также называемый tool use — использование инструментов) — это возможность, которая позволяет LLM выйти за рамки генерации текста и вместо этого инициировать реальные действия во внешних системах — вызывать API, запрашивать базу данных, выполнять вычисление или запускать код — выводя структурированный, машиночитаемый запрос (обычно JSON), указывающий, какую функцию вызвать и с какими аргументами; ваше приложение затем фактически выполняет это и передаёт результат обратно модели, чтобы она продолжила рассуждение или ответила пользователю. Это механизм, который превращает LLM из системы \"текст на входе, текст на выходе\" в систему, способную взаимодействовать с реальным миром: без вызова функций LLM, которую спросили \"какой у меня баланс на счету\", может только угадывать или отказаться отвечать; с вызовом функций она может вызвать определённую вами функцию `get_account_balance(user_id)`, получить обратно реальное число и ответить точно. Это чрезвычайно важно для разработчиков SaaS, потому что это фундаментальный примитив, лежащий в основе каждой AI-функции, которая делает что-то помимо разговора — ассистенты бронирования, чат-боты для поиска данных, автономные агенты для кодинга и любой \"AI, который совершает действия\", — все они полагаются на вызов функций как мост между рассуждением модели и вашими реальными системами. Механика: разработчик определяет набор доступных функций с именами, описаниями и типизированными параметрами (схема, которую модель использует, чтобы понять, что доступно и когда это использовать); когда запрос пользователя требует одну из этих функций, модель не вызывает её напрямую — она выводит структурированный запрос, указывающий имя функции и аргументы, код вашего приложения выполняет фактическую функцию относительно вашего реального бэкенда, и результат отправляется обратно модели как новое сообщение, чтобы она могла включить эти реальные данные в свой окончательный ответ. Конкретный пример: SaaS-ассистенту для планирования встреч дано определение инструмента `{\"name\": \"check_calendar_availability\", \"parameters\": {\"date\": \"string\", \"duration_minutes\": \"integer\"}}`. Пользователь спрашивает: \"могу ли я встретиться с Сарой завтра днём на 30 минут?\" Модель понимает, что ей нужны реальные данные, которых у неё нет, и выводит `{\"tool_call\": \"check_calendar_availability\", \"arguments\": {\"date\": \"2026-07-03\", \"duration_minutes\": 30}}`; ваше приложение выполняет это относительно реального API календаря, получает обратно `{\"available_slots\": [\"14:00\", \"15:30\"]}`, отправляет это обратно модели, и модель отвечает пользователю: \"Да — Сара свободна завтра в 14:00 или в 15:30 на 30 минут. Забронировать одно из этих время?\" Вызов функций также является механизмом, лежащим в основе MCP (Model Context Protocol), который стандартизирует, как инструменты предоставляются моделям в разных приложениях. Определения функций\u002Fинструментов выигрывают от той же дисциплины проектирования, что и хорошо документированный API: чёткие, конкретные описания того, что делает каждая функция и когда её использовать (а не только типы параметров), ощутимо улучшают то, насколько надёжно модель выбирает правильный инструмент и заполняет корректные аргументы — плохо описанная функция `search(query)` провоцирует непоследовательное использование, тогда как `search_customer_invoices(customer_id, date_range)` с явным описанием того, что именно она ищет, оставляет модели гораздо меньше пространства для ошибки. Разработчикам также следует валидировать и очищать аргументы инструментов, предоставленные моделью, перед их выполнением относительно реальных систем — точно так же, как они бы валидировали любой другой недоверенный ввод, поскольку модель иногда может выдавать некорректные или неожиданные значения аргументов, которым не следует слепо доверять только потому, что они пришли от AI.","Вызов функций позволяет LLM обращаться к внешним инструментам или API, выводя структурированный запрос, который выполняет ваше приложение.",null,[11,14,17],{"slug":12,"name":13},"agentic","Агентный AI (Agentic AI)",{"slug":15,"name":16},"grounding","Обоснование (Grounding)",{"slug":18,"name":19},"mcp","Протокол контекста модели (MCP)",[21,23,27,31,34,37,40,43,46,49,52,55],{"slug":12,"category":5,"name":13,"updated_at":22},"2026-08-24T02:46:36+00:00",{"slug":24,"category":5,"name":25,"updated_at":26},"alignment-tax","Налог на выравнивание (Alignment Tax)","2026-08-24T02:46:37+00:00",{"slug":28,"category":5,"name":29,"updated_at":30},"artificial-intelligence","Искусственный интеллект (ИИ)","2026-08-24T02:46:38+00:00",{"slug":32,"category":5,"name":33,"updated_at":22},"attention","Внимание (Attention)",{"slug":35,"category":5,"name":36,"updated_at":30},"beam-search","Лучевой поиск",{"slug":38,"category":5,"name":39,"updated_at":26},"benchmark-contamination","Загрязнение бенчмарка (Benchmark Contamination)",{"slug":41,"category":5,"name":42,"updated_at":26},"catastrophic-forgetting","Катастрофическое забывание (Catastrophic Forgetting)",{"slug":44,"category":5,"name":45,"updated_at":30},"computer-vision","Компьютерное зрение",{"slug":47,"category":5,"name":48,"updated_at":26},"constitutional-ai","Конституционный ИИ (Constitutional AI)",{"slug":50,"category":5,"name":51,"updated_at":22},"context-window","Контекстное окно",{"slug":53,"category":5,"name":54,"updated_at":30},"deep-learning","Глубокое обучение",{"slug":56,"category":5,"name":57,"updated_at":22},"diffusion-model","Диффузионная модель (Diffusion Model)"]