Fine-tuning o RAG: cómo elegir sin quemar presupuesto
No compiten por el mismo trabajo. Uno cambia lo que el modelo sabe; el otro, cómo se comporta. Confundirlos sale caro.
Pensamientos, tutoriales y experiencias sobre desarrollo web, arquitectura e ingeniería.
No compiten por el mismo trabajo. Uno cambia lo que el modelo sabe; el otro, cómo se comporta. Confundirlos sale caro.
No es un bug que se parchea con más instrucciones. Es la consecuencia de mezclar datos e instrucciones en el mismo canal.
Una ventana de contexto grande no es memoria. Distinguirlas es la diferencia entre un agente y un chat con amnesia.
El vector te trae diez candidatos, pero el orden en que llegan casi nunca es el bueno. Notas de campo sobre añadir un reranker sin arruinar la latencia.
Casi todos los fallos de recuperación no son culpa del embedding, sino de cómo troceaste el texto. Notas de campo para partir documentos sin romper el sentido.
Sacar datos de un LLM con expresiones regulares es una bomba de relojería. Notas de campo para obtener JSON que valida a la primera y no te revienta en producción.
Un panel que nadie abre no es neutro: cuesta tiempo, atención y credibilidad. Notas de campo para construir dashboards que cambian una decisión.
El mismo contexto, viajando una y otra vez. Ahí está tu factura, y ahí está la palanca.
La retro no es un ritual de quejas ni una terapia de grupo: es la única reunión que existe para cambiar algo.
El modelo tarda lo mismo, pero la espera se siente la mitad. Ese es todo el truco.
No compiten por el mismo puesto: uno lee registros en la planta, el otro los lleva a la nube.
No necesitas una plataforma de despliegue para un proyecto de una persona. Necesitas veinte líneas que corran los tests y suban el build sin que tú mires.
La respuesta honesta casi nunca es 'ya'. Aquí está la línea que sí la cruza.
No son decoración ni burocracia: son el contrato que convierte errores de producción en errores de tu editor.
Partir el monolito no es gratis: pagas en latencia, deuda operativa y reuniones. Cuándo merece la pena y cuándo te estás complicando la vida.
Boris Cherny dice que ya no hace prompts, sino bucles que los hacen por él. Qué significa eso en la práctica y por qué diseñar el bucle es más difícil, no más fácil.
Cinco principios pensados como heurísticas, no como mandamientos. Aplicarlos a ciegas también es deuda técnica.
Tu modelo funciona en el notebook. El problema empieza cuando lo llaman mil personas a la vez.
Sin un conjunto de evaluación, cada cambio de prompt es una apuesta a ciegas.
Un prompt que funciona en tu pantalla no es un sistema. Es un accidente que aún no se ha roto.
Lo que me llevé del harness de Anthropic y cómo lo aterricé en mi propio pipeline.
Si entiendes esto, entiendes por qué tu buscador semántico acierta o falla.
El problema casi nunca es el modelo. Es lo que le das de comer.
Por qué si no duele, probablemente no lo estés haciendo bien
En este post hago una exploración sobre la comunicación industrial, específicamente sobre Modbus.
Este post describe las librerías más utilizadas para la visualización de datos en tiempo real
Este post introduce al desarrollo con Stimulus.js
Este post introduce al desarrollo con Python
En este post voy a explicar la arquitectura de software y los principios SOLID.