Overview
| Property | Detail |
|---|
| Pattern | Relevant Segment Extraction (RSE) — The Context Reconstructor |
| Level | 4 (Better post-retrieval) |
| Key Innovation | Finds best CONTIGUOUS section, not scattered chunks |
| Core Algorithm | Maximum sub-array (Kadane's-style) |
| Notebook | 10_Contextual_Compression.ipynb |
Architecture
flowchart TD
A["1. Chunk Document (NO overlap)"] --> B["2. Score ALL Chunks Against Query"]
B --> C["3. Subtract Threshold from Each Score"]
C --> D["4. Find MAX-SUM Contiguous Segment\n(Kadane's Algorithm)"]
D --> E["5. Concatenate Best Segment"]
E --> F["Return Coherent Passage"]
style D fill:#1e293b,stroke:#f59e0b,stroke-width:2px
Test Results (Actual Notebook Output)
Query: "What are the effects of climate change on sea levels?"
| Method | Result |
|---|
| Simple top-3 | 3 scattered chunks (~2,400 chars) from random parts |
| RSE | Chunks 7-12 contiguous (4,804 chars) = "Chapter 3: Effects of Climate Change" |
RSE correctly identified that the entire "Effects" chapter is the best context — not 3 isolated paragraphs.
The Problem RSE Solves
| Issue with Simple RAG | How RSE Fixes It |
|---|
| Top-K chunks are scattered across document | Finds contiguous section |
| Chunks cut mid-sentence | No-overlap chunking + concatenation |
| Missing "glue" between relevant chunks | Includes slightly-irrelevant chunks if sandwiched |
| LLM gets fragments, not narrative | LLM gets coherent passage |
The Algorithm (Simple Version)
Chunk values: [-0.2, -0.2, 0.4, 0.8, -0.1, 0.6, 0.3, -0.2, -0.2]
↑_____________________↑
Best segment: chunks 3-7, sum = 2.0
Key insight: Chunk 5 (value -0.1) is included even though it's slightly irrelevant — because the overall segment including it has a higher total value than skipping it.
RSE vs Simple RAG vs Semantic Chunking
| Aspect | Simple RAG | Semantic Chunking | RSE |
|---|
| Returns | Top-K scattered chunks | Top-K coherent chunks | Best contiguous section |
| Context for LLM | Fragments | Better fragments | Full narrative |
| Character count | ~2,400 (3 chunks) | ~2,400 (3 chunks) | ~4,800 (whole section) |
| Best for | Quick lookups | Topic-based queries | Multi-paragraph answers |
When to Use
| Scenario | Use RSE? |
|---|
| Questions needing multi-paragraph answers | Yes |
| Documents with info in consecutive sections | Yes |
| Need LLM to have coherent narrative, not fragments | Yes |
| Reports, papers, legal docs | Yes |
| Simple one-fact lookups | No — overkill |
| Scattered info across unrelated sections | No — simple top-K is fine |
Tech Stack
| Component | Technology |
|---|
| Embeddings | AWS Bedrock — Amazon Titan Embed Text v2 (1024 dims) |
| LLM | AWS Bedrock — Claude Sonnet |
| Vector DB | Qdrant Cloud (cosine similarity) |
| Chunk Size | 800 characters (no overlap) |
| Algorithm | Maximum sub-array (modified Kadane's) |
| Framework | LangChain |
Source