AI Tech Inspire

Exact Recipe Retrieval at Scale: Chunking, Reranking, and Boundaries

When a user searches for paella across a stack of scanned cookbooks, they don’t want a paraphrase — they want the original recipes, intact. At AI Tech Inspire, we spotted a practical question that many IR/RAG builders quietly wrestle with: how do you return many exact passages from large, messy document collections without regenerating text?

Quick facts from the problem statement

  • Goal: natural language search over large unstructured cookbooks, returning complete, unmodified recipes.
  • Example: user uploads ~100 cookbooks, searches “paella,” expects ~40 exact recipe returns.
  • Constraint: traditional RAG is a poor fit because the output must be the exact source text (no summaries).
  • Two candidate approaches: (1) precise chunking at index time to match recipe boundaries; (2) simpler chunking + better retrieval + a post-processing step to find true recipe boundaries.
  • Challenge: detecting recipe start/end boundaries is error-prone; NER may be too granular for this task.

Why this matters to builders

Most retrieval-augmented generation systems optimize for answer snippets or summaries. Here, the requirement flips: retrieval must output the complete original section — think legal clauses, medical protocols, or, in this case, recipes. The same techniques generalize to standards, operating manuals, API docs, and historical archives. If your app needs fidelity over fluency, this is your playbook.

Key takeaway: Treat this as an information retrieval and segmentation problem first; LLMs can assist, but should not rewrite output.

Two viable strategies (and when to use each)

There are two main paths — both “RAG-adjacent,” but grounded in IR and document structure.

1) Boundary-accurate chunking at index time

Extract structure once, index recipes as the atomic unit, and return exact matches.

  • Layout-aware parsing: Use PDF or EPUB parsers that retain layout (headings, font sizes, bullets). Tools like pdfplumber, PyMuPDF, Apache Tika, or layout libraries (e.g., LayoutParser) can help segment pages into blocks.
  • Heuristic boundary detection: Detect a recipe start when a heading-like line is followed by an ingredients-looking list (quantities, units, bullets), then instructions paragraphs. Simple signals like lines starting with 1 cup, 2 tbsp, or numbered steps can be powerful anchors.
  • Sequence labeling model: Train a lightweight boundary detector on lines/blocks using BIO tags (B-RECIPE, I-RECIPE, O). A small model in PyTorch can learn patterns across different cookbooks; bootstrap with heuristics, refine via active learning.
  • Metrics: Optimize for segment-level F1 on start/end accuracy. A few hundred labeled pages can produce good results because cookbook structure is repetitive.
  • Index design: Once boundaries are reliable, index each recipe as a single document. Use hybrid search (BM25 + dense vectors). Store page spans and character offsets so you can render the exact source.

When this shines: stable layouts, recurring patterns, and a need for consistent, deterministic results. Invest here if you control ingestion and expect to scale to thousands of books.

2) Simple chunking + smarter retrieval + boundary post-processing

Chunk with a coarse strategy (e.g., 512–1,000 tokens with overlap), then snap matched chunks to true boundaries after retrieval.

  • Hybrid retrieval: Combine lexical (BM25) and semantic embeddings. For embedding and reranking models, check Hugging Face for sentence encoders and cross-encoders trained on MS MARCO. Use FAISS for vector search, and consider approximate settings that favor recall when returning large k (e.g., 100–500 candidates).
  • Reranking at query time: Use a cross-encoder re-ranker to sort candidates by relevance. This boosts precision before boundary snapping. Keep it efficient; rerank top 200–500 hits, not millions.
  • Boundary snapping: From a top chunk, scan outward to the nearest heading-like line, ingredients block, and the end of instructions. Merge across adjacent chunks until you collect a full recipe.
  • LLM-assisted classification (no generation): If heuristics are uncertain, ask an LLM like GPT to label lines as header, ingredients, instructions, or other — but only to produce tags. Always render the original text using stored offsets.

When this shines: heterogeneous document quality, varied layouts across books, or when rapid prototyping matters more than an upfront heavy parsing pipeline.

A practical pipeline blueprint

