JEV - Hay preguntas que no le corresponden
Después de usarlo, las preguntas que no le corresponden son las explicaciones, las respuestas para que las lea una persona, inventar un nombre en un conjunto abierto, y guardar una traza de razonamiento. Lo que sí le corresponde sigue siendo un sí o no cerrado, una categoría, un nivel, y si hay que escalar.
Coautor: folkbench.com (Folkbench es una plataforma revisable de evaluación y selección de API de IA, servicios de modelos y sitios relacionados. Se apoya en información de servicio publicada, precios, disponibilidad, latencia y ventanas de evidencia para ayudar a los usuarios a comparar y a elegir un camino.)
Diez textos en esta serie:
- JEV - Una articulación no necesita cerebro
- JEV - Por qué un Jev que no puede chatear encaja en un Agent
- JEV - Hasta dónde llega de verdad «no puede alucinar»
- JEV - ¿Bastan el sí o no, la opción y el nivel como lenguaje?
- JEV - Un laboratorio podría hacerlo. Por qué quizá no.
- JEV - Los dos demos que ejecuté
- JEV - Las personas pasan del centro del bucle al borde
- JEV - Pasada esa línea, ya no distingo quién es más listo
- JEV - Hay preguntas que no le corresponden
- JEV - Un modelo reducido, una suite y uno que no habla
Después de usarlo, de lo que estoy más claro no es de lo que Jev puede hacer. Es de qué clases de habla no debería preguntarle.
Lo tomo como una articulación, no como una boca. El instinto solo puede responder preguntas que el instinto puede responder. Lo que hay que desplegar, o lo que hay que poner el razonamiento a la vista de una persona, es el objeto equivocado si usted le pregunta a Jev. Decirle algo hasta el final a una persona también es la pregunta equivocada. No tiene cadenas. Pregunte, y no hay dónde poner la respuesta.
Lo que no debería preguntar
Si usted también viene de un modelo de chat, lo más fácil de preguntar mal son las clases de abajo.
No debería pedirle que explique por qué. El hábito que traje del chat es abrir pidiéndole que explique. Ese hábito no funciona en él. Cuando le pido que explique, lo que llega es solo un juicio. Una razón tiene que escribirse en frases. No puede escribirlas. El retorno no tiene «porque». Si alguien necesita ver cómo llegó la causa, no puede darlo. Si de verdad necesito un tramo de razones, lo escribo yo, o pido a un modelo que pueda hablar, y le hago escribir a partir del juicio ya hecho.
Le he pedido, mal, que escriba una respuesta para que la lea una persona. Lo que hay que enviar es un pasaje. Qué frase va primero, y qué pesado es el tono, vive en las palabras. Lo que él da son opciones y probabilidades. Eso no casa con el pasaje que hay que enviar. Por alta que sea la probabilidad, lo que vuelve es uno de los elementos que yo di de antemano, no un pasaje que escriba ahora. Luego invertí el orden. Él solo juzga de qué clase es esta cosa, y si este paso debería escalar. Las frases van a un modelo de chat, o las escribo yo.
Le he pedido que se invente un nombre por su cuenta dentro de un conjunto abierto. Los nombres usables son muchos, y solo un corte pequeño se escribe en la pregunta. Solo puede elegir entre los elementos que yo di. Lo que no está entre los elementos, no puede producirlo. Si yo no puedo nombrar los candidatos, aún no le toca. Primero estrecho con reglas, o saco un puñado pequeño con recuperación, y luego cierro la pregunta. Luego cambié el nombrar a esto: yo fijo unos pocos candidatos, y luego dejo que elija. Uno del todo nuevo fuera de la lista, lo dejo al paso que puede hablar.
Hay otra clase que parece trabajo pesado que debería darse a un modelo. La prueba hay que volverla del derecho y del revés, y el razonamiento hay que guardarlo. Los materiales se empujan entre sí. Usted quiere que elija un lado, y también quiere que guarde cómo se hizo el encaje. Él no tiene ese ir y venir. Una petición es un juicio rápido a partir de lo que yo metí en el state. El proceso no se vuelve texto que se pueda repasar. El ir y venir del que hablo a menudo es una conclusión que depende de la página siguiente, y esa página aún no está en el state. Pongo esa dependencia en el código. Pregunto primero un juicio cerrado, luego voy a buscar la prueba, y cuando vuelve cambio el state y pregunto otra vez. La secuencia de qué página se miró primero, y qué se descartó, no puede escribirla. Si hay que guardar una traza, se la doy a un modelo que pueda hablar.
Lo que debería preguntar
Lo que debería preguntar, ahora solo reconozco unas pocas formas. Si es de esta clase, lo pregunto directo. Las categorías tienen que ser las que yo fijé de antemano, y él solo tiene que señalar una. La gravedad, no le dejo declarar un número fino. Yo dibujo los niveles, y le dejo decir en qué nivel cae. La escalada, si este paso debería entregarse a una persona, también es una pregunta cerrada, y la pregunto en la misma pasada. Una forma fuera de estas, no se la meto.
También guardo una regla gruesa. Si una persona que entiende el asunto puede señalar, por instinto, mientras mira este state, entonces se parece a su pregunta. Si señalar aún pide una deducción larga, lo entrego directo a un modelo que pueda hablar.
Yo preparo el state. Yo cierro la pregunta. Yo elijo los campos que entran en el contexto, y no traigo lo que es irrelevante para esta pregunta. Los límites de las opciones y de los niveles se escriben en la pregunta, no en un sitio donde yo espere que improvise. No es responsable de redondear una pregunta abierta, y no pasa por mí la página siguiente del material. Pase una página, y el state ha cambiado. Esa es la petición siguiente, y aún tengo que prepararla.
He pisado una pregunta que no estaba bien cerrada. La distribución se aplana. Varias opciones se aprietan juntas, y ninguna sobresale una cabeza. Al principio lo tomé como que iba lento. No era eso. Yo le había dado a una articulación el pistón de una boca. Las opciones se solapan, o una situación que de verdad ocurrirá no se escribió en la lista, y la probabilidad solo puede repartirse. Entonces cambie la pregunta, o devuelva el paso a un modelo que pueda hablar. Cambiar la pregunta quiere decir fundir los elementos que se solapan, y dar al caso no cubierto un «ninguno de estos». Devolverlo quiere decir dejar que el modelo que puede hablar diga primero la situación con claridad, y luego yo decido si la cierro otra vez. No siga ajustándolo. Mientras la pregunta siga abierta, la distribución sigue repartida.
Choice y Score
Procuro no llenar Choice hasta 255. El tope oficial es 255. Más allá, ellos mismos tienen que puntuar primero y luego elegir, y además se vuelve más lento. 255 no es un número que yo esté aquí para llenar. Cuantos más casos límite enumero como opciones, más se parece la pregunta a una lista que nunca se cerró. Si mi pregunta tiene de natural cientos de salidas, primero pregunto si las reglas pueden cortar los candidatos, y si la recuperación puede cortarlos. Un puñado pequeño no tiene un recuento fijo. Aún puedo distinguir, de un vistazo, en qué se diferencian estos elementos, y solo entonces el corte ha ido bastante lejos. Si un vistazo no puede distinguirlos, estoy enviando la petición demasiado pronto. Córtelo hasta un puñado pequeño, y entonces lo llevo a elegir.
Trato Score como niveles ordenados, no como un decimal exacto continuo. Cuando escribo la pregunta, suelo dibujar los niveles de 2 a 10. Lo que quiero es un nivel, no una precisión falsa como 7.63. Escribo los niveles en palabras llanas. Si este nivel y el siguiente se tratarían de otro modo, lo pienso primero. Si se tratarían así, los parto. Si los dos niveles acaban disparando el mismo código, los fundo en un nivel. Ninguna rama del código está esperando dos dígitos después del decimal. A veces deja caer un número entre dos niveles, y yo aun así lo leo como un nivel, con el umbral escrito en el código. Si el sentido de un nivel no se puede escribir con claridad, cambio la descripción del nivel. No escarbo en el decimal.
Mientras miraba los demos
Miré el demo oficial de Doom y la carrera de Wikipedia, y no los usé para concluir mis propias preguntas. Mirando Doom, me dejo llevar con facilidad por la pantalla. La pantalla parece un juego que se está jugando. Lo que entra es state estructurado, no la imagen. Del lado de Doom la escala es de unas 10 consultas por segundo, unos $7 la hora. Esa escala solo muestra que una articulación en tiempo real se sostiene, y que un bucle puede girar a esa densidad. No muestra que pueda jugar al juego. La imagen no se comió. El paso siguiente es código de fuera, preguntando con el state.
La carrera de Wikipedia muestra que elegir enlaces con cardinalidad alta es útil. No muestra que navegue la web mejor que un modelo que puede razonar. Bajo la comparación sin razonamiento, da menos pasos. Eso es porque el otro lado no encendió el razonamiento, así que la demostración se ve mejor. Encienda el razonamiento, y la demostración se ve menos bien. El recuento de pasos cambia, y quién es más rápido cambia. No me llevaré «menos pasos» de vuelta a mi propia tarea y lo trataré como mejor para encontrar un camino. Si el camino sigue, y dónde se para, lo sigue decidiendo el programa de fuera. Esto lo tomo como: no juzgue todo a partir de un juguete. Si una demostración es agradable de mirar no decide, para mí, qué frase debería preguntar después.
Cuando lo uso yo, el corte es bastante duro. Lo que se puede agotar, y cuyas condiciones son estables, lo sigo escribiendo como reglas. No voy a preguntárselo. Lo que el instinto puede responder de un punto, ahí es cuando se lo pregunto. Antes de preguntar, la pregunta tiene que estar cerrada, y yo tengo que poder preparar el state. Cuando toca abrir y decir el contenido, se lo doy a un modelo de chat. Pregunte lo equivocado, y la lentitud y el coste son problema mío.
Fuentes
- https://typesafe.ai/blog/introducing-system-one-models-and-jev
- https://evals.typesafe.ai/
- https://docs.typesafe.ai/primitives