Retomo el asunto de los paralelismos entre textos, que ya traté aquí, por el siguiente motivo:
Estoy explorando las posibilides del RAG Para lo cual es necesario crear una base de datos documental con los fragmentos debidamente embebidos En particular, estoy probando lo que chroma da de sí. Esencialmente, chroma consiste en:
Una base de datos (SQLite, de hecho) donde se almacenan los fragmentos, sus metadatos y sus embeddings. Mecanismos para crear los embeddings.
Tenía ganas de meterle mano al modelo 3PL de la teoría de respuesta al ítem. Había un par de motivos para no hacerlo: que viene del mundo de la sicometría, que es un rollo macabeo, y que sirve —en primera aproximación— para evaluar evaluaciones (preguntas de examen, vamos), un asunto muy alejado de mis intereses. Pero acabaron pesando más:
Que se trata de un modelo generativo en el que los coeficientes tienen una función —y por tanto, interpretación— determinada y prefijada.
Hace un tiempo tuve que leerlo todo sobre cierto tema. Entre otras cosas, cinco libros bastante parecidos entre sí. Era una continua sensación de déjà vu: el capitulo 5 de uno de ellos era casi como el tres de otro, etc. Pensé que podría ser útil —y hacerme perder menos tiempo— poder observar el solapamiento en bloques —sígase leyendo para entender mejor el significado de lo que pretendía—.
En esta entrada voy a mostrar el resultado de mis ensayos sobre unos textos distintos.
I. El problema original Tienes dos cuentas en Twitter, llámense @trabajo y @personal. Tienes una única cuenta de desarrollador en Twitter. Supongamos que está vinculada al usuario @trabajo. Quieres usarla para tuitear también en nombre de @personal. Lo suyo sería disponer de dos cuentas de desarollador, una para cada usuario. Sin embargo, Twitter parece estar dando acceso a tu plataforma de desarrollador con cuentagotas y ni siquiera está claro si conceden más de una cuenta a una misma persona que maneje varios usuarios.
Este soy yo hoy mismo:
Este es mi script:
carlos@tiramisu:~$ wordle señor Intento 1 -> seria Quedan 2 opciones. Las más populares son: señor : 228.79 segur : 0.23 Intento 2 -> señor Solución en 2 intentos: señor Mi pequeño script tiende a ganarme. Lo cual me satisface enormemente.
En caso de que a alguien le interese, puede bajárselo de aquí. Existen dos versiones que implementan el mismo algoritmo, una en R y otra en Python.
SE significa arriba_squared errors_, pero lo que aplica a cualquier otro tipo de error, incluso los que son más apropiados que los cuadráticos. El problema de los SE es que se tienden a considerar iguales y por eso se los promedia en engendros como el RMSE y similares. Pero incluso entre los SE hay jerarquías, como evidencia la siguiente historia.
Con lo del covid se pusieron en marcha muchas iniciativas. Una de ellas fue la del COVID-19 Forecast Hub.
Hoy me voy a limitar a publicar una imagen de mi flamante home server corriendo la versión 0.1 de mi panel para el seguimiento del mi consumo eléctrico en tiempo real:
Sin duda, iré desgranando los detalles técnicos del sistemita en próximas entradas.
Una de mis aficiones más excusables es la de participar en el mercado de predicciones de Hypermind. Una de las preguntas que se suele plantear anualmente —y en la que, gracias a apostar contra el común/apocalíptico sentir, logré pingües beneficios el año pasado— tiene que ver con cuándo nos vamos a morir todos. De otra manera:
Este año también quiero participar, pero como no sabía por dónde empezar, he bajado los datos.
El otro día hubo, parece, cierto interés por modelar la siguiente serie histórica de datos:
Notas al respecto:
El eje horizontal representa años, pero da igual cuáles. El eje vertical son números naturales, conteos de cosas, cuya naturaleza es poco relevante aquí, más allá de que se trata de eventos independientes. Se especulaba con un posible cambio de tendencia debido a una intervención ocurrida en alguno de los años centrales de la serie.
[Antes de nada, un aviso: léase la fecha de publicación de esta entrada. Es fácil estés visitándola en algún momento futuro en el que ya esté más que caduca.]
Soy muy partidario de las ETL en memoria. Cada vez es menos necesario utilizar herramientas específicas (SQL, servidores especializados, Spark, etc.) para preprocesar datos. Casi todo cabe ya en memoria y existen herramientas (hoy me concentraré en R y Python, que son las que conozco) que permiten realizar manipulaciones que hace 20 años habrían resultado impensables.
Larguísimo, arriba, significa algo así como 10 o 20 años. Vamos, como cuando comencé con R allá por el 2001. R es, reconozcámoslo, un carajal. Pocas cosas mejores que esta para convencerse. No dejo de pensar en aquello que me dijo un profesor en 2001: que R no podría desplazar a SAS porque no tenía soporte modelos mixtos. Yo no sabía qué eran los modelos mixtos en esa época pero, desde entonces, vine a entender y considerar que “tener soporte para modelos mixtos” venía a ser como aquello que convertía a un lenguaje para el análisis de datos en una alternativa viable y seria a lo existente.
Hoy me he retrasado en escribir por haber estado probando (y estresando, como hay quien dice), software para resolver problemas de programación lineal. En total, nada, unos diez millones de variables unos treinta millones de restricciones.
Nota: es un problema LP puro, nada de enteros, nada de pérdidas no lineales, etc.
Primera opción: Python + PuLP + CBC (de COIN-OR), que es el optimizador por defecto de PuLP. Rendimiento aceptable para el tipo de uso que se le acabaría dando.
Así vendría a traducirse el título de este artículo, que trata de taxonomizar y sistematizar una serie de técnicas muy recientes para explicar modelos de caja negra.
Tal vez no acabe siendo la manera pero, sin duda, acabará habiendo una.