Here’s a battle-tested flow many teams adapt:

  • Ingestion: Extract text with layout. Preserve per-line features: font size, bold/italic flags, indentation, bullet markers, page numbers.
  • Weak heuristics: Regex and rules to flag likely headings (short, Title Case), ingredients (quantity-unit patterns), and instructions (imperatives like “Heat,” “Stir”).
  • Boundary model (optional but recommended): Train a small sequence labeler in PyTorch using heuristics as noisy labels, then correct with a few rounds of human-in-the-loop. If you prefer a transformer, start with a compact encoder on Hugging Face.
  • Indexing: Store both (a) recipe-level documents (if boundary model exists) and (b) overlapping chunk-level documents. This dual index lets you fall back gracefully.
  • Search: Hybrid retrieval (BM25 + dense). Consider late-interaction models like ColBERT for high recall on large corpora while keeping chunks reasonably small.
  • Rerank: Cross-encoder rerank of top N. If you need to surface ~40 recipes, request top 200–500 from the index to maintain recall, then rerank down.
  • Post-process: Boundary snapping + deduplication (MinHash/LSH on shingles can collapse near-duplicates). Always use stored offsets to return verbatim text.
  • Acceleration: GPU-accelerate embedding and reranking using CUDA. Batch embeddings, cache frequent queries, and consider reusing memory-mapped FAISS indexes.

Notice what’s missing: no generation step. LLMs act as classifiers or re-rankers, not authors.

Details that move the needle

  • Recall vs. precision when k is large: If users expect dozens of results, set ANN (FAISS/ScaNN) to favor recall. Follow with a strong reranker. For lexical, tune BM25 parameters on a validation set.
  • OCR edge cases: Scanned cookbooks need OCR. Use language-aware OCR and keep confidence scores. Lines with low confidence shouldn’t decide boundaries — let neighbors vote.
  • Multilingual inputs: Pick multilingual encoders if recipes span languages. Units and measures are your universal anchors.
  • Normalization without mutation: You can normalize internally (e.g., strip extra whitespace, standardize bullets) for matching, but always render the original characters for the user.
  • Source attribution: Include book title, page range, and a “jump to source” link. Users often want provenance and context.

What about NER?

Named Entity Recognition tends to be too granular for this framing. It’s great for extracting ingredients or tools, but boundary detection is a segmentation or sequence labeling problem. If you need both, run entity extraction after segmentation.

Lightweight example flow

Think of a query-time routine like this:

query -> hybrid search (top 300 chunks) -> cross-encoder rerank (top 100) -> for each candidate: snap_to_boundaries() -> dedupe() -> return top 40 recipes

If snap_to_boundaries() is uncertain, optionally call an LLM to label lines, then re-snap based on predicted tags (still returning original text by offsets).

Tools to explore

  • Indexing & retrieval: FAISS for vector search; Elasticsearch/OpenSearch for BM25 and hybrid queries.
  • Encoders & rerankers: Sentence Transformers and cross-encoders from Hugging Face.
  • Training & acceleration: PyTorch for custom boundary models; CUDA for GPU speedups.
  • LLM assistance: Use GPT in classification-only prompts when heuristics disagree.

Questions to pressure-test your design

  • Do you prefer upfront effort (accurate boundaries) or flexible retrieval with smarter post-processing?
  • What’s your acceptable latency to return 40 full recipes? Can you precompute embeddings and cache hot queries?
  • How will you handle duplicates and near-duplicates across editions?
  • What’s your ground truth for evaluation? Consider segment-level precision/recall and user satisfaction on completeness.
  • Any legal or licensing constraints on returning verbatim text from uploaded sources?

If you’re building beyond cookbooks, the same playbook applies to case law, research papers, SOPs, and technical manuals. The north star is the same: use IR to find candidates, segmentation to define what “complete” means, and LLMs only where they help classify — not compose. That’s how you deliver exact passages at scale without sacrificing fidelity.

Curious to see this run end-to-end? A minimal version can be prototyped in a weekend using hybrid search, a cross-encoder reranker, and a boundary snapper driven by simple heuristics. From there, add a small boundary model for robustness. When users stop pressing Ctrl+F and start trusting your results, you’ll know the pipeline is doing its job.

Recommended Resources

As an Amazon Associate, I earn from qualifying purchases.