Contador de tokens de LangChain: Estimación de auditoría y cobertura de uso

La respuesta útil no es pick one LangChain token counter. Utilice dos contadores diferentes para dos decisiones diferentes. Ejecutar count tokens approximately() antes de una llamada de modelo cuando necesita una estimación rápida de la presión de contexto. Lea el AIMessage.usage metadata reportado por el proveedor después de la llamada cuando necesite el uso de entrada, salida, caché o razonamiento observado. Luego, comparar los registros de uso con un manifiesto de llamada de modelo esperado. Sin ese último cheque de cobertura, un total ordenado puede ser bajo sólo porque una llamada nunca fue contada. Esa distinción importa en un agente. Una estimación de la historia del mensaje puede ayudar a decidir si se debe recortar el contexto. No puede probar lo que el proveedor procesó, lo que facturó, si un retraso emitió el uso, o si una llamada de modelo anidada escapó a la llamada de regreso. La cuestión operativa es, por tanto: ¿Cuál es el tren de contabilidad que apoya esta decisión, y cómo sabemos que todas las llamadas esperadas llegaron a ella? Tratar la aproximación y el uso del proveedor como pruebas separadas La referencia Python actual de LangChain describe count tokens approximately() como una aproximación simple. Por defecto, divide los caracteres por cuatro, agrega tres tokens por mensaje y ronda de manera conservadora. La función cuenta el contenido del mensaje y los roles. También cuenta con las llamadas de herramientas AI, ID de llamadas de mensajes de herramientas, nombres opcionales, una asignación de imagen fija y esquemas de herramientas suministrados a través del argumento tools . La documentación dice explícitamente que se requieren tokenizers específicos del modelo para contar con precisión. Eso hace que la función sea útil antes de invocar: El detalle de tools=bound tools no es cosmético. La implementación serializa cada esquema suministrado y añade sus caracteres a la aproximación. Si un modelo está ligado a herramientas pero el contador recibe sólo messages , la estimación puede omitir una gran superficie de entrada repetida. Por el contrario, pasar herramientas no hace que el proveedor del resultado sea exacto. Se mantiene una estimación basada en una relación genérica y derechos fijos. Después de la invocación, utilice los metadatos del AIMessage devuelto: LangChain estandariza UsageMetadata alrededor de input tokens , output tokens y total tokens , con mapas de detalles de entrada y salida opcionales. Su propio ejemplo incluye la creación de caché, lecturas de caché, audio y razonamiento. Optional es la palabra importante. Un campo cache read faltante es una evidencia no disponible, no prueba de que el valor fue cero. Conservar esa distinción en el almacenamiento en lugar de llenar los detalles ausentes con 0 . Para múltiples llamadas, UsageMetadataCallbackHandler agrega AIMessage.usage metadata a través de modelos: La agregación es conveniente, pero una agregación responde lo que el manipulador vio,no lo que el flujo de trabajo debería haber llamado.Guardar registros por intento también. Indique a cada intento de modelo un call id estable, un attempt id , el nombre del proveedor/modelo resuelto y un sello de tiempo. Un nuevo intento es un segundo intento, no una corrección al primer contador. Construir una prueba de cobertura alrededor del manifiesto de llamada de modelo Comience con el trabajo esperado, no con las filas de uso que existen. Para una carrera de cuatro etapas, el manifiesto puede requerir plan:1 , retrieve:1 , draft:2 y verify:1 . El sufijo es el número de intento. El verificador se suma entonces a los intentos previstos a tres formas de evidencia: una aproximación previa al vuelo, incluidos los mensajes y los esquemas de herramientas requeridos; el uso informado por el proveedor del mensaje devuelto o de la llamada de regreso; el recibo de nivel de tarea que dice que la etapa produjo su efecto esperado. La unión produce estados más útiles que un total: El Estado Lo que existe Interpretación segura provider reported uso del proveedor, con la identidad de la llamada uso observado para ese intento approximate only estimación previa al vuelo, sin uso del proveedor estimación del contexto; uso de la facturación no disponible missing call fila manifiesta, sin observación la brecha de instrumentación o la etapa nunca se ejecutó detail unavailable Total del proveedor, falta de detalles de caché/razón esperados el total puede utilizarse; el análisis de componentes está bloqueado duplicate attempt dos filas de uso para una identificación de intento riesgo de agregación; fija la identidad antes de sumar La fijación que acompaña parece deliberadamente plausible mientras permanece incompleta. Contiene cuatro llamadas esperadas. Dos tienen uso de proveedor, uno tiene sólo una aproximación, y uno no tiene observación. Las dos filas de proveedores suman 1.451 tokens. Ese número es aritméticamente correcto y operacionalmente incompleto. Realizar la auditoría: El resultado es: Las dos llamadas que tienen ambas formas de evidencia también demuestran por qué una estimación debe conservar su etiqueta. La aproximación fue de 5,0% por debajo del total de proveedores para una llamada y de 16,5% por debajo de otra. Esta fijación no afirma que dichos porcentajes sean generalizados; los valores son datos de ensayo fijos. Demuestra que la auditoría mantiene las estimaciones fuera del total del proveedor observado y puede exponer los desacuerdos sin tratar a ninguno de los ejemplos como un factor de calibración universal. Un detalle sutil de la implementación actual merece cautela. El use usage metadata scaling=True opcional de LangChain toma el mensaje AI más reciente con uso, requiere un proveedor consistente y escala la aproximación hacia arriba. La fuente acalma ese factor entre 1.0 y 1.25 ; no escala una estimación hacia abajo. Esta puede ser una estimación histórica conservadora útil. No es un algoritmo de reconciliación para facturas, proveedores mixtos o llamadas faltantes. Decidir qué cuenta se le permite conducir Añade un límite de decisión a cada número almacenado. Utilice una aproximación a: advertir antes de que una historia se acerque a un límite de contexto suave; comparar dos variantes de esquemas de respuesta rápida o de herramientas antes de enviarlas; decidir si se resumen, se retiran o se abandonan los contextos sustituibles; estimar el efecto relativo de incluir otro mensaje o esquema de herramienta. Utilice el uso informado por el proveedor para: atribuir la entrada y salida observadas a un intento de modelo completado; los componentes de caché, audio o de razonamiento separados cuando los devuelva el proveedor; conciliar los totales de proveedores/modelos entre los intentos; calcular el coste únicamente con una fuente de precio fechada y un manejo explícito para detalles no disponibles. No utilice ningún contador solo para probar: que cada llamada modelo esperada haya sido instrumentada; que una llamada de herramienta haya llegado a su destino; que existe el rendimiento esperado; que un nuevo ensayo fue seguro o útil; que una ejecución con un token bajo logró el resultado solicitado. Esas afirmaciones necesitan cobertura de llamadas y pruebas de resultados. Una aplicación compacta puede hacer cumplir cuatro reglas de promoción: 1. Cada attempt id esperado tiene exactamente una observación. 2. Cada llamada observada está etiquetada approximate o provider reported ; las etiquetas nunca se fusionan silenciosamente. 3. Las estimaciones previas al vuelo con herramientas demuestran que el conjunto de esquemas fue enviado al mostrador. 4. El proveedor o el detalle de caché que faltan permanece null /no disponible y bloquea solo las decisiones que lo requieren. El umbral no tiene por qué ser universalmente del 100%. Una vista previa no productiva podría permitir una cobertura aproximada. No debería haber una alerta presupuestaria o una devolución de cargos por parte de los clientes. Encifrar la política junto al consumidor: context warning puede aceptar estimaciones, mientras que cost reconciliation requiere un uso completo del proveedor y IDs únicos de intento. Compruebe el límite antes de optimizar El incumplimiento razonable es sencillo: estimar antes, observar después, la cobertura de auditoría en el límite de ejecución. Optimiza sólo después de los tres trabajos. Si una estimación de contexto es alta, inspeccione sus entradas antes de recortar. ¿Se incluyó el conjunto completo de herramientas? ¿Todavía se necesitan resultados de las herramientas para la próxima decisión? ¿Es un mensaje largo un recibo de decisión duradero o una narración reemplazable? Eliminar el contexto equivocado puede hacer que una carrera sea más barata y menos confiable. Si el uso del proveedor es inesperadamente bajo, compruebe si faltan llamadas antes de celebrar. Los fragmentos de transmisión de confirmación se combinaron en el mensaje final, las llamadas de retorno se propagaron en ejecutivos infantiles, las retas recibieron identificadores de intento distintos, y la etapa de verificación esperada se ejecutó realmente. Un gráfico de costos con intervalos faltantes no es un resultado de optimización. Si el almacenamiento en caché es importante, requiera el mapa de detalles específico del proveedor y registre su disponibilidad. LangChain le da un sobre común, pero los proveedores no necesariamente llenan todos los componentes. No deducir una falta de cache de una llave faltante. Comparar como con como: mismo proveedor, modelo, superficie de solicitud/herramienta, estado de caché y requerimiento de resultado. Finalmente, adjunta evidencia simbólica a un recibo de tarea. Para un agente de revisión de documentos, el recibo puede contener la revisión de la fuente, las secciones requeridas comprobadas, afirmaciones fallidas y hash de salida. Los tokens por llamada exitosa siguen siendo un denominador débil si el artefacto final está ausente. Este diseño de dos carriles es intencionalmente más estrecho que una pila de observabilidad genérica. Responde a una decisión concreta: si un número de token de LangChain es una estimación de contexto, una medición observada del proveedor o una vista incompleta que no debe generar reclamos de costo o optimización. Sidewisp se encuentra actualmente en versión preliminar privada. Los análisis de uso de tokens y de costo estimado se planifican, no se envían. La dirección del producto consiste en conectar las señales de costes con el progreso útil y los resultados verificados, manteniendo al mismo tiempo visibles las pruebas y la incertidumbre. Si ese límite operacional coincide con la forma en que manejas a los agentes, puedes Únete a la vista previa privada. Fuentes Referencia de Python de LangChain: count tokens approximately Una instantánea de fuente de LangChain para el contador aproximado Guía de mensajes de LangChain: uso de tokens en AIMessage Referencia de LangChain: UsageMetadata Referencia de LangChain: UsageMetadataCallbackHandler