Recuperación frente a representación en sistemas de conocimiento
La búsqueda no es estructura de conocimiento
La mayoría de los sistemas de conocimiento modernos optimizan la recuperación, y eso es comprensible. La búsqueda es visible, fácil de demostrar y parece mágica cuando funciona. Escribe una pregunta, obtén una respuesta.
Pero la recuperación es solo la mitad del problema. La pregunta más profunda es:
¿Qué forma tiene el conocimiento antes de que algo intente recuperarlo?
Eso es la representación: la estructura detrás del conocimiento:
- notas
- páginas
- esquemas
- grafos
- entidades
- relaciones
- resúmenes
- taxonomías
- límites de origen
- versiones canónicas
La recuperación pregunta:
¿Puedo encontrar algo relevante?
La representación pregunta:
¿El conocimiento está organizado de manera que tenga sentido?
Estos no son el mismo problema. Un sistema RAG con una mala representación se convierte en una interfaz rápida para un archivo desordenado. Puede recuperar fragmentos, pero no puede arreglar una estructura rota. Puede citar documentos, pero no puede decidir cuál es canónico. Puede ensamblar contexto, pero no puede garantizar que el conocimiento subyacente sea coherente.
Esto es por qué los sistemas estilo LLM Wiki son interesantes: desplazan el esfuerzo desde el momento de la consulta al momento de la ingestión. En lugar de solo recuperar fragmentos cuando un usuario hace una pregunta, intentan pre-estructurar el conocimiento en páginas, conceptos, resúmenes y enlaces. Eso no hace que RAG sea obsoleto; significa que la recuperación y la representación son capas diferentes, y los buenos sistemas de conocimiento necesitan ambas.
La distinción fundamental
La recuperación se trata del acceso; la representación se trata del significado.
| Capa | Pregunta | Ejemplos |
|---|---|---|
| Recuperación | ¿Cómo encuentro la información correcta? | búsqueda, embeddings, BM25, reranking, almacenes vectoriales |
| Representación | ¿Cómo se estructura el conocimiento? | notas, wikis, grafos, esquemas, ontologías |
| Razonamiento | ¿Cómo uso el conocimiento? | síntesis, comparación, inferencia, toma de decisiones |
Un sistema débil a menudo salta directamente a la recuperación; un sistema fuerte primero pregunta:
- ¿Cuáles son los conceptos centrales?
- ¿Cuál es la fuente canónica?
- ¿Qué relaciones importan?
- ¿Qué cambia con el tiempo?
- ¿Qué debe ser recuperado?
- ¿Qué ya debe estar representado?
Esta es la diferencia entre buscar sobre documentos y tener un sistema de conocimiento real.
Por qué la recuperación se volvió dominante
La recuperación se volvió dominante porque se adapta bien al stack moderno de IA. Un pipeline típico de RAG se ve así:
- Cargar documentos
- Dividirlos en fragmentos (chunks)
- Generar embeddings
- Almacenar vectores
- Recuperar fragmentos relevantes
- Reordenarlos (rerank) opcionalmente
- Insertarlos en un prompt de LLM
- Generar una respuesta
Este pipeline es práctico: es relativamente fácil de construir, funciona con documentos desordenados, escala a grandes corpús, evita el reentrenamiento de modelos y da a los LLMs acceso a información actual. Por eso RAG se convirtió en el patrón predeterminado para “IA sobre documentos”.
Pero hay una trampa:
RAG mejora el acceso al conocimiento. No mejora automáticamente el conocimiento.
Si tu contenido está duplicado, desactualizado, contradictorio, fragmentado mal o mal nombrado, la recuperación hará visibles esos problemas, a menudo con confianza.
Qué significa la representación
La representación es la forma en que se moldea el conocimiento antes de que ocurra la recuperación. Responde preguntas como:
- ¿Este conocimiento se almacena como documentos, notas, entidades o hechos?
- ¿Las relaciones son explícitas o implícitas?
- ¿Existen páginas canónicas?
- ¿Existen resúmenes?
- ¿Los conceptos están enlazados?
- ¿El sistema está organizado por tema, flujo de trabajo, tiempo o propiedad?
- ¿Un humano puede mantenerlo?
- ¿Una máquina puede razonar sobre ello?
La representación no es decoración; determina qué tipo de operaciones son posibles.
Formas de representación
Documentos
Los documentos son la representación más común. Los ejemplos incluyen:
- artículos
- PDFs
- manuales
- informes
- archivos README
- páginas de soporte
- publicaciones de blog
Los documentos son fáciles de escribir para los humanos, pero a menudo son difíciles de usar para las máquinas porque mezclan hechos, narrativa, contexto, ejemplos, opiniones, secciones desactualizadas y explicaciones repetidas en el mismo contenedor. Los documentos son buenos contenedores, pero no siempre son buenas estructuras de conocimiento.
Notas
Las notas son más flexibles que los documentos. Pueden ser:
- atómicas
- enlazadas
- privadas
- inacabadas
- centradas en conceptos
Un sistema de notas, como un PKM o una segunda mente, puede representar mejor el conocimiento en evolución que un repositorio de documentos pulidos. Las buenas notas capturan el pensamiento en progreso; las malas notas se convierten en un cajón desastre insalvable.
Wikis
Las wikis representan el conocimiento como páginas mantenidas. Una buena wiki tiene:
- páginas estables
- temas claros
- enlaces internos
- propiedad
- respuestas canónicas
- patrones de actualización
Una wiki es más fuerte que un volcado de documentos sueltos porque le da un hogar al conocimiento. “Lista de verificación de despliegue” vive en un lugar. “Respuesta a incidentes” vive en un lugar. “Arquitectura RAG” vive en un lugar. Eso importa porque la recuperación funciona mejor cuando el conocimiento tiene una estructura estable.
Grafos de conocimiento
Los grafos de conocimiento representan el conocimiento como entidades y relaciones. En lugar de almacenar solo texto, modelan cosas como:
- Persona trabaja en Proyecto
- Modelo soporta ContextLength
- Página depende de Concepto
- Servicio se conecta a Base de Datos
- Herramienta implementa Protocolo
Los grafos son poderosos porque las relaciones se vuelven explícitas, lo cual ayuda con la traversal, el análisis de dependencias, la resolución de entidades, la lineage, el razonamiento y las recomendaciones. Pero los grafos son costosos de mantener y no son mágicos: un mal grafo es solo confusión estructurada.
Esquemas y ontologías
Los esquemas definen la estructura esperada; las ontologías van más allá y definen tipos, relaciones y restricciones. Responden a:
- ¿Qué tipos de cosas existen?
- ¿Qué propiedades tienen?
- ¿Cómo pueden relacionarse?
- ¿Qué reglas aplican?
Esto es útil cuando la corrección importa, como en el conocimiento médico, conocimiento legal, catálogos de datos empresariales, taxonomías de productos y sistemas de cumplimiento. El compromiso es la rigidez: cuanto más formal sea la representación, más costoso es evolucionarla.
Representaciones generadas por LLM
Los sistemas modernos utilizan cada vez más LLMs para crear representaciones. Los ejemplos incluyen:
- resúmenes
- entidades extraídas
- páginas de temas
- mapas conceptuales
- FAQs sintéticas
- esquemas de documentos
- enlaces cruzados
- entradas de glosario
Aquí es donde se sitúan los sistemas estilo LLM Wiki. Utilizan el modelo no solo para responder consultas, sino para pre-procesar y estructurar el conocimiento antes de que ocurra la consulta. RAG dice “recuperar fragmentos relevantes en el momento de la consulta”; LLM Wiki dice “compilar estructuras de conocimiento útiles en el momento de la ingestión”. Ambos patrones pueden coexistir en la misma arquitectura.
Qué significa la recuperación
La recuperación es el proceso de encontrar información relevante. Los métodos de recuperación comunes incluyen:
- búsqueda por palabras clave
- búsqueda de texto completo
- búsqueda vectorial
- búsqueda híbrida
- filtrado por metadatos
- traversal de grafos
- reranking
- reescritura de consultas
- búsqueda agéntica
La recuperación no es una sola cosa; es un stack apilado de métodos complementarios.
Búsqueda por palabras clave
La búsqueda por palabras clave coincide términos y sigue siendo útil porque es predecible, depurable, rápida y buena para términos exactos, IDs, mensajes de error, nombres y código. Su debilidad es la discrepancia semántica: si el usuario busca “cómo detener respuestas repetidas” pero el documento dice “penalización de presencia”, la búsqueda por palabras clave puede perder el mejor resultado.
Búsqueda vectorial
La búsqueda vectorial recupera por similitud semántica. Es útil cuando:
- la redacción difiere
- los conceptos son difusos
- los usuarios hacen preguntas en lenguaje natural
- los documentos usan terminología inconsistente
Su debilidad es la precisión: la búsqueda vectorial puede recuperar cosas que parecen relacionadas pero que no son realmente correctas, lo cual es especialmente arriesgado en sistemas técnicos.
Búsqueda híbrida
La búsqueda híbrida combina la recuperación de palabras clave y vectorial, lo cual a menudo es mejor que cualquiera por separado. La búsqueda de palabras clave atrapa coincidencias exactas; la búsqueda vectorial atrapa coincidencias conceptuales. Para bases de conocimiento técnico, la recuperación híbrida suele ser un valor predeterminado fuerte.
Reranking
El Reranking toma un conjunto inicial de resultados recuperados y los reordena usando un modelo más fuerte. Esto mejora la calidad porque el primer paso de recuperación suele ser amplio. Un patrón típico recupera 50 fragmentos, los reordena a los 5 o 10 mejores, y luego pasa solo el mejor contexto al LLM. El reranking es una de las formas más prácticas de mejorar la calidad de RAG.
Recuperación agéntica
La recuperación agéntica convierte la búsqueda en un proceso. En lugar de una sola consulta, un agente puede:
- Hacer una pregunta inicial
- Buscar
- Inspeccionar resultados
- Reformular la consulta
- Buscar de nuevo
- Comparar fuentes
- Sintetizar una respuesta
Esto está más cerca de la investigación que de la búsqueda. Es útil para preguntas complejas, pero es más lento y más difícil de controlar.
La recuperación sin representación es frágil
Un sistema de recuperación solo puede recuperar lo que existe. No puede arreglar de manera fiable:
- conceptos poco claros
- páginas duplicadas
- terminología inconsistente
- documentación desactualizada
- falta de propiedad de la fuente
- declaraciones contradictorias
- enlaces internos débiles
- límites de documentos deficientes
Este es el error más común en los proyectos RAG: los equipos construyen una base de datos vectorial y esperan que se convierta en un sistema de conocimiento. Una base de datos vectorial no es una arquitectura de conocimiento; es una capa de acceso.
La representación sin recuperación es aislada
También existe el fallo opuesto. Puedes tener una base de conocimiento bellamente estructurada que nadie puede encontrar. Esto ocurre con:
- wikis sobre-diseñadas
- árboles de carpetas profundos
- taxonomías rígidas
- documentación mal indexada
- sistemas de notas privados sin descubrimiento
- grafos sin interfaces utilizables
La representación da estructura al conocimiento; la recuperación da alcance al conocimiento. Necesitas ambas.
El mapa de compensaciones
Velocidad vs coherencia
La recuperación es rápida de construir y la representación toma más tiempo. Si necesitas un prototipo, la recuperación gana; si necesitas confianza a largo plazo, la representación importa más.
| Prioridad | Mejor punto de partida |
|---|---|
| Q&A rápido sobre muchos documentos | Recuperación |
| Conocimiento técnico estable | Representación |
| Investigación exploratoria | PKM más recuperación |
| Asistente empresarial | Corpús estructurado más RAG |
| Memoria de agente | Representación más recuperación selectiva |
Un prototipo RAG puro se puede construir rápidamente, pero un sistema de conocimiento fiable requiere curación.
Flexibilidad vs consistencia
Los documentos sueltos son flexibles; el conocimiento estructurado es consistente. La flexibilidad ayuda cuando:
- el dominio cambia rápidamente
- el conocimiento es incompleto
- los usuarios están explorando
- el sistema es personal
La consistencia ayuda cuando:
- varias personas dependen de ello
- las respuestas deben ser confiables
- los flujos de trabajo dependen de ello
- los sistemas de IA lo consumen
Cuanta más gente o agentes dependan del conocimiento, más importa la representación.
Recall vs precisión
Los sistemas de recuperación a menudo optimizan el recall primero, lo que significa encontrar cualquier cosa que pueda ser relevante. Pero las buenas respuestas necesitan precisión, lo que significa encontrar la mejor evidencia en lugar de meramente evidencia relacionada. La representación mejora la precisión haciendo que los conceptos y los límites sean más claros: una página bien estructurada es más fácil de recuperar con precisión que un párrafo aleatorio enterrado dentro de un documento largo.
Costo en tiempo de ingestión vs costo en tiempo de consulta
RAG generalmente desplaza el trabajo al tiempo de consulta. En el momento de la consulta, el sistema:
- reescribe la consulta
- recupera fragmentos
- reordena resultados
- ensambla contexto
- pide al modelo que razone sobre fragmentos
Los sistemas estilo LLM Wiki desplazan más trabajo al tiempo de ingestión. En el momento de la ingestión, el sistema:
- lee fuentes
- extrae conceptos
- escribe resúmenes
- crea páginas
- enlaza ideas relacionadas
- mantiene la estructura
| Arquitectura | Paso costoso | Beneficio |
|---|---|---|
| RAG | Tiempo de consulta | Recuperación flexible |
| LLM Wiki | Tiempo de ingestión | Estructura pre-compilada |
| Grafo de conocimiento | Tiempo de modelado | Relaciones explícitas |
| Wiki | Tiempo de mantenimiento | Conocimiento canónico |
Ninguno de estos es universalmente mejor; optimizan costos diferentes.
Por qué existe LLM Wiki
LLM Wiki existe porque la recuperación a menudo repite el trabajo. En un sistema RAG normal, cada consulta puede forzar al modelo a interpretar fragmentos crudos de nuevo:
- Recuperar fragmentos sobre un tema
- Pedir al LLM que infiera el concepto
- Generar una respuesta
- Olvidar la síntesis
- Repetir la próxima vez
LLM Wiki dice:
Deja de re-derivar la misma síntesis. Compíla.
En lugar de solo almacenar documentos crudos, crea páginas estructuradas que resumen y conectan el conocimiento, lo cual puede mejorar la coherencia, la reutilización, la eficiencia de tokens, la legibilidad humana y el mantenimiento a largo plazo. Pero tiene un costo: el sistema debe mantener la wiki, y si la wiki es incorrecta, desactualizada o alucinada, la estructura se vuelve peligrosa.
Alucinación de RAG vs mala representación
La gente a menudo culpa al LLM cuando un sistema RAG da una mala respuesta, y a veces eso es correcto. Pero muchos fallos son en realidad fallos de recuperación o de representación.
Modo de fallo 1. Documento correcto, fragmento incorrecto
La respuesta existe, pero la fragmentación la divide mal. El modelo recibe:
- la mitad de un párrafo
- contexto faltante
- una tabla sin explicación
- una definición sin restricciones
El LLM llena esos vacíos, lo que parece una alucinación, pero el problema más profundo es una representación rota.
Modo de fallo 2. Fragmento relacionado, respuesta incorrecta
La búsqueda vectorial recupera algo semánticamente similar pero operativamente incorrecto. La consulta pregunta sobre el despliegue en producción; el fragmento recuperado discute el desarrollo local. Los términos se superponen pero el significado difiere, por lo que el modelo responde con instrucciones de configuración local para un problema de producción. Esta es imprecisión de recuperación.
Modo de fallo 3. Fuentes conflictivas
Dos documentos discrepan: uno antiguo, uno nuevo. El sistema de recuperación devuelve ambos, y el LLM los fusiona en una respuesta confiable pero inválida. Esto no es solo un problema de recuperación, sino un problema de representación, porque la base de conocimiento carece de estado canónico.
Modo de fallo 4. Sin modelo conceptual
El sistema tiene muchos documentos pero sin modelo del dominio. No sabe que:
- “memoria de agente” difiere de “RAG”
- “wiki” difiere de “PKM”
- “búsqueda de embeddings” difiere de “búsqueda de texto completo”
- “despliegue” difiere de “alojamiento”
Sin representación conceptual, la recuperación se convierte en coincidencia difusa.
Modo de fallo 5. La estructura generada se convierte en autoridad falsa
Los sistemas LLM Wiki tienen su propio modo de fallo. Si un LLM genera una página limpia a partir de fuentes malas, el resultado puede parecer más autorizado que el material original. Esto es peligroso: una alucinación pulida es peor que un documento fuente desordenado. Cualquier representación generada necesita:
- enlaces de fuente
- revisión
- reglas de actualización
- marcadores de confianza
- propiedad
Implicaciones de diseño
Optimizar la recuperación cuando el corpús es grande y dinámico
La recuperación debe ser la prioridad cuando:
- el corpús es enorme
- los documentos cambian frecuentemente
- los usuarios hacen muchas preguntas impredecibles
- necesitas cobertura amplia
- la estructura perfecta es irrealista
Ejemplos: bases de conocimiento de soporte, búsqueda de documentos empresariales, asistentes de investigación, chat interno sobre muchos archivos, descubrimiento legal y bots de servicio al cliente. En estos casos, invierte en una recuperación sólida:
- búsqueda híbrida
- filtros de metadatos
- reranking
- reescritura de consultas
- citación de fuentes
- conjuntos de evaluación
Optimizar la representación cuando la coherencia importa
La representación debe ser la prioridad cuando:
- el conocimiento debe ser confiable
- las respuestas deben ser consistentes
- los conceptos se reutilizan a menudo
- el dominio tiene una estructura clara
- múltiples sistemas dependen de ello
Ejemplos: conocimiento de arquitectura, documentación de productos, reglas de cumplimiento, referencias de API, libros de operaciones, colecciones de investigación curadas y clústeres de blogs técnicos. En estos casos, invierte en:
- páginas canónicas
- términos de glosario
- diagramas
- enlaces internos
- propiedad
- versionado
- cadencia de revisión
Optimizar ambos cuando los sistemas de IA dependen del conocimiento
Si un agente de IA depende del conocimiento, la recuperación por sí sola generalmente no es suficiente. Los agentes necesitan:
- contexto estable
- reglas de tarea claras
- memoria duradera
- referencias estructuradas
- límites de fuente
- comportamiento de actualización
Para los sistemas agénticos, la representación se convierte en parte del diseño del sistema. Un agente de codificación no solo necesita recuperar “algunos documentos”; necesita saber:
- convenciones del proyecto
- decisiones de arquitectura
- patrones de comando
- dependencias prohibidas
- flujo de trabajo de pruebas
- reglas de despliegue
Parte de eso pertenece a RAG, parte a la memoria y parte a la documentación estructurada del proyecto.
Marco de decisión práctica
Si el problema es encontrar información
Optimiza la recuperación. Ejemplos:
- “Encuentra páginas relevantes.”
- “Responde preguntas sobre documentos.”
- “Busca en muchos PDFs.”
- “Localiza tickets de soporte similares.”
Usa:
- búsqueda de texto completo
- búsqueda vectorial
- recuperación híbrida
- reranking
- filtrado por metadatos
Si el problema es hacer el conocimiento coherente
Optimiza la representación. Ejemplos:
- “Crea una explicación canónica.”
- “Resuelve páginas duplicadas.”
- “Define el modelo de dominio.”
- “Construye una base de conocimiento estable.”
Usa:
- páginas de wiki
- mapas conceptuales
- taxonomías
- grafos de conocimiento
- resúmenes
- esquemas
Si el problema es la síntesis repetida
Usa representación compilada. Ejemplos:
- “Respondemos las mismas preguntas conceptuales repetidamente.”
- “El sistema sigue re-resumiendo las mismas fuentes.”
- “Necesitamos una capa de síntesis estable.”
Usa:
- LLM Wiki
- resúmenes curados
- páginas de temas
- páginas generadas revisadas por humanos
Si el problema es la continuidad adaptativa
Usa memoria. Ejemplos:
- “El agente debería recordar las preferencias del usuario.”
- “El agente de codificación debería recordar las convenciones del proyecto.”
- “El asistente debería continuar el trabajo entre sesiones.”
Usa:
- memoria de agente
- almacenes de preferencias
- memoria episódica
- memoria semántica
- memoria del proyecto
Cómo esto se aplica a un blog técnico
Un blog técnico puede ser más que una secuencia de publicaciones; puede convertirse en un sistema de conocimiento representado. Los artículos son documentos, las categorías son una taxonomía débil, los enlaces internos son aristas de grafo, las páginas pilar son resúmenes canónicos, las páginas de series son caminos curados y la búsqueda es recuperación. Si solo publicas publicaciones aisladas, la recuperación tiene que trabajar más duro. Si construyes una representación fuerte, la recuperación se vuelve más fácil.
Eso significa:
- límites de clúster claros
- slugs estables
- páginas canónicas
- páginas de comparación
- explicadores estilo glosario
- enlaces internos
- metadatos estructurados
Esto es por qué la arquitectura del sitio importa: no solo para el SEO, sino porque es representación de conocimiento. El clúster de Knowledge Management en este sitio es en sí mismo un ejemplo de publicación centrada en la representación.
Cómo esto se aplica a RAG
La calidad de RAG depende en gran medida de la representación. Un corpús fuente bien estructurado mejora:
- calidad de los fragmentos
- precisión de la recuperación
- calidad de la citación
- consistencia de la respuesta
- claridad de la evaluación
Antes de construir un pipeline RAG complejo, pregunta:
- ¿Los documentos fuente están actualizados?
- ¿Se eliminaron los duplicados?
- ¿Los conceptos importantes están claramente nombrados?
- ¿Las páginas tienen alcance correcto?
- ¿Las tablas y bloques de código son recuperables?
- ¿Las respuestas canónicas son evidentes?
- ¿Los límites de los documentos tienen sentido?
Si la respuesta es no, mejores embeddings solo ayudarán tanto.
Cómo esto se aplica a LLM Wiki
LLM Wiki es un patrón centrado en la representación. Es útil cuando:
- el corpús es pequeño o mediano
- el conocimiento es lo suficientemente estable para resumir
- la síntesis repetida es costosa
- los humanos se benefician de páginas legibles
- quieres estructura antes de la recuperación
Es menos útil cuando:
- el corpús es masivo
- el contenido cambia constantemente
- la frescura es más importante que la coherencia
- la gobernanza es débil
- los resúmenes generados no pueden ser revisados
LLM Wiki no es un reemplazo para RAG, sino una capa diferente, y un sistema fuerte puede usar ambos:
- LLM Wiki crea resúmenes estructurados.
- RAG recupera de fuentes crudas y páginas de wiki.
- La revisión humana mantiene la representación confiable.
Patrones de arquitectura sugeridos
Patrón 1. Primero la recuperación
Usa cuando la velocidad importa.
documentos
-> fragmentos
-> embeddings
-> recuperación
-> respuesta LLM
Bueno para:
- prototipos
- búsqueda amplia
- corpús grandes
- experimentos tempranos
Debilidad: la coherencia depende de la calidad de la fuente.
Patrón 2. Primero la representación
Usa cuando la confianza importa.
fuentes
-> páginas curadas
-> enlaces internos
-> base de conocimiento mantenida
-> búsqueda o RAG
Bueno para:
- documentación
- conocimiento técnico
- contenido a largo plazo
- conocimiento del equipo
Debilidad: requiere mantenimiento.
Patrón 3. Conocimiento compilado
Usa cuando la síntesis repetida importa.
fuentes crudas
-> extracción LLM
-> resúmenes generados
-> páginas de temas
-> base de conocimiento revisada
-> recuperación
Bueno para:
- sistemas LLM Wiki
- colecciones de investigación
- bases de conocimiento personales
- dominios estables
Debilidad: la estructura generada debe ser auditada.
Patrón 4. Arquitectura de conocimiento híbrida
Usa cuando construyes sistemas serios.
documentos crudos
-> capa de conocimiento estructurado
-> índice de búsqueda
-> recuperación y reranking
-> respuesta IA
-> retroalimentación y mantenimiento
Bueno para:
- RAG de producción
- sistemas de conocimiento interno
- asistentes de IA
- sistemas de publicación técnica
Debilidad: más partes móviles.
Preguntas de evaluación
Para evaluar la recuperación, pregunta:
- ¿El sistema encontró la fuente correcta?
- ¿Clasificó la fuente correcta en alto?
- ¿Recuperó suficiente contexto?
- ¿Evitó el contexto irrelevante?
- ¿La respuesta citó la fuente correcta?
Para evaluar la representación, pregunta:
- ¿El conocimiento está estructurado claramente?
- ¿Existe una página canónica?
- ¿Los conceptos están nombrados consistentemente?
- ¿Las relaciones son explícitas?
- ¿El contenido está mantenido?
- ¿Pueden humanos y máquinas usarlo?
No evalúes un sistema de conocimiento solo por la calidad de la respuesta; una buena respuesta puede ocultar una mala estructura.
La regla de opinión
Si tu sistema falla ocasionalmente, mejora la recuperación. Si falla repetidamente en la misma área conceptual, mejora la representación.
Una mala recuperación pierde la información correcta. Una mala representación significa que la información correcta realmente no existe en una forma utilizable.
Conclusión
La recuperación y la representación resuelven problemas diferentes: la recuperación da acceso, la representación da estructura. RAG es poderoso porque hace que el conocimiento externo esté disponible para los LLMs en el momento de la consulta, pero RAG no hace automáticamente que el conocimiento sea coherente, canónico o mantenido. Es por eso que las wikis, los sistemas PKM, los grafos de conocimiento y los sistemas estilo LLM Wiki siguen importando.
El futuro no es recuperación vs representación, sino sistemas de conocimiento apilados:
- representación para la estructura
- recuperación para el acceso
- memoria para la continuidad
- razonamiento para la síntesis
Si estás construyendo un sistema de conocimiento serio, no comiences con la base de datos vectorial. Comienza con la forma del conocimiento, luego decide cómo debe ser recuperado.
