Get AI summaries of any video or article — Sign up free
Master PDF Chat with LangChain - Your essential guide to queries on documents thumbnail

Master PDF Chat with LangChain - Your essential guide to queries on documents

Sam Witteveen·
5 min read

Based on Sam Witteveen's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Long PDFs require retrieval because prompt context windows are finite; chunking and semantic search prevent irrelevant or missing evidence.

Briefing

Building a “chat with your PDF” system hinges on one practical fix: plain prompting can’t reliably handle long books because the context window is finite. The solution is retrieval—turning the PDF into a searchable semantic index so questions pull in only the most relevant passages before the language model tries to answer.

The workflow starts by loading a PDF (Reid Hoffman’s book on GPT-4 and AI, available as a free PDF) and converting it into text. Because a model can’t ingest hundreds of thousands of characters at once, the text is split into overlapping chunks. In the example, the chunk size is set to 1,000 characters with a 200-character overlap, producing 448 chunk-sized “mini documents.” The overlap matters: key information often straddles boundaries, so sliding windows reduce the chance that a question’s answer gets cut in half.

Next comes embeddings and a vector store. Each chunk is embedded into a high-dimensional vector using OpenAI embeddings (specifically the model text embedding ADA 0 0 2). Those vectors are stored in a FAISS in-memory index, which functions like a database for semantic search. When a user asks a question—such as “How does GPT-4 change social media?”—the question itself is embedded and compared against the chunk vectors using similarity matching. The vector store returns the closest chunks (by default, four), and those retrieved passages are then fed into a language-model chain along with the user’s question.

The chain setup demonstrates how answers depend on retrieval quality and how many chunks are included. A basic “stuff” approach stuffs the retrieved context into a single prompt, which works as long as the combined text stays within the model’s context limit. When the system retrieves too little, answers can miss details. For instance, asking “Who are the authors of the book?” returns Reid Hoffman correctly but incorrectly omits GPT-4 as a co-author—an error attributed to the model’s interpretation of “authors” and the retrieved context. A separate test with an unrelated query (“Has it rained this week?”) yields “not specified,” illustrating the intended behavior when relevant passages aren’t found.

To manage context limits, the transcript contrasts chain types. Increasing K (the number of retrieved documents) can trigger context-length errors (the example cites a maximum context length around 4,097 tokens). Alternatives include “map-reduce”-style chains such as map-rerank, which run the language model on multiple retrieved chunks and then merge results using scores. Another option is retrieval QA, which wraps the retriever and question-answering logic together and can return both the final answer and the source documents.

Finally, the system is stress-tested with questions that should be answerable from the book’s table-of-contents chapters (e.g., what GPT-4 means for creativity) and with a nonsense query (“Beagle Bard”). The nonsense question is used to show that when the term isn’t present in retrieved context, the system should not confidently invent an answer. The takeaway is a production-minded checklist: chunking strategy, embedding model, vector store retrieval settings (like top-k), and chain type all determine whether the language model gets the right evidence to respond accurately.

Cornell Notes

A reliable “chat with a PDF” system avoids stuffing an entire document into a prompt by using retrieval. The PDF is loaded, split into overlapping character chunks (example: 1,000 characters with 200 overlap), and each chunk is embedded into vectors using OpenAI embeddings (text embedding ADA 0 0 2). Those vectors are stored in a FAISS index so similarity search can return the most relevant chunks for a given question. LangChain chains then combine the retrieved context with the question—using approaches like “stuff” (single prompt) or retrieval QA (retriever + answering)—to produce answers and, when configured, source documents. Retrieval quality and top-k settings strongly affect accuracy and context-length errors.

Why can’t a long PDF be handled by simply putting it into a prompt, and what replaces that approach?

A model’s prompt budget is finite (the transcript cites limits like 4,000 tokens, or up to ~8,000 with GPT-4). A book-sized document won’t fit cleanly, so answers become unreliable. The replacement is retrieval: chunk the document, embed chunks into vectors, store them in a vector store, and fetch only the most relevant chunks for each question before calling the language model.

How do chunk size and overlap affect retrieval performance?

Chunk size controls how much text each embedding represents; overlap reduces boundary loss when key information spans adjacent sections. The example uses 1,000-character chunks with a 200-character overlap, producing 448 chunks. The overlap means some sentences appear in multiple chunks, so semantic search is more likely to retrieve the chunk containing the full answer.

What role do embeddings and the vector store play in answering questions?

Embeddings convert each chunk into a high-dimensional vector that captures semantic meaning. The vector store (FAISS in-memory in the example) supports similarity matching: embed the user’s question, compare it to chunk vectors, and return the closest chunks. Those retrieved chunks become the context the language model uses to answer.

What is the practical impact of the “top-k” (K) retrieval setting?

K determines how many retrieved chunks get stuffed into the language model context. Too small can miss the exact passage needed for the answer; too large can exceed the model’s context window. The transcript notes that increasing K (e.g., to 20) can cause a context-length error, citing a maximum context length around 4,097 tokens.

How do chain types like “stuff” and map-rerank differ in handling retrieved context?

“Stuff” merges retrieved documents into one prompt call, which is cheaper but limited by context length. Map-rerank runs the language model separately on multiple retrieved chunks (e.g., 10 queries/chunks), returns intermediate answers with scores, then merges the best results. This can reduce context pressure while still leveraging multiple passages.

How can you tell whether errors come from retrieval or from the language model?

The transcript recommends inspecting what the vector store returns when answers are wrong or when errors occur. If retrieved chunks don’t contain the needed facts, the language model can’t answer correctly. If retrieval looks relevant but the answer is still off, the issue may be in the chain/prompting logic or model reasoning.

Review Questions

  1. If a question’s answer is missing, what two components should be checked first: chunking/retrieval settings or the language-model chain type? Why?
  2. How would you adjust chunk overlap and top-k to balance recall against context-length limits?
  3. What observable behavior would indicate that a question is out of scope for the retrieved PDF content?

Key Points

  1. 1

    Long PDFs require retrieval because prompt context windows are finite; chunking and semantic search prevent irrelevant or missing evidence.

  2. 2

    Split documents into overlapping chunks so answers that cross boundaries aren’t lost (example: 1,000-character chunks with 200 overlap).

  3. 3

    Embed each chunk into vectors (example uses OpenAI embeddings with text embedding ADA 0 0 2) and store them in a vector store such as FAISS for similarity search.

  4. 4

    For each question, embed the query, retrieve the top-k most similar chunks, and pass those chunks as context to a LangChain QA chain.

  5. 5

    Tune K carefully: too low can miss the right passage; too high can trigger context-length errors (example cites ~4,097 token max).

  6. 6

    Choose chain types based on constraints: “stuff” is simple and cheaper, while map-rerank can score and merge multiple chunk-level answers.

  7. 7

    In production, debug by inspecting retrieved chunks first to determine whether failures stem from retrieval quality or from the language-model step.

Highlights

The core fix for “chat with a PDF” is retrieval: embed chunks, store them in a vector index, and fetch relevant passages before answering.
Chunk overlap is not optional in practice—sliding windows (e.g., 200-character overlap) help capture answers that span chunk boundaries.
Increasing top-k improves recall but can break context limits; the transcript flags errors when K becomes too large.
Chain choice matters: “stuff” works when retrieved context fits, while map-rerank uses per-chunk calls and scoring to merge results.
A nonsense query like “Beagle Bard” is used as a sanity check: if the term isn’t in retrieved context, the system should avoid confident invention.

Topics

Mentioned

  • Reid Hoffman
  • GPT-4
  • LLM
  • FAISS