El otro día os presentaba el sistema de clasificación de vídeos con IA el cual, entre otras cosas, terminaba metiendo la información de los vídeos clasificados en una base de datos Mongodb en local.

Elegí MONGO por ligereza, velocidad y por el propio contexto de uso, desde luego no por la simpatía que le tengo a las queries de JSON que con un par de condiciones que se le pongan tiende a galimatias-insufrible
db.getCollection("identificados").find({ "filename": /_03/, "especies.Buho real": { $exists: true }, saturacion: { $lt: 15 } }, { _id: 0, ruta_completa: { $concat: ["$path", "/", "$filename"] } }).forEach(doc => print("'" + doc.ruta_completa + "'"))
Claro que en este contexto y habiendo llegado a dejar que la IA identifique la fauna y clasifique los vídeos ¿porqué no dejar que la misma IA siga trabajando y se encargue de hacer las búsquedas en MONGO y que sea ella la que se pelee con cadenas interminables de comas, comillas, puntos, llaves abiertas, paréntesis, barras de escape…

¿No sería ideal? Ya tenemos los vídeos clasificados en una base de datos MONGO, con sus rutas, las especies clasificadas y principales caracteristicas técnicas. Ahora solo necesitamos que una IA con acceso a dichos datos pueda atender instrucciones sencillas tipo «Pasame los 2 últimos vídeos que grabé de un Zorro durante el día» y acto seguido obtener una lista archivos.

local vs online, LMSTUDIO/OLLAMA vs GEMINIS

Claro, si se trata de acceder a nuestros datos locales, en nuestro ordenador, cabría pensar que ejecutar una IA local tendría algún tipo ventaja en el acceso a datos locales, archivos, vídeos, bases de datos… pero no, al menos por el momento (no creo que esto tarde mucho en llegar) ejecutar una IA en local tiene unos pocas ventajas, principalmente velocidad (que no potencia), versatilidad a la hora de hacer integraciones con otras aplicaciones y servicios, equipos OFFLINE, poco más.

LMStudioLMStudio

En las pruebas que he estado haciendo con modelos locales de LLM (Mistral, LLAMA, Gemma y Deepsek prinicipalmente) tanto con LMSTUDIO como con OLLAMA el problema era siempre el mismo: falta de consistencia. Le puedes preguntar 20 veces lo mismo y obtener 20 respuestas distintas cada vez.
Si nuestro proyecto trata de consultas más «orgánicas» como narración, resumenes de texto, conversación, etc… pues puede pasarse por alto o incluso ser deseable una ligera variación natural, pero si lo que le pedimos es una query informática para generar un comando que devuelva «los 2 últimos vídeos que grabé de un Zorro durante el día» pues hay poco margen a la creatividad. Y aquí los modelos locales fallaban mucho. Suelen «olvidar» parte de la instrucción, no entrecomillan bien.
Muy probablemente esta falta de consistencia en las respuestas esté directamente relacionada con el hecho de que los modelo LLM para ejecución local son modelos muy aligerados para su ejecución local lo que repercute en su falta de precisión.

Sea cual sea el motivo, tras algunas pruebas con modelos en local acabé (volviendo) a usar la APIKEY de Gemini que os mostraba en el post anterior. Claro, el retardo aumenta mucho, la conexión a internet es obligatoria y probablemente (no por ahora) las limitaciones de la API de Géminis acabe asomando la patita. Pero por ahora el resultado es fenomenal

Convertir lenguaje humano a query mongodb

Como decía, si las IAs no pueden acceder a los datos y a la estructura de los datos ¿como van a construir consultas para la base de datos?
Fácil: todas las consultas que se les envian a la IA debe ir siempre acompañadas de un manual de instrucciones y órdenes de lo que queremos que haga y además esta parte es crítica para el éxito de la conversion del lenguaje humano a consulta de base de datos. Deben ser instrucciones claras, sencillas, sin vagedades, sin contradicciones o generalizaciones, enfatizadas y bien estructuradas y con ejemplos.
En mi código lo he llamado «estructura» y tiene este contenido:


Nota curiosa: en la descripción de la estructura de los datos no incluyo la fila _id (que existe porque Mongodb la incluye por defecto) pero luego en las instrucciones si que le indico que no la use, ya que aunque no se lo digamos la IA ya sabe la estructura habitual de MongoDB.
Observa también que hay que insistirle mucho para que se calle, como si fuera un crio deseando dar su opinión: callate, no hables, responde y ya! :D

Si lo hacemos bien, al escribir «dame el último vídeo grabado de una Gineta» nos devolvería:
db.getCollection("identificados").find({ "especies.Gineta": { $exists: true } }, { _id: 0, ruta_completa: { $concat: ["$path", "/", "$filename"] } }).sort({ fecha: -1 }).limit(1).forEach(doc => print("'" + doc.ruta_completa + "'"))
Que lo podemos mandar a Mongosh asi
mongosh Trailcam --eval {repuesta_gemini}
obtendriamos ‘/home/mis-videos/Gineta/mi-video.mp4‘

En general el sistema es bastante flexible y admite un lenguaje humano bastante natural. Si es cierto que hay alguna limitación imporante relacionada con los nombres de los animales: Se deben entrecomillar (uso comillas españolas) si el nombre incluye espacios ya que si escribimos Buho real sin entrecomillar es muy probable que la IA use en la búsquedas Buho, especie que no existe, solo Buho real. Algo parecido pasa con los plurales, se escribe «3 vídeos de Jabali» no «3 vídeos de Jabalies«, este ultimo no existe.
Ya lo de que le pida un vídeo de un gato y me saque un Jabali adentrandose en la oscuridad es solo achacable a la clasificación inicial que en su día se confundió de culo en la espesura nocturna, para la proxima tarea.