Qué llega completo y qué llega solo como nombre

La recuperación tiene dos tareas. Elegir el conocimiento correcto es la más conocida. Decidir cuánto espacio merece cada entrada elegida es la que determina si la buena respuesta realmente cabe.

Un diseño más simple resuelve la segunda cuestión con una sola regla: todo lo que entra en la priorización se envía con su contenido completo, en orden de prioridad, hasta que se acaba el espacio. La entrada en octavo lugar recibe exactamente el mismo trato que la primera, y la siguiente no recibe nada, aunque sea relevante. La relevancia decide el orden y nada más.

En Pathrule, la relevancia decide la forma.

Tres formas, una sola priorización

• Las pocas más cercanas llegan con su contenido completo. El asistente las lee y actúa, sin una consulta aparte y sin ida y vuelta.
• Todo lo demás que es relevante llega como un nombre, un id y una línea. Es suficiente para que el asistente lo reconozca y solicite el cuerpo cuando resulte importante.
• Las skills llegan solo por nombre, sin importar qué tan alta sea su prioridad. Más detalles abajo.

La propiedad importante es la del final de la lista: una entrada relevante no se descarta por falta de espacio. Lo que no cabe en el presupuesto por prompt se lista por título, y es la forma económica la que hace que eso sea viable.

La cantidad de cuerpos que llegan completos se elige para mantener íntegras las coincidencias más fuertes y, al mismo tiempo, costar menos que enviar completas todas las entradas priorizadas. El presupuesto exacto forma parte del motor de Pathrule y puede cambiar entre versiones.

Por qué una skill nunca se envía sin pedirse

Una memoria es un hecho. Una regla es una restricción. Ambas son cosas que un asistente simplemente debería saber mientras trabaja, así que ambas pueden llegar como contenido.

Una skill es un procedimiento. Meter un procedimiento en el contexto de un turno que no lo pidió no informa al asistente, le da instrucciones, y un asistente al que le entregan una lista de pasos tiende a seguirla. Por eso las skills se ofrecen por nombre, y el asistente recurre a una cuando el trabajo es justamente el que esa skill describe. Al invocarla, por ejemplo con ::skill-name, se trae su cuerpo completo. Consulta cómo escribir skills para saber qué se espera de una skill.

Las reglas también se ganan su espacio

Si las reglas se saltaran la prueba de relevancia, una restricción sobre migraciones de base de datos podría desplazar a la memoria que habría respondido una pregunta sobre un botón. Por eso las reglas pasan por la misma prueba de relevancia que todo lo demás, y una regla no relacionada llega como nombre en lugar de ocupar un espacio completo.

La excepción es deliberada: una regla marcada como estricta conserva su cuerpo, porque una restricción firme cuyo incumplimiento provoca una regresión no es algo que convenga racionar. Consulta Las reglas como barreras de protección.

La degradación es lo que hace observable la relevancia

Hay una segunda razón por la que importa la forma económica, y tiene que ver con aprender más que con el costo.

Cuando cada entrada priorizada se envía como cuerpo, la capa nunca se entera de si alguna era necesaria. Un cuerpo que llega sin pedirse no aporta evidencia en ningún sentido. Un nombre ofrecido es distinto: el asistente lo solicita o no, y una solicitud es un acto deliberado de la parte que sabe qué necesitaba el trabajo.

Esa solicitud es una señal de relevancia útil, y una entrada que se solicita una y otra vez tiene más probabilidades de llegar completa la próxima vez. Encaja en el ciclo más amplio descrito en cómo la recuperación encuentra el conocimiento correcto: la capa mide lo que entregó en lugar de pedirle al asistente que lo informe.

El umbral tiene que funcionar en todos los idiomas

Que una entrada se envíe o no depende de un umbral de relevancia, y ese umbral puede depender del idioma sin que se note. La misma memoria puede obtener cierta puntuación frente a un prompt escrito en inglés y una más baja frente a una traducción fiel de ese prompt, porque la comparación basada en significado no produce resultados idénticos entre idiomas para la misma idea. Un umbral ajustado solo con prompts en inglés dejaría fuera a los demás idiomas sin que nadie lo notara, y el síntoma no sería un error. Sería un equipo que escribe sus prompts en turco recibiendo menos contexto que un equipo que escribe los mismos prompts en inglés.

Por eso el umbral se fija en un punto que funciona en todos los idiomas, y Pathrule lo comprueba con prompts en varios idiomas en lugar de darlo por hecho. Cómo demuestra Pathrule sus afirmaciones más exigentes describe cómo se verifican afirmaciones como esta.

Un prompt que pregunta dos cosas recibe conocimiento para ambas

Si haces una sola pregunta, la comparación basada en significado funciona bien. Si haces dos en el mismo mensaje, tiene un problema estructural: la solicitud se convierte en un único promedio de dos ideas distintas, y el promedio de dos cosas a menudo no se parece a ninguna. La entrada que responde tu primera pregunta y la que responde la segunda pueden quedar ambas por debajo de un umbral que cualquiera de ellas habría superado por sí sola.

Pathrule lee una solicitud de varias partes como sus partes. Cada parte se compara por separado y los resultados se combinan, así que una pregunta de dos partes recibe conocimiento para ambas, mientras que una pregunta de una sola parte se compara igual que antes.

El espacio disponible crece con la pregunta y no con el espacio de trabajo. Preguntar dos cosas cuesta un poco más que preguntar una. Tener diez mil memorias en lugar de cien cuesta lo mismo.

Qué leer a continuación

• Cómo la recuperación encuentra el conocimiento correcto, sobre la selección en la que se apoya este modelo de entrega.
• Cómo funcionan los hooks, sobre cómo la porción seleccionada llega al asistente antes de su primera llamada a una herramienta.
• Cómo demuestra Pathrule sus afirmaciones más exigentes, sobre cómo se prueban afirmaciones como el comportamiento entre idiomas.