Pipeline de investigación
ResearchRaven
Un pipeline automatizado que convierte la investigación en la web en conocimiento estructurado, y el conocimiento estructurado en textos publicables.
Las herramientas de investigación son buenas encontrando y malas en todo lo que viene después. Devuelven más material del que nadie puede leer y no dejan nada atrás: la siguiente pregunta vuelve a empezar de cero. ResearchRaven parte de la premisa contraria: que el artefacto duradero es la estructura, no el resultado de búsqueda.
El sistema recopila fuentes sobre un tema, organiza lo encontrado en una base de conocimiento navegable y escribe a partir de ella en el formato que haga falta: un artículo, un boletín, un capítulo. Cada uno de esos pasos es una fase propia con un límite definido, y eso es lo que permite reconstruir cualquiera de ellas sin tocar las demás.
Cómo funciona
La arquitectura sigue una sola idea: investigar y leer exigen formas opuestas, y la tarea del sistema es convertir entre ellas.
Plano
Investigación
Las fuentes se recopilan y se resumen de forma independiente, cada una en sus propios términos. Aquí no se juzga la relevancia, y es deliberado: esa decisión pertenece al momento en que se formula una pregunta, no al momento en que se recoge el material.
Jerárquico
Conocimiento
El material recopilado se organiza en una estructura navegable y se enlaza entre documentos. Es la fase que convierte un montón de resúmenes en algo capaz de responder preguntas para las que no fue recopilado.
Lineal
Contenido
Un fragmento de la base de conocimiento se proyecta de vuelta a un único orden de lectura y se redacta en el formato de destino. La fase de escritura usa la base de conocimiento como un servicio y nunca necesita saber cómo está organizada por dentro.
Plano, después jerárquico, después plano otra vez
La investigación llega plana. Las fuentes están una al lado de la otra, cada una resumida en sus propios términos, sin que ninguna sepa de las demás. Esa es la forma natural de la recopilación, y es una mala forma para comprender.
El conocimiento exige jerarquía. Los temas contienen aspectos, los aspectos contienen subaspectos, y las afirmaciones se conectan a través de ellos. Construir esa estructura es el paso donde está el trabajo de verdad.
La lectura vuelve a exigir lo plano. Nadie lee un grafo; quien lee sigue una línea de principio a fin. Por eso la última fase proyecta un fragmento de la jerarquía de vuelta a una única secuencia, adaptada al formato.
Ese ida y vuelta es el diseño. La teoría de la información describe el coste de pasar de una forma a otra desde Shannon; Miller cuantificó qué poco de una jerarquía puede sostener un lector a la vez; Sweller mostró por qué recopilar y estructurar al mismo tiempo degrada ambas cosas. Separar las fases es lo que se deduce de esas restricciones.
Por qué importa el límite
La interfaz entre organizar y escribir es la única costura que debe permanecer limpia. Mientras la fase de escritura pida conocimiento por tema en lugar de meterse en sus interioridades, la capa de conocimiento puede reconstruirse —y así ha sido— sin tocar nada aguas abajo.
Cómo se establece la calidad
Un pipeline de modelos de lenguaje es fácil de demostrar y difícil de acreditar. La pregunta interesante no es si produce resultados plausibles, sino qué ocurre cuando se mide contra un listón fijado antes de la medición.
Los umbrales se fijan antes de la ejecución, no después
El listón de aceptación de cada capacidad se deja por escrito en un documento de decisión arquitectónica antes de tomar ninguna medida. Comprometerse con el listón de antemano es lo que hace que un fallo sea interpretable en lugar de negociable: un umbral acordado después de ver el resultado no es un umbral.
Un resultado halagador resultó ser un artefacto
Una capacidad se midió como prácticamente perfecta. Al repetir la misma medición con un evaluador ciego e independiente —un modelo nuevo sin acceso a las respuestas de referencia— el resultado fue notablemente peor, y ambos evaluadores discreparon en una parte considerable de los casos. La cifra favorable procedía de un evaluador que compartía contexto con el sistema al que calificaba. El hallazgo era sobre el montaje de la evaluación, no sobre la función, y ese es el tipo de error que valida en silencio todo lo que viene después.
Cuando falló el umbral, cambió la arquitectura
Una capacidad no alcanzó su listón a escala realista. El análisis del fallo separó dos causas: la mayoría de los fallos eran cuestión de la amplitud de la búsqueda, pero algunos eran fallos de representación que ninguna búsqueda adicional recupera. Junto con la observación de que la operación era irreversible —destruía justamente la distinción que erraba—, el trabajo pasó del momento de escritura al momento de lectura. El umbral nunca se rebajó para encajar con el resultado.
Los resultados solo cuentan si son reproducibles
La capa de conocimiento derivada puede borrarse y reconstruirse a partir de los archivos fuente, y la reconstrucción es idéntica byte a byte. Las mediciones tomadas contra un estado que no puede reconstruirse son anécdotas, no pruebas.
Nada de esto hace que el sistema sea correcto. Hace que sus fallos se vean pronto, y obliga a la arquitectura a absorberlos en lugar de a los criterios de aceptación.
Dónde se sitúa
El diseño empezó con un estudio del terreno en lugar de una hoja en blanco, y vuelve a uno cada vez que se reconstruye una capa.
Se evaluaron diez sistemas existentes antes de escribir la primera línea, entre ellos Fabric, GPT Researcher, STORM, CrewAI, Khoj, Quivr y Open Deep Research. La mayoría resuelve bien la recuperación. Pocos dejan tras de sí un artefacto que sobreviva a la consulta, y esa carencia definió en qué iba a consistir este proyecto.
La capa de conocimiento se volvió a estudiar antes de reconstruirla: GraphRAG, RAPTOR, estructuras de índice jerárquico de los frameworks de recuperación consolidados, análisis del discurso y la tradición de la gestión personal del conocimiento —Zettelkasten, Obsidian, Logseq, Roam— por cómo manejan los enlaces entre notas sin que el conjunto de enlaces se dispare.
La conclusión que dio forma al diseño actual es una separación que los sistemas estudiados en su mayoría no hacen: estructurar un solo documento y enlazar entre documentos son problemas distintos con modos de fallo distintos, y fundirlos en un único grafo es lo que produce los fallos medidos más arriba. Mantenerlos separados es la apuesta de esta arquitectura.
Hacia dónde va
ResearchRaven está construido en torno a la observación de que en el trabajo del conocimiento no suele escasear la información, sino la estructura. Los buscadores y los modelos de lenguaje devuelven más material del que nadie puede abarcar; lo que ninguno hace es dejar atrás un artefacto que resulte más útil cuanto más se le aporta.
Por eso el sistema está diseñado para la permanencia y no para el rendimiento bruto. El conocimiento se captura sin decidir de antemano su relevancia, porque la relevancia es una propiedad de la pregunta que se hará después, no del momento de la captura. Se guarda en archivos simples bajo control de versiones y no en una base de datos, de modo que sobrevive a la herramienta que lo produjo. Y su coste se gobierna de forma explícita, porque un sistema que no puede operarse dentro de un presupuesto no es un sistema que se mantenga en marcha.
La dirección va del texto breve al texto largo: de las publicaciones y los boletines hacia los capítulos y los libros. Son los formatos donde la diferencia entre el conocimiento acumulado y los fragmentos recuperados se nota de verdad.