En estos dos días, si usted a menudo cepilla los círculos tecnológicos y la comunidad de desarrolladores, es probable que haya sido El Jev El nombre se deslizó.
Curiosamente, no se parece en absoluto al "gran modelo " que conocemos.
No te acompaña a chatear, no es responsable de escribir artículos, y no es adecuado para que escriba un pedazo de código en vivo. Ni siquiera puedes entenderlo como un producto como ChatGPT, Claude.
Sin embargo, es un modelo de "no escribir nada" que ha atraído rápidamente la atención de la comunidad de desarrolladores recientemente.
La razón es simple:
Jev no es para escribir respuestas para las personas, sino para juzgar el programa.
Si los grandes modelos tradicionales son buenos en "generar", lo que Jev está tratando de resolver es otro tipo de problema que es un gran número de sistemas de software, pero a menudo se pasa por alto:
¿Cuál es el próximo paso?
Esto parece ser solo un pequeño cambio, pero en realidad puede corresponder a una dirección muy importante en la arquitectura del agente de IA.
¿Qué es realmente Jev?
Primero aclare algunas de las preguntas más confusas.
Jev de la startup AI de San Francisco TipoSafeEs un modelo de código cerrado.
No es lo mismo que el posicionamiento del producto de ChatGPT y Claude, y no es simplemente cambiar un modelo de chat tradicional por un paquete de API.
Desde el principio de su diseño, Jev se ha centrado en un rango de tareas muy estrecho:
Permite que el modelo complete rápidamente la clasificación, selección, juicio y puntuación.
Por lo tanto, no lo harás como con un LLM ordinario y lo harás:
"Ayúdame a escribir un artículo sobre AI ".
Lo que realmente es bueno en es:
"¿Este mensaje de usuario es un reembolso, logística u otro problema?"
o:
"¿Qué botón de esta página web se adapta mejor a la tarea actual? "
O también:
"¿Debería pasar la auditoría? "
En otras palabras,
El modelo grande tradicional es más como un experto que habla, mientras que Jev es más como un módulo de toma de decisiones de alta velocidad.
En la actualidad, Jev proporciona principalmente servicios a través de API y no tiene ponderación de modelo abierta. Por lo tanto, la mayoría de los proyectos relacionados que se ven en GitHub son aplicaciones y herramientas construidas alrededor de la API Jev por los desarrolladores, en lugar de los pesos de código abierto del modelo Jev en sí.
La diferencia más importante: no es responsable de "escribir ".
La forma más fácil de entender Jev es comparar el LLM tradicional con Jev.
Supongamos que su programa recibió un mensaje de servicio al cliente:
"¿Cuándo me van a devolver el dinero?¡He estado esperando una semana! "
Si se usa ChatGPT o Claude, generalmente es necesario decirle al modelo:
- Análisis de la intención del usuario
- Juicio de emoción
- Clasificación de salida
- Devuelve en el formato JSON especificado
Finalmente, el programa extrae los resultados del texto generado por el modelo.
El problema es que:
Puede que el programa realmente quiera saber sólo una cosa:
refund
o:
true
incluso:
0.93
El largo análisis anterior, es un costo adicional para el programa.
El pensamiento de Jev era exactamente lo contrario.
Dado que el programa solo necesita un juicio en última instancia, no deje que el modelo genere texto extra.
Esto es también lo que más vale la pena prestar atención a Jev.
Resolve principalmente tres tipos de problemas.
Si consideramos a Jev como una API en lugar de un chatbot, entonces sus capacidades se pueden entender simplemente en tres tipos de preguntas.
1. Pregunta de juicio: sí o no
El primero es el juicio booleano.
Por ejemplo:
"¿Este comentario contiene un ataque contra el personal de servicio al cliente? "
El modelo no necesita explicar por qué, ni escribir un análisis.
Da directamente una probabilidad, por ejemplo:
true: 0.94
false: 0.06
Después de que el programa obtiene los resultados, puede decidir por su cuenta:
confidence > 0.8
El proceso correspondiente se activa.
Esto es especialmente conveniente para tareas como la revisión de contenido, el filtro de spam y la desviación automática.
2. Pregunta de elección: Seleccione una de las opciones fijas
La segunda categoría está más cerca de las tareas de clasificación tradicionales.
Por ejemplo, un sistema de servicio al cliente preestablecido:
0 = 账单问题
1 = 物流问题
2 = 退款问题
3 = 其他
La tarea del modelo no es crear una categoría por sí mismo, sino:
Elige entre estas opciones.
Esto es importante para los sistemas de ingeniería.
El LLM tradicional a menudo requiere que pase los requisitos de Prompt:
"Por favor, siga estrictamente el formato JSON. "
Pero el modelo, después de todo, está generando texto, lo que teóricamente sigue siendo posible:
- Explique una frase más
- Error de formato JSON
- Crear una categoría que no existe
- Etiquetas de salida con ortografía diferente
El modelo de opción fija puede restringir directamente el espacio de salida a un conjunto de candidatos especificados por el desarrollador.
Para el programa, esto significa una gran diferencia:
La IA ya no es responsable de "escribir los resultados ", sino de" seleccionar los resultados ".
3. Problemas de calificación: dar una calificación estimada a un objeto
La tercera categoría es el Score.
Por ejemplo, desea juzgar la intensidad emocional de un mensaje de cliente:
1 = 非常平静
2 = 有些不满
3 = 明显不满
4 = 愤怒
5 = 极度愤怒
El modelo no devuelve un análisis de emociones, sino toda la distribución de puntuaciones.
De esta manera el programa puede desarrollar su propia estrategia:
- 1 - 2: Procesamiento automático
- 3: Asumir el servicio general al cliente
- 4 ~ 5: Promover el supervisor manual
AI es responsable de juzgar.
Las reglas de negocio permanecen en manos de los procedimientos.
Es una idea de ingeniería muy importante.
Cuarto, lugar realmente interesante: una entrada, puede responder a muchas preguntas al mismo tiempo
Otra característica de Jev es que se pueden tomar varias decisiones al mismo tiempo en torno a la misma entrada.
Por ejemplo, una orden de trabajo de servicio al cliente, puede estar interesado en:
- ¿A qué categoría de negocio pertenece?
- ¿Cuál es el nivel de urgencia?
- ¿Cómo está el sentimiento del cliente?
- ¿Se requiere una revisión manual?
Los escenarios tradicionales pueden requerir múltiples llamadas al modelo.
Este modelo orientado a la toma de decisiones puede combinar estos problemas para tratarlos.
Una entrada ya no es:
Leer una vez → Generar respuestas → Leer de nuevo → Generar respuestas de nuevo
Y más como:
Leer una vez → Completar varios juicios al mismo tiempo.
Este diseño puede ser más importante para los sistemas que deben manejar un gran número de eventos que simplemente buscar si el modelo "sería mejor escrito".
V. ¿Por qué puede ser tan rápido?
Aquí hay una diferencia fundamental en el método de razonamiento entre Jev y el modelo generativo tradicional.
Los modelos que estamos familiarizados con GPT, Claude y otros dependen en gran medida de la generación de autorregresión.
Simples de entender:
El modelo genera el primer token, luego genera el siguiente token basado en el contenido anterior y luego continúa generando.
Si se le pide que escriba un párrafo, necesita decodificar constantemente token por token.
Sin embargo, para muchas decisiones de programación, simplemente no es necesario generar decenas, cientos o incluso miles de tokens.
Supongamos que la pregunta es simplemente:
"Hay 30 botones en esta página web, ¿cuál debo hacer clic? "
Los resultados que el programa realmente necesita pueden ser simplemente:
button_17
Entonces, ¿por qué hacer que el modelo piense primero, organice el lenguaje y luego produzca una explicación?
Aquí es donde Jev está tratando de cortar.
Limitar el espacio de salida de la IA a un espacio de decisión limitado.
Desde un punto de vista de ingeniería, esto equivale a poner:
"Crear una respuesta "
Convierte en:
"Cálculo de probabilidades y elección entre candidatos limitados ".
La tarea es más simple, la salida es más corta, y los enlaces de razonamiento naturalmente pueden comprimirse enormemente.
Por lo tanto, la métrica central que hace hincapié oficialmente en Jev no es "cuánto tiempo puede escribir ", sino:
¿Cuánto retraso, cuánto cálculo y cuánto dinero se requiere para una decisión?
El verdadero golpe asesino puede no ser "rápido ", sino" probabilidad ".
Si el Jev solo tiene una característica:
"El modelo de clasificación es rápido ".
No fue tan sorprendente.
Lo que es realmente notable es que trata de abordar otro problema de larga data:
¿Qué tan confiable es el modelo?
Los modelos de clasificación tradicionales suelen tener un problema:
El modelo estaba muy seguro de que tenía razón.
Pero, en realidad, puede estar escandalosamente equivocado.
Por ejemplo:
预测：退款问题
置信度：99%
Resultados Después de la inspección manual, se encontró:
Los usuarios realmente están preguntando por la logística.
Si este modelo se pone en un sistema automatizado, el problema es molesto.
Porque un ingeniero podría escribir:
confidence > 95%
→ 自动执行
Si la confianza no está calibrada, este umbral no tiene mucho sentido.
Así que una de las direcciones que Jev enfatiza es queCalibración de probabilidad。
Idealmente:
El modelo dice que tiene un 80% de certeza, entonces las estadísticas a largo plazo, aproximadamente realmente debería tener una tasa de precisión del 80%.
De esta manera, la probabilidad de la salida del modelo es realmente de valor de ingeniería.
Porque en este momento, la IA no solo le dice al programa:
"Creo que la respuesta es A."
También dice al programa:
"¿Qué tan seguro estoy de A? "
Entre estos dos, la diferencia es realmente muy grande.
¿Qué tiene que ver esto con el agente de AI?
Esta puede ser la verdadera razón por la que Jev ha atraído la atención de los desarrolladores recientemente.
En el pasado hablamos de Agentes de IA y a menudo nos centramos en el "cerebro ":
- Mayor razonamiento
- Contexto más amplio
- Un proceso de pensamiento más largo
- Llamadas a herramientas más complicadas
Pero un agente que realmente funciona necesita tomar muchas decisiones muy triviales.
Por ejemplo:
¿Quieres llamar a la búsqueda?
¿Qué herramienta?
¿Se ha completado la tarea actual?
¿Es creíble este resultado?
¿Quieres seguir el ciclo?
¿A qué flujo de trabajo pertenece esta solicitud de usuario?
Ninguna de estas preguntas parece complicada.
Pero un agente puede hacerlo docenas o incluso cientos de veces por minuto.
Si se llama a un LLM de peso pesado cada vez, la latencia y los costos se acumulan rápidamente.
En este momento, un modelo como Jev tiene su lugar:
El modelo grande es responsable del razonamiento complejo, mientras que el modelo pequeño es responsable de la toma de decisiones de alta frecuencia.
Esto puede ser más consistente con la arquitectura de software real que la idea de "resolver todos los problemas con un modelo ".
¿Cómo lo han comenzado a usar los desarrolladores?
En la actualidad, la comunidad ya ha hecho algunos intentos muy representativos.
1. Agente del navegador: Deje que la IA se encargue exclusivamente de "pegar dónde "
La automatización del navegador es un escenario típico.
Después de que un agente abre una página web, a menudo tiene que enfrentar docenas o incluso cientos de elementos DOM.
El verdadero problema es que:
"¿Qué elemento debo elegir para la tarea actual? "
Esto es, naturalmente, una opción.
La comunidad de Browser Use ha aparecido con el nombre El Jev Ultrafast El proyecto utiliza Jev en el proceso de toma de decisiones del agente del navegador.
Browser-use/jev-ultrafast proyecto GitHub
Su idea no es que Jev se encargue de todo el Agente del navegador, sino que se encargue de una capa muy específica:
Seleccione rápidamente la siguiente acción.
y la generación de texto complejo aún se puede dejar a un modelo convencional.
Esta estructura es en realidad muy representativa:
Un Agente no necesariamente necesita un modelo para ser responsable de principio a fin.
2. Juego Agente: Decisiones de alta frecuencia
Los juegos son otro escenario que se adapta perfectamente a este modelo.
Supongamos que una IA juega a Doom, y puede necesitar juzgar a cada instante:
- ¿Izquierda o derecha?
- ¿Disparar o no?
- ¿Quieres cambiar de arma?
- ¿Equivocarse?
- ¿Sigue adelante o no?
Estos movimientos no requieren necesariamente una larga sección de razonamiento.
Es más como:
Introduzca el estado actual → Seleccione la próxima acción.
Si el modelo es capaz de tomar tales decisiones repetidamente con un retraso muy bajo, se abren nuevas posibilidades para escenarios en tiempo real que son difíciles de cubrir con un LLM tradicional.
3. Enrutamiento del agente: Decidir a quién llamar a continuación
En los sistemas multiagentes, esta capacidad es particularmente directa.
Supongamos que el sistema tiene:
搜索 Agent
代码 Agent
数据库 Agent
客服 Agent
人工审核
Después de que el usuario entra, el sistema necesita juzgar:
¿A quién se debe entregar esta solicitud?
Esto es un problema de clasificación.
Un poco más lejos:
¿Debería el agente actual llamar a la herramienta de búsqueda o a la herramienta de base de datos?
Otra pregunta de elección.
Si cada enrutamiento permitiera que los grandes modelos de lenguaje se completaran, el Agente podría gastar una gran cantidad de tiempo "decidiendo qué hacer a continuación por sí mismo".
Un modelo de alta velocidad dedicado al enrutamiento puede separar esta capa.
Nuevo, esto en realidad significa que el futuro de los sistemas de IA puede ser cada vez más "estratificado".
En el pasado, a todos les gustaba discutir:
¿Cuál es el modelo más fuerte? "
Pero para los sistemas de producción reales, el problema puede convertirse lentamente en:
¿Qué modelo es responsable de qué tipo de trabajo?
Un sistema de IA típico podría ser algo así:
用户请求
↓
高速决策模型
↓
┌────────┬────────┬────────┐
↓ ↓ ↓ ↓
搜索工具 数据库 Agent 人工审核
↓
复杂任务
↓
大型推理模型
↓
最终结果
Dentro de este marco:
Los grandes modelos ya no lo hacen todo.
Se encarga de la parte que realmente requiere razonamiento, creación y generación.
Mientras que el modelo de alta velocidad es responsable de una gran cantidad de flujos de control finamente fragmentados.
Desde el punto de vista de la ingeniería de software, esto es realmente muy natural.
Porque los programas de computadora no son impulsados por el lenguaje natural.
Una gran cantidad de lógica de negocio se puede reducir a:
if
else
switch
route
score
filter
Lo que Jev está haciendo es, en esencia, tratar de poner una parte de eso if / switch Hacerse más "inteligente "
10, pero tampoco es absolutamente todopoderoso
Aquí hay una advertencia especial:
El valor de Jev proviene precisamente de su especialidad, que también implica limitaciones.
No es un sustituto de ChatGPT o Claude.
Si la tarea requiere:
- Escrita larga
- Generación de código complejo
- Diálogo multi-ronda
- Preguntas y respuestas de conocimiento abierto
- Inferencia de cadena larga
- Cálculo matemático preciso
Entonces este modelo orientado a la decisión no es adecuado para asumir todo el trabajo directamente.
Además, las tareas como la cobertura del lenguaje, el razonamiento complejo, las matemáticas y la aritmética, las relaciones de fecha y otras tareas también deben verificarse a través de su propio conjunto de pruebas, en lugar de juzgarse solo por los materiales publicitarios del modelo.
También hay un problema que es fácil de pasar por alto:
El modelo comete errores.
Incluso si el modelo da un alto grado de confianza, esto no significa que:
"El procedimiento puede ejecutarse incondicionalmente ".
En particular, se refiere a:
- El reembolso
- El pago
- Borrar datos
- Permiso de modificación
- Base de datos Operación
Estas acciones de alto riesgo aún deben mantener el control de permisos de software tradicional, la verificación de reglas y la cobertura manual.
AI puede hacerse cargo del juicio.
Sin embargo, el límite de seguridad final todavía debe estar en manos del programa.
XI. Entonces, ¿cuál es lo que es realmente interesante en Jev?
Si solo se entiende Jev como:
"Un modelo de clasificación más rápido ".
Es fácil subestimarlo.
Lo que es realmente interesante de esto es que plantea una pregunta muy simple:
¿Realmente necesitamos tener un modelo que escriba largos artículos y participe en cada juicio del procedimiento?
Muchas veces, la respuesta puede ser no.
En un sistema de agente de IA maduro, las tareas de razonamiento más complejas pueden no ser las que realmente consumen mucho costo.
Puede ser exactamente un sinnúmero de pequeñas decisiones:
要不要搜索？
选哪个工具？
是不是垃圾信息？
属于哪个类别？
要不要继续？
需要不需要人工？
Mirado por sí solo, cada pregunta es muy simple.
Pero multiplicarlos por millones de llamadas, y el costo y la latencia se convierten en un verdadero problema de ingeniería.
Esto es lo que más vale la pena ver en modelos como Jev:
En lugar de tratar de ser un "cerebro " más grande, trata de ser una terminación nerviosa dentro de un sistema de IA.
Escrita al final
Durante los últimos dos años, la industria de la IA ha estado buscando modelos cada vez más grandes.
Mayor número de argumentos, contextos más largos, razonamiento más complejo, capacidad de código más fuerte.
Pero cuando la IA realmente entra en el sistema de software, podemos encontrar:
Muchas interacciones entre computadoras, en realidad, no requieren lenguaje natural.
El programa no necesita un modelo para escribir un documento.
Puede que sólo necesite:
true
o:
refund
o:
tool_7
O también:
confidence = 0.91
Esto es también lo más interesante en la dirección que representa Jev.
No está destinado a reemplazar a ChatGPT, ni a escribir artículos mejor que Claude.
Lo que intenta hacer es otra cosa:
Transformar la IA de "la persona responsable de hablar " a" el componente del programa responsable de tomar decisiones ".
Si esta línea de pensamiento continúa evolucionando, las futuras aplicaciones de IA pueden dejar de ser "un paquete de supermodelos para luchar por el mundo".
Y más probable es:
Uno es responsable del pensamiento, uno es responsable de la generación, uno es responsable del juicio, uno es responsable del enrutamiento, y uno es responsable de la auditoría.
Los grandes modelos son responsables de problemas complejos.
El modelo pequeño es responsable de las decisiones de alta frecuencia.
El código tradicional es responsable de las restricciones finales.
Los tres se combinan para constituir un sistema de software de IA que realmente puede funcionar a largo plazo.
Por lo tanto, si es necesario recordar a Jev en una sola frase:
ChatGPT es para dar respuestas a las personas, y Jeff es para elegir a los programas.
Y tal vez esa es la verdadera razón por la que ha atraído la atención de los desarrolladores de repente recientemente.