Artefactos literarios

Simplemente crear embeddings del texto fuente muchas veces no alcanza. Las preguntas amplias pueden requerir material de apoyo generado que se indexa para recuperación sin tratarse como evidencia primaria.

Este capítulo es donde el pipeline RAG empieza a convertirse en producto en lugar de una demo genérica de búsqueda de documentos. El sistema de recuperación crudo puede encontrar pasajes, pero los artefactos literarios moldean el sistema alrededor de las expectativas de un usuario de club de lectura. Le dan a la aplicación su comportamiento de dominio: eso la convierte en un chat de club de lectura y no en un chat de información de viajes, documentos legales o PDFs genéricos.

La pregunta de diseño importante no es solo "¿qué texto indexamos?" También es "¿qué preguntarán usuarios reales y qué conocimiento de apoyo debería existir para que el sistema responda bien?" Para un asistente de club de lectura, los usuarios suelen preguntar por personajes, temas, escenario, motivaciones, simbolismo y prompts de discusión. Esas preguntas pueden requerir síntesis de todo el libro, no solo de un párrafo cercano.

Para mejorar esto, el worker genera chunks derivados adicionales:

• un perfil de club de lectura;
• un perfil de nombres/entidades.

Se crean mediante RAG.Core/Services/LiteraryArtifactGenerator.cs y el ILiteraryAnalysisProvider configurado.

El generador de artefactos lee chunks fuente representativos y pide al proveedor de IA seleccionado que cree resúmenes estructurados y buscables para el dominio. Estos resúmenes no reemplazan los chunks fuente. Son objetivos de recuperación adicionales que facilitan responder preguntas amplias centradas en el usuario.

Los artefactos generados se embeben y guardan en Qdrant como chunks normales, pero su chunkType los identifica:

literary_book_club_profile
literary_name_profile

Esta es una lección importante de RAG: la base vectorial puede almacenar tanto material fuente como material de apoyo generado. El material de apoyo debe diseñarse alrededor de las preguntas esperadas de los usuarios.

En un proyecto real, aquí importa el análisis de producto. Un sistema RAG útil empieza con el workflow del usuario, no solo con el esquema de base de datos o la elección del modelo. Si el producto fuera un chat de información de viajes, los artefactos generados podrían enfocarse en destinos, horarios, opciones de transporte, clima, accesibilidad y restricciones de itinerario. Si fuera un asistente legal, podrían enfocarse en partes, obligaciones, fechas, cláusulas, riesgos y definiciones. La capa de recuperación debe reflejar el trabajo que el usuario intenta hacer.

Para este MVP, el dominio esperado es discusión de club de lectura, así que el perfil generado se enfoca en:

• protagonistas probables;
• personajes principales;
• escenario;
• resumen de trama;
• arcos de personajes;
• temas;
• motivos;
• preguntas de discusión;
• notas de evidencia.

Procedencia de artefactos generados

El código mantiene honestos los artefactos generados con ChunkProvenance. Los chunks fuente no se marcan como generados. El perfil determinista de nombres registra Provider = "RAGPipeline", Model = "deterministic-name-extractor" y PromptVersion = "deterministic-name-profile-v1". El perfil de club de lectura del LLM registra el proveedor de IA configurado, modelo de chat, versión de prompt, timestamp de generación y los índices de chunks y páginas fuente usados para construir el perfil.

public sealed record ChunkProvenance(
    bool IsGenerated,
    string? ArtifactKind,
    string? Provider,
    string? Model,
    string? PromptVersion,
    DateTimeOffset? GeneratedAtUtc,
    IReadOnlyList<int>? SourceChunkIndexes,
    IReadOnlyList<int>? SourcePageNumbers);

Esa procedencia es la diferencia entre usar resúmenes generados responsablemente y fingir que son evidencia primaria. Los artefactos generados mejoran la recuperación, pero las citas y etiquetas de UI todavía deben decir al lector cuándo un chunk vino de material de apoyo generado.