1. Modelo mental
Investigar con IA tiene dos capas distintas:descubrimientoyevidencia. La IA puede ayudarte a formular preguntas, localizar líneas de investigación y resumir documentos, pero la afirmación final debe poder volver a una fuente que tú puedas abrir y evaluar.
Una cita no garantiza que la afirmación sea correcta. Hay que comprobar que la fuente existe, que dice lo que se afirma, que la fecha sirve para la pregunta y que no estamos citando una copia secundaria cuando existe una fuente primaria.
La mejor salida de una investigación no es un párrafo elegante; es un mapa de afirmaciones con su evidencia, incertidumbre y decisiones pendientes.
2. Conceptos que debes dominar
Una pregunta suficientemente concreta para decidir qué evidencia sería relevante.
Documento original: paper, regulación, documentación oficial, informe de resultados, dataset o anuncio del proveedor.
Análisis que interpreta o resume fuentes originales. Puede ser útil, pero no debe ocultar el origen.
Afirmación concreta que puede ser verdadera, falsa o incierta y que debe vincularse a evidencia.
Registro de dónde sale un dato, cuándo se consultó y cómo se transformó.
Relación entre la antigüedad de una fuente y la velocidad a la que cambia el tema.
Contrastar una afirmación con varias fuentes independientes cuando el impacto lo justifica.
Enlace o referencia que permite comprobar exactamente la afirmación, no sólo visitar una página relacionada.
3. Workflow paso a paso
Formula la pregunta
Define qué decisión depende de la investigación.
Sabes qué evidencia podría cambiar tu conclusión.
Prioriza fuentes
Empieza por documentación oficial, papers, organismos y datasets originales.
No confundes popularidad con autoridad.
Captura claims
Separa cada afirmación importante y anota la fuente.
Una frase no mezcla cinco afirmaciones imposibles de auditar.
Lee alrededor
Comprueba contexto, metodología, fecha, población y limitaciones.
La cita no se ha sacado de una frase aislada.
Contrasta
Busca desacuerdos y explica por qué pueden existir.
No ocultas evidencia que contradice tu hipótesis.
Sintetiza
Agrupa hallazgos por pregunta, no por fuente.
La síntesis distingue consenso, incertidumbre y vacío.
Marca caducidad
Asigna revisión más frecuente a precios, modelos, límites y normativa cambiante.
Sabes cuándo volver a comprobar un dato.
Entrega evidencia
Incluye conclusión, claims, fuentes y preguntas abiertas.
Otra persona puede auditar tu razonamiento.
4. Ejemplo completo
Pregunta:“¿Qué modelo deberíamos usar para resumir documentos largos con citas?”
- Claim AEl modelo admite X contexto. Fuente: documentación oficial del proveedor, fecha.
- Claim BEl coste por millón de tokens es Y. Fuente de pricing, fecha.
- Claim CEn nuestros 30 documentos, la cobertura de citas fue Z. Fuente: eval interno.
- ConclusiónLa decisión combina capacidades oficiales y rendimiento en casos propios.
La investigación mejora cuando separas datos del proveedor, observaciones propias y opiniones externas. Cada capa responde a una pregunta diferente.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Fuente oficial | Capacidades, precios, disponibilidad | Página/documentación fechada | Marketing ambiguo sin detalle |
| Paper | Método o resultado científico | Metodología y limitaciones claras | Preprint sin contexto tratado como consenso |
| Benchmark | Comparar una capacidad | Dataset y protocolo visibles | Ranking único extrapolado a todo |
| Comunidad | Detectar problemas reales | Patrones repetidos y reproducibles | Anécdota convertida en hecho |
| Eval propio | Decidir para tu caso | Casos representativos y rúbrica | Muestra cómoda que favorece una opción |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Aceptar citas generadas que no has abierto.
- Usar snippets de buscador como evidencia final.
- Citar una fuente antigua para un dato que cambia semanalmente.
- Mezclar un anuncio de producto con un benchmark independiente.
- Ignorar metodología, tamaño de muestra o población.
- Elegir sólo fuentes que confirman la hipótesis inicial.
- Usar un ranking general para una decisión específica.
- No guardar la fecha exacta de consulta.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Cobertura de claims | Claims con fuente | Claims citados/total | <100% en claims críticos |
| Primariedad | Uso de fuentes originales | Tier de fuente | Demasiadas copias secundarias |
| Frescura | Edad apropiada | Días desde revisión | TTL superado |
| Conflictos | Desacuerdos visibles | Claims con valores distintos | Conflicto sin resolver |
| Reproducibilidad | Otro puede comprobar | Enlaces + método | Resultado no auditable |
| Tiempo por decisión | Eficiencia | Minutos a conclusión | Más lectura sin mejor evidencia |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Toma una respuesta con cinco cifras y encuentra la fuente primaria de cada una.
- Compara una afirmación en documentación oficial y en una noticia secundaria.
- Crea una ficha de evidencia con claim, valor, fuente, fecha y TTL.
- Busca deliberadamente una fuente que contradiga tu conclusión.
- Repite una investigación después de una semana y detecta qué cambió.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:Capacidades, precios, disponibilidad.Señal favorable:Página/documentación fechada.Alerta:Marketing ambiguo sin detalle.
Pregunta:Método o resultado científico.Señal favorable:Metodología y limitaciones claras.Alerta:Preprint sin contexto tratado como consenso.
Pregunta:Comparar una capacidad.Señal favorable:Dataset y protocolo visibles.Alerta:Ranking único extrapolado a todo.
Pregunta:Detectar problemas reales.Señal favorable:Patrones repetidos y reproducibles.Alerta:Anécdota convertida en hecho.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
Investigar no es pedir una respuesta: es construir una cadena de evidencia
La investigación asistida por IA debe separar descubrimiento, lectura y síntesis. En descubrimiento buscas candidatos; en lectura extraes afirmaciones y contexto; en síntesis decides qué puede sostenerse. Si mezclas las tres fases, una respuesta fluida puede ocultar que una fuente nunca fue abierta o que una afirmación procede de un resumen secundario.
Prioriza fuentes primarias cuando la pregunta depende de especificaciones, precios, políticas, lanzamientos o resultados de investigación. Una noticia puede ayudarte a descubrir un cambio, pero la documentación oficial, el paper, el registro o el dataset original deberían sostener el claim siempre que existan. Para temas disputados o comparativos, conserva fuentes independientes y explica dónde divergen.
Una cita no convierte automáticamente una afirmación en cierta. Debes comprobar que la fuente realmente sostiene la frase, que el dato pertenece a la fecha correcta y que no has extrapolado una limitación de un plan a todo el producto. La unidad de verificación es claim → fragmento/fuente → fecha, no artículo → lista de enlaces al final.
En temas que cambian rápido, guarda también la frescura. Un precio revisado hace seis meses puede ser una fuente auténtica y aun así estar obsoleto. Por eso Lumaria separa confianza de procedencia y de vigencia: una fuente primaria antigua puede requerir revisión antes que una fuente primaria revisada hoy.
La síntesis final debe permitir al lector distinguir hechos, inferencias y recomendaciones. Los hechos se respaldan; las inferencias explican cómo conectas esos hechos; las recomendaciones incorporan además objetivos y preferencias. Mezclar los tres niveles produce textos convincentes pero difíciles de auditar.
Una escala de madurez para investigar no es pedir una respuesta: es construir una cadena de evidencia
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.