Los modelos de lenguaje grandes (LLM) no pueden acceder a datos en tiempo real ni a sistemas externos. Function Calling permite a los modelos llamar a herramientas externas, como APIs, bases de datos y funciones definidas por el usuario. Esto permite que un modelo recupere información o realice acciones más allá de sus capacidades integradas.
Funcionamiento
Function Calling funciona mediante una interacción de varios pasos entre su aplicación y el LLM:
- Realizar la primera llamada al modelo La aplicación envía la pregunta del usuario y una lista de herramientas disponibles al LLM.
-
Recibir instrucciones de llamada a herramientas del modelo
Si el modelo decide llamar a una herramienta externa, devuelve una instrucción JSON que especifica el nombre de la función y los parámetros de entrada.
Si el modelo decide no llamar a una herramienta, devuelve una respuesta en lenguaje natural.
- Ejecutar la herramienta en la aplicación La aplicación ejecuta la herramienta especificada y obtiene la salida.
- Realizar la segunda llamada al modelo Agregue la salida de la herramienta al arreglo messages y llame al modelo nuevamente.
- Recibir la respuesta final del modelo El modelo combina la salida de la herramienta con la pregunta del usuario para generar una respuesta en lenguaje natural.
Modelos admitidos
- Qwen
- DeepSeek
- GLM
- Kimi
- MiniMax
-
Modelos de generación de texto
- Qwen-Max: serie Max de Qwen4 (solo Token Plan), serie Qwen3.8-Max, serie Qwen3.7-Max, serie Qwen3.6-Max, serie Qwen3-Max y serie Qwen-Max
- Qwen-Plus: serie Qwen3.7-Plus, serie Qwen3.6-Plus, serie Qwen3.5-Plus y serie Qwen-Plus.
- Qwen-Flash: serie Qwen3.7-Flash, serie Qwen3.6-Flash, serie Qwen3.5-Flash y serie Qwen-Flash
- Qwen-Coder: serie Qwen3-Coder, serie Qwen2.5-Coder y serie Qwen-Coder
- Qwen-Turbo: serie Qwen-Turbo
- Serie de código abierto Qwen3.6
- Serie de código abierto Qwen3.5
- Serie de código abierto Qwen3
- Serie de código abierto Qwen2.5
- Serie de código abierto Qwen3.8
-
Modelos multimodales
- Qwen-VL: serie Qwen3-VL-Plus y serie Qwen3-VL-Flash
- Qwen-Omni: Qwen3.8-Omni-Flash, serie Qwen3.5-Omni-Plus, serie Qwen3.5-Omni-Flash y serie Qwen3-Omni-Flash
- Qwen-Omni-Realtime: Qwen3.8-Omni-Flash-Realtime, serie Qwen3.5-Omni-Plus-Realtime y serie Qwen3.5-Omni-Flash-Realtime
- Serie de código abierto Qwen3-VL
-
Modelos de chat de voz
- Qwen-Audio-Realtime: Qwen-Audio-3.1-Realtime-Plus, serie Qwen-Audio-3.0-Realtime-Plus y serie Qwen-Audio-3.0-Realtime-Flash
Introducción
Antes de comenzar, obtenga una clave API y configúrela como variable de entorno. Si utiliza el SDK de OpenAI o el SDK de DashScope, también debe instalar el SDK.
El siguiente ejemplo muestra el flujo completo de Function Calling para un escenario de consulta meteorológica.
- Compatible con OpenAI
- DashScope
Cómo usar
Function Calling admite dos formas de pasar información de herramientas:
- Método 1: Pasar información mediante el parámetro tools (recomendado) Para más información, consulte Cómo utilizar. Siga los pasos para definir herramientas, crear un arreglo de mensajes, realizar una Function Calling, ejecutar la función de herramienta y hacer que el LLM resuma la salida de la función de herramienta.
-
Método 2: Pasar información mediante un mensaje del sistema
Pasar información a través del parámetro
toolsproporciona los mejores resultados porque el servidor se adapta automáticamente a la plantilla de prompt óptima. Si está utilizando un modelo Qwen y no want usar el parámetrotools, consulte Pasar información de herramientas a través de un mensaje del sistema.
tools.
Suponga un escenario empresarial que recibe dos tipos de preguntas: consultas meteorológicas y consultas de hora.
1. Definir herramientas
Las herramientas conectan los LLM a servicios externos. Primero debe definir las herramientas.
1.1. Crear funciones de herramienta
Cree dos funciones de herramienta: una herramienta de consulta meteorológica y una herramienta de consulta de hora.
-
Herramienta de consulta meteorológica
Esta herramienta recibe el parámetro
arguments. El formato deargumentses{"location": "queried location"}. La salida de la herramienta es una cadena con el formato:"{location} today is {weather}".Con fines de demostración, la herramienta de consulta meteorológica definida aquí no consulta realmente el clima. Selecciona aleatoriamente entre soleado, nublado o lluvioso. En un escenario empresarial real, puede reemplazar esto con una herramienta como Amap Weather.
-
Herramienta de consulta de hora
La herramienta de consulta de hora no requiere ningún parámetro de entrada. La salida de la herramienta es una cadena con el formato:
"Current time: {queried time}.".Si utiliza Node.js, ejecute
npm install date-fnspara instalar el paquete date-fns para obtener la hora.
1.2. Crear el arreglo de herramientas
Antes de que los humanos puedan elegir una herramienta, necesitan entender su función, escenarios de uso y parámetros de entrada. Lo mismo aplica para los LLM. El modelo selecciona la herramienta adecuada basándose en esta información. Proporcione la información de la herramienta en el siguiente formato JSON.
| Para la herramienta de consulta meteorológica, el formato de la información de descripción de la herramienta es el siguiente: |
tools) en su código. Este arreglo incluye el nombre de la función, la descripción y la definición de parámetros para cada herramienta. El arreglo se pasa como parámetro en las solicitudes posteriores.
2. Crear el arreglo messages
Function Calling pasa instrucciones y contexto al LLM a través del arreglo messages. Antes de realizar una llamada, el arreglo messages debe contener un System Message y un User Message.
Mensaje del sistema
Aunque la función y los escenarios de uso de las herramientas se han descrito cuando usted creó el arreglo de herramientas, enfatizar aún más cuándo llamar a las herramientas en el mensaje del sistema generalmente mejora la precisión de la llamada a herramientas. Para el escenario actual, puede configurar el System Prompt en:
Mensaje del usuario
El User Message se utiliza para transmitir la pregunta del usuario. Suponiendo que el usuario pregunte "Clima en Shanghái", el arreglo messages en este punto es:
Dado que las herramientas disponibles incluyen consultas meteorológicas y de hora, también puede preguntar por la hora actual.
3. Realizar una llamada de Function Calling
Pase los elementos tools y messages creados al LLM para realizar una Function Calling. El LLM determina si debe llamar a una herramienta. Si lo hace, devuelve el nombre de la función de la herramienta y los parámetros.
Para ver los modelos compatibles, consulte Modelos compatibles.
"get_current_weather" y el parámetro de entrada de la función como "{\"location\": \"Shanghai\"}".
content. Cuando usted ingresa "Hola", el parámetro tool_calls está vacío, y el formato del objeto devuelto es:
Si el parámetrotool_callsestá vacío, su programa puede devolver directamente elcontentsin ejecutar los siguientes pasos.
Si usted want que el LLM seleccione una herramienta específica cada vez que realiza una Function Calling, consulte Llamada forzada a herramienta.
4. Ejecutar la función de herramienta
Ejecutar la función de herramienta traduce la decisión del modelo en una operación real.
El proceso de ejecución de la función de herramienta lo completa su entorno informático, no el LLM.El LLM solo genera una cadena. Antes de ejecutar la función de herramienta, usted necesita analizar por separado el nombre de la función de herramienta y sus parámetros de entrada.
-
Función de herramienta
Cree un mapeo
function_mapperdesde el nombre de la función de herramienta hacia la entidad de la función de herramienta para asignar la cadena de función de herramienta devuelta a la entidad de la función de herramienta. - Parámetros de entrada Los parámetros de entrada devueltos por Function Calling son una cadena JSON. Utilice una herramienta para analizarla en un objeto JSON y extraer la información de los parámetros de entrada.
En escenarios empresariales reales, muchas herramientas realizan acciones específicas (como enviar correos electrónicos o cargar archivos) en lugar de consultar datos, y no generan una cadena. Recomendamos agregar información de descripción de estado (como "Correo electrónico enviado correctamente" u "Operación fallida") para dichas herramientas para ayudar al LLM a comprender el estado de ejecución.
5. Permitir que el LLM resuma la salida de la función de herramienta
El formato de salida de la función de herramienta es relativamente fijo. Devolverlo directamente al usuario podría sonar robótico. Envíe la salida de la herramienta al contexto del modelo y llame al modelo nuevamente para generar una respuesta en estilo de lenguaje natural.
-
Agregar un mensaje de asistente
Después de que usted realiza una Function Calling, obtiene un Assistant Message a través de
completion.choices[0].message. Primero, agréguelo al arreglomessages. -
Agregar un mensaje de herramienta
Agregue la salida de la herramienta al arreglo
messagesen el formato{"role": "tool", "content": "tool output", "tool_call_id": completion.choices[0].message.tool_calls[0].id}.- Asegúrese de que la salida de la herramienta esté en formato de cadena.
tool_call_ides un identificador único generado por el sistema para cada solicitud de llamada a herramienta. El modelo puede solicitar llamar a varias herramientas a la vez. Al devolver múltiples resultados de herramientas al modelo,tool_call_idgarantiza que el resultado de salida de la herramienta pueda coincidir con su intención de llamada.
messages es:
messages, ejecute el siguiente código.
content: "El clima en Shanghái hoy está nublado. Si tiene alguna otra pregunta, no dude en consultar".
Uso avanzado
Especificar el método de llamada a herramientas
Llamada a herramientas en paralelo
kimi-k3 no admite controlar medianteUna consulta del clima de una sola ciudad requiere solo una llamada a herramienta. Si una pregunta requiere múltiples llamadas a herramientas, como "¿Cómo está el clima en Beijing y Shanghái?" o "¿Cómo está el clima en Hangzhou y qué hora es ahora?", el modelo puede devolver varias llamadas a herramientas en una sola respuesta después de que usted realice una llamada de función, ya queparallel_tool_callssi las llamadas a herramientas son paralelas: establecerlo enfalsepuede seguir devolviendo variostool_callsen un mismo turno. Recorra y procese todas las llamadas a herramientas que devuelva realmente el modelo.
parallel_tool_calls tiene el valor predeterminado true. Por ejemplo, si pregunta "¿Cómo está el clima en Beijing y Shanghái?", el arreglo tool_calls en el objeto devuelto contiene la información de parámetros de entrada tanto para Pekín como para Shanghái:
parallel_tool_calls en false cuando realice una llamada de función:
La llamada paralela a herramientas es adecuada para tareas que no tienen dependencias. Si existen dependencias entre tareas (la entrada de la herramienta A está relacionada con la salida de la herramienta B), consulte Introducción para implementar llamadas a herramientas en serie (llamar a una herramienta a la vez) a través de un bucle
while.Llamada forzada a herramientas
Los LLM generan contenido con un grado de incertidumbre y pueden elegir la herramienta incorrecta. Para forzar el uso o la desactivación de una herramienta específica para un determinado tipo de pregunta, puede modificar el parámetro tool_choice. El valor predeterminado del parámetro tool_choice es "auto", lo que significa que el LLM decide autónomamente cómo realizar una llamada a herramienta.
Cuando el LLM resuma la salida de la función de herramienta, elimine el parámetro tool_choice. De lo contrario, la API seguirá devolviendo información de llamada a la herramienta.
-
Forzar el uso de una herramienta específica
Si want que Function Calling fuerce la llamada a una herramienta específica para un determinado tipo de pregunta, puede establecer el parámetro
tool_choiceen{"type": "function", "function": {"name": "the_function_to_call"}}. El LLM no participará en la selección de herramientas y solo generará la información del parámetro de entrada. Suponiendo que el escenario actual solo involucra preguntas de consulta meteorológica, puede modificar el códigofunction_callinga:
get_current_weather.
Antes de utilizar esta estrategia, asegúrese de que la pregunta esté relacionada con la herramienta seleccionada. De lo contrario, podría devolver resultados inesperados.
tool_calls en el objeto devuelto no está vacío), puede establecer el parámetro tool_choice en "required". Function Calling entonces siempre devolverá información de la herramienta y de los parámetros de entrada.
Los modelos de la serie Qwen no admiten configurarSuponiendo que todas las preguntas en el escenario actual requieren una llamada a herramienta, puede modificar el códigotool_choicecomo"required": en modo sin pensamiento,requiredno puede garantizar que siempre se llame a una herramienta, y en modo de pensamiento no se admite"required".
function_calling a:
tool_calls en el objeto devuelto nunca estará vacío.
Antes de utilizar esta estrategia, asegúrese de que la pregunta esté relacionada con las herramientas. De lo contrario, podría devolver resultados inesperados.
-
Forzar no usar herramientas
Si necesita que Function Calling nunca realice una llamada a herramienta (el objeto devuelto contiene contenido de respuesta en
contenty el parámetrotool_callsestá vacío), puede establecer el parámetrotool_choiceen"none", o no pasar el parámetrotools. El parámetrotool_callsdevuelto por Function Calling siempre estará vacío. Suponiendo que ninguna pregunta en el escenario actual requiere una llamada a herramienta, puede modificar el códigofunction_callinga:
Conversación multironda
Un usuario podría preguntar "Clima en Beijing" en el primer turno, y luego "¿Qué tal en Shanghái?" en el segundo. Si el contexto del modelo carece de la información del primer turno, el modelo no puede determinar qué herramienta llamar. En un escenario de conversación de múltiples turnos, mantenga el arreglo messages completo después de cada turno. Agregue el nuevo mensaje de usuario a este arreglo y luego realice una llamada de función y los pasos subsiguientes. La estructura de messages es la siguiente:
Salida por secuencias
El uso de salida en streaming le permite obtener el nombre de la función de herramienta y la información de los parámetros de entrada en tiempo real, lo que mejora la experiencia del usuario. En este caso:
- La información de parámetros para la llamada a la herramienta se devuelve en fragmentos como un flujo de datos.
- El nombre de la función de herramienta se devuelve en el primer fragmento de datos de la respuesta de transmisión.
arguments):
tool_calls a continuación con el contenido anterior.
Llamada a herramientas con la API Responses
Los ejemplos anteriores se basan en las API de OpenAI Chat Completions y DashScope. Si usted utiliza la API de OpenAI Responses, el proceso general es el mismo, pero el formato de la API presenta las siguientes diferencias:
| Dimensión | Chat Completions | API de Responses |
|---|---|---|
| Formato de definición de herramienta | ||
| Salida de llamada de herramienta | response.choices[0].message.tool_calls | Elementos en response.output donde type es function_call |
| Devolución de resultado de herramienta | ||
| Respuesta final | response.choices[0].message.content | response.output_text |
Llamada a herramientas para modelos omnimodales
Los modelos omnimodales admiten la llamada a herramientas. Los métodos de llamada para la serie Qwen-Omni y la serie Qwen-Omni-Realtime son diferentes.
Serie Qwen-Omni
Utilice qwen3.8-omni-flash para llamadas a herramientas basadas en texto mediante Chat Completions o Responses. Los ejemplos de Python y JavaScript a continuación utilizan transmisión por secuencias de Chat Completions y leen deltas de texto y llamadas a herramientas con el pensamiento desactivado. Para entradas de audio/video, consulte Qwen3.8-Omni-Flash.
Los ejemplos establecen reasoning_effort="none" para desactivar el pensamiento. Para llamadas a herramientas que requieren pensamiento, omita el parámetro para usar el valor predeterminado xhigh, y lea reasoning_content, content y tool_calls por separado. En turnos posteriores, incluya el mensaje anterior del asistente con su razonamiento, respuesta y llamadas a herramientas en el historial, seguido de los resultados de las herramientas. preserve_thinking está activado de forma predeterminada. Consulte Pasar contenido de razonamiento.
Primero instale el SDK de OpenAI, configure DASHSCOPE_API_KEY y establezca DASHSCOPE_BASE_URL en el endpoint de Chat Completions de su espacio de trabajo. Utilice la misma región para la clave de API y el endpoint.
arguments), consulte Salida en streaming.
Las llamadas existentes a Qwen3.5-Omni-Plus, Qwen3.5-Omni-Flash y Qwen3-Omni-Flash requierenstream=True. Usemodalities=["text"]al obtener información de herramientas; omita los fragmentos de audio cuando Qwen3.5-Omni también genere audio.
Serie Qwen-Omni-Realtime
Qwen3.8-Omni-Flash-Realtime, Qwen3.5-Omni-Plus-Realtime y Qwen3.5-Omni-Flash-Realtime admiten Function Calling personalizado para conversaciones de voz. El siguiente flujo de trabajo utiliza el SDK de DashScope o el protocolo WebSocket nativo. Para la conexión y configuración del SDK, consulte la guía en tiempo real.
Para las herramientas MCP ejecutadas en el servidor y el flujo de aprobación en Qwen3.8-Omni-Flash-Realtime, consulte Interacción MCP.
Flujo de trabajo:
Después de establecer una conexión WebSocket, pase la definición de herramienta mediante session.update para entrar en el siguiente flujo de interacción:
Fase 1: Entrada de voz y llamada a herramientas
- El usuario hace una pregunta por voz. El cliente recopila el audio y lo envía al servidor (correspondiente al método
append_audio()). Después de que el VAD del servidor detecta el fin del habla, realiza la inferencia del modelo y determina que es necesario llamar a una herramienta. - El servidor devuelve la información de la llamada a la herramienta al cliente (correspondiente al evento
response.function_call_arguments.done), incluyendo el nombre de la función (name), los parámetros de entrada de la función (arguments) y el identificador de llamada (call_id). Un ejemplo es el siguiente:
- El cliente ejecuta localmente la función de herramienta correspondiente basándose en el nombre de la función y los parámetros de entrada para obtener el resultado de la ejecución.
- El cliente envía el resultado de la ejecución de la herramienta de vuelta al servidor (correspondiente al evento
conversation.item.create), incluyendo el identificador de llamada (call_id) y el resultado de la ejecución (output). Un ejemplo es el siguiente:
- El cliente continúa enviando un evento
response.createpara activar al servidor a generar la respuesta de voz final basada en el resultado de la ejecución de la herramienta. - El cliente recibe la voz y el texto devueltos por el servidor (correspondientes a los eventos
response.audio.deltayresponse.audio_transcript.delta) y reproduce la respuesta de voz al usuario.
La serie Qwen-Omni-Realtime no admite los parámetrostool_choiceyparallel_tool_calls.
Para más información sobre Qwen-Omni-Realtime, consulte Tiempo real (Qwen-Omni-Realtime), Eventos del cliente y Eventos del lado del servidor.
DashScope Python SDK
Llamada a herramientas para modelos de pensamiento profundo
Los modelos de pensamiento profundo realizan inferencias antes de generar la información de llamada a la herramienta, lo que mejora la interpretabilidad y la fiabilidad de las decisiones.
- Proceso de pensamiento El modelo analiza la intención del usuario, identifica las herramientas necesarias, verifica la validez de los parámetros y planifica la estrategia de llamada paso a paso.
-
Llamada a herramientas
El modelo genera una o más solicitudes de llamada a función en un formato estructurado.
Se admite la llamada a herramientas en paralelo.
Para obtener más información sobre los modelos de pensamiento de generación de texto, consulte Pensamiento profundo. Para obtener más información sobre los modelos de pensamiento multimodal, consulte Comprensión de imágenes y videos y No en tiempo real (Qwen-Omni).En modo de pensamiento (
enable_thinking=True), el parámetro tool_choice no admite ser establecido en "required" o en un objeto (por ejemplo, {"type": "function", "function": {...}}). Establecer tool_choice en cualquiera de estos valores mientras el modo de pensamiento está activado provoca que la solicitud falle con el error The tool_choice parameter does not support being set to required or object in thinking mode. Si necesita llamadas a herramientas MCP confiables mientras el modo de pensamiento está activado, utilice la API de Responses para conectarse a MCP en su lugar.
- Compatible con OpenAI
- DashScope
- Python
- Node.js
- HTTP
Código de ejemplo
Resultado devuelto
Ingrese "Clima en los cuatro municipios" para obtener el siguiente resultado:Puesta en marcha
Probar la precisión de la llamada a herramientas
- Establecer un sistema de evaluación: Construya un conjunto de datos de prueba que refleje escenarios comerciales del mundo real y defina métricas de evaluación claras, como la precisión en la selección de herramientas, la precisión en la extracción de parámetros y la tasa de éxito de extremo a extremo.
- Optimización de prompts Basándose en los problemas identificados durante las pruebas, como selecciones incorrectas de herramientas o parámetros, usted puede optimizar los prompts del sistema, las descripciones de herramientas y las descripciones de parámetros.
-
Actualización del modelo
Si el ajuste de prompts no logra mejorar el rendimiento, actualizar a una versión de modelo más potente, como
qwen3.6-plus, es el método más directo y efectivo.
Controlar dinámicamente el número de herramientas
Cuando una aplicación integra decenas o incluso cientos de herramientas, proporcionarlas todas al modelo puede causar los siguientes problemas:
- Degradación del rendimiento: La dificultad del modelo para seleccionar la herramienta correcta de un gran conjunto de herramientas aumenta drásticamente.
- Costo y latencia: Muchas descripciones de herramientas consumirán una gran cantidad de tokens de entrada, lo que provocará un aumento de costos y respuestas más lentas.
-
Recuperación semántica
Convierta las descripciones de herramientas (
description) en vectores utilizando un modelo de embedding y almacénelos en una base de datos vectorial. Cuando un usuario envíe una consulta, usted puede realizar una búsqueda de similitud vectorial sobre el vector de consulta para recuperar las K herramientas más relevantes. -
Recuperación híbrida
Este método combina la coincidencia difusa de la recuperación semántica con la coincidencia exacta de palabras clave tradicionales o etiquetas de metadatos. Para hacer esto, agregue campos de
tagsokeywordsa las herramientas. Durante la recuperación, realizar tanto búsqueda vectorial como filtrado de palabras clave puede mejorar significativamente la precisión de recuperación, especialmente para escenarios específicos o de alta frecuencia. - Enrutador LLM ligero Para una lógica de enrutamiento más compleja, usted puede usar un modelo más pequeño, rápido y económico, como Qwen-Flash, como modelo enrutador. La tarea de este modelo es generar una lista de nombres de herramientas relevantes basándose en la consulta del usuario.
- Mantenga el conjunto de candidatos conciso: Independientemente del método utilizado, recomendamos proporcionar no más de 20 herramientas al modelo principal. Esto proporciona un equilibrio óptimo entre la carga cognitiva del modelo, el costo, la latencia y la precisión.
- Estrategia de filtrado por capas: Puede crear una estrategia de enrutamiento tipo embudo. Por ejemplo, primero puede utilizar coincidencias de palabras clave o reglas de bajo costo para filtrar herramientas claramente irrelevantes. Luego, puede realizar una recuperación semántica en las herramientas restantes para mejorar la eficiencia y la calidad.
Principios de seguridad de herramientas
Al otorgar capacidades de ejecución de herramientas a un LLM, la seguridad es la consideración principal. Los principios fundamentales son el privilegio mínimo y la confirmación humana.
- Principio de menor privilegio: El conjunto de herramientas proporcionado al modelo debe adherirse estrictamente al principio de menor privilegio. De forma predeterminada, las herramientas deben ser de solo lectura, como herramientas para consultar el clima o buscar documentos. Evite proporcionar cualquier permiso de "escritura" que implique cambios de estado u operaciones de recursos.
- Aísle las herramientas peligrosas: No proporcione herramientas peligrosas directamente al LLM, como herramientas para ejecutar código arbitrario (
code interpreter), operar el sistema de archivos (fs.delete), realizar operaciones de eliminación o actualización de bases de datos (db.drop_table) o manejar transacciones financieras (payment.transfer). - Participación humana: Se requiere un proceso de revisión y confirmación manual para todas las operaciones de alto privilegio o irreversibles. El modelo puede generar una solicitud de operación, pero el botón final de "ejecutar" debe ser pulsado por un usuario humano. Por ejemplo, el modelo puede preparar un correo electrónico, pero el usuario debe confirmar la operación de envío.
Optimización de la experiencia del usuario
El proceso de llamada a función implica múltiples pasos, y un problema en cualquier paso puede afectar negativamente la experiencia del usuario.
Gestionar fallos en la ejecución de herramientas
Los fallos en la ejecución de herramientas son comunes. Puede adoptar las siguientes estrategias:
- Reintentos máximos: Establezca un límite de reintentos razonable, como 3, para evitar largas esperas del usuario o desperdicio de recursos del sistema debido a fallos continuos.
- Proporcione respuestas alternativas: Si se agotan los reintentos o se encuentra un error irresoluble, devuelva un mensaje claro y amigable al usuario, como: "Lo siento, no puedo encontrar la información relevante en este momento. El servicio podría estar ocupado. Por favor, inténtelo de nuevo más tarde".
Gestionar la latencia de procesamiento
Una alta latencia puede reducir la satisfacción del usuario. Puede implementar optimizaciones tanto en el frontend como en el backend.
- Establecer un tiempo de espera: Configure un tiempo de espera independiente y razonable para cada paso del proceso de llamada a funciones. Si ocurre un tiempo de espera, la operación debe interrumpirse inmediatamente y se debe proporcionar retroalimentación al usuario.
- Proporcionar retroalimentación instantánea: Cuando comienza una llamada a función, recomendamos mostrar un aviso en la interfaz, como "Consultando el clima para usted..." o "Buscando información relevante...". Esto brinda al usuario retroalimentación en tiempo real sobre el progreso.
Facturación
Además de los tokens en el arreglo messages, las descripciones de herramientas también se facturan como tokens de entrada.
Pasar información de herramientas a través de un mensaje del sistema
Pasar información de herramientas a través de un mensaje del sistema
Recomendamos pasar información de herramientas al modelo de lenguaje grande (LLM) utilizando el parámetro
tools, como se describe en la sección Cómo usar. Para pasar información de herramientas a través de un mensaje del sistema, utilice la plantilla de prompt en el siguiente código para un rendimiento óptimo del modelo:- Compatible con OpenAI
- DashScope
- Python
- Node.js
Código de ejemplo
Después de ejecutar el código anterior, usted puede usar un analizador XML para extraer la información de la llamada a la herramienta, incluido el nombre de la función y los parámetros de entrada, de entre las etiquetas<tool_call>y</tool_call>.