¿Se puede resumir como que “predicción del siguiente token” es precisa como explicación a nivel de implementación, pero incompleta como forma de explicar las capacidades o el propósito del modelo?

 

Entonces, parece que podríamos encontrar un punto medio con un modelo que prediga mejor 😄

 

Mmm... quizá ahora pienso que el texto se transmitió de una forma distinta a la que yo pretendía. Si este texto dio la impresión de que estaba menospreciando el valor técnico de los LLM, les ofrezco una disculpa.

Dicho eso, la intención de este texto era quitar el empaque exagerado y la mistificación para verlo con frialdad. Por eso, en lo personal, siento que expresarlo como un "modelo que alcanza objetivos" le da un tono de mistificación. Al final, tanto el software convencional como un modelo existen también para alcanzar algún "objetivo".

Por eso, sumando mi curiosidad personal, me gustaría volver a preguntar si la expresión que mencionó es técnicamente más precisa.

 

Parece un anuncio de Analytics de principio a fin. Suena convincente, pero al final sigue siendo publicidad, y también da la impresión de que el administrador de hada.io lo está dejando demasiado abandonado.

 

Al final, es un trade-off con la calidad, y también me preocupa si no terminará siendo una estructura en la que se usen más tokens para recuperar la calidad perdida.

 

Como bm25 es débil para las búsquedas en coreano, también apliqué por separado una capa de protección que puede buscar bien en coreano.

 

En un contexto amplio, se trata de buscar conversaciones pasadas, así que me parece una buena idea si se organiza bien el tema de la clasificación. De hecho, creo que a mí también me ayudó mucho para organizar proyectos.

 

Yo también lo implementé. Le agregué un poco para poder vincular el vault de Obsidian con respaldo en GitHub cuando se usan varios dispositivos. También hice y añadí parsers para Codex y Gemini. https://github.com/hang-in/seCall

 

Si vas a reducir a los LLM modernos a "predicción de la siguiente palabra", entonces AlphaGo también sería nada más que "predicción de la siguiente jugada".

Desde ChatGPT, predecir la siguiente palabra no pasa de ser solo preentrenamiento.

En cambio, Claude es un modelo que logra objetivos.

 

Por lo que escuché, los desarrolladores del kernel les han estado diciendo a los desarrolladores de PostgreSQL desde hace casi 10-20 años: "los spinlocks en espacio de usuario no son recomendables, así que nos gustaría que lo reconsideraran"...

https://x.com/kosaki55tea/status/2040458791536497035

 

Si ya usabas el equipo de agentes de Claude Code, no había nada especialmente novedoso.
Pero fue conveniente construir la infraestructura usando agentes o skills para poder continuar incluso en sesiones nuevas con información como la configuración del equipo.
Cuando armabas el equipo manualmente, se repetían cosas tipo boilerplate para el equipo.

Había un problema: como es un entorno que considera tanto subagentes como equipos de agentes, en el patrón Supervisor a menudo ocurre la situación extraña de que el supervisor delega trabajo a un subagente aunque el equipo ya esté creado.

 

https://github.com/google-ai-edge/gallery/issues/437

Parece que la compatibilidad con Exynos no es muy buena. En el Galaxy Quantum 5 (A55) hay un problema en el que responde repitiendo caracteres chinos infinitamente.

 

Pensaba que, salvo algunos modelos que usan modelos de difusión, todos los modelos de lenguaje grandes disponibles en el mercado después de GPT funcionaban prediciendo el siguiente token. Si hay modelos que funcionen de otra manera, agradecería que me lo hicieran saber.

 

Ni siquiera sabía que existía internet simétrico de 25 gigas. Pensaba que incluso algo del nivel de 10 gigas ya era más que suficiente para un hogar...

 

Lo probé antes, pero como Claude seguía gastando más tokens para resolver problemas causados por rtk, terminé quitándolo.
(Por ejemplo, si haces una solicitud JSON con curl, genera JSON inválido, jq lanza un error, Claude se pone a depurarlo y se consume los tokens, y al final vuelve a tomar la solicitud cruda de curl para parsearla con jq.)
Aun así, creo que la intención en sí es un buen intento, así que cuando esté más estable, parece que valdrá la pena probarlo.

 

A mí también me había parecido una lástima esa parte.

Pero en una actualización reciente hicieron que el full output se guarde en un archivo aparte para que el LLM pueda leerlo si lo necesita~

 

La renovación del sitio oficial se hizo antes del lanzamiento de GnuBoard 7.

 

Por eso a veces rehacerlo desde cero termina siendo más rápido.

 

No sé si de verdad lo reduzca. Le dije al agent varias veces que usara el comando rtk ls.., pero no lo usa.