I’ve been testing NotebookLM for a research project where I need to analyze a lot of technical whitepapers and internal reports (mostly as PDFs). While I love the idea of a source-grounded AI, I keep hitting a major snag: the performance degrades significantly once I upload a PDF over, say, 150 pages. The initial processing is slow (expected), but even asking questions against the processed doc feels laggy, sometimes taking 10-15 seconds for a response.
Has anyone else run into this? I'm trying to figure out if it's:
* A limitation in how NotebookLM chunks or indexes the PDF text.
* Something about the underlying model (Gemini) struggling with the context window.
* Just a current scalability issue with their architecture.
My typical workflow involves:
1. Uploading a 200-page technical PDF.
2. Asking it to "summarize the key methodologies in sections 3-5."
3. Then diving into specific queries about data tables or findings.
The first summary is usually okay speed-wise, but follow-up questions get slower. I've tried breaking the PDF into smaller chunks (sub-50 pages), which helps, but it defeats the purpose of having a single source of truth.
**Workarounds I'm exploring:**
* Using a separate script (Python with `PyPDF2`) to pre-chunk the PDF by chapter and create separate sources in NotebookLM.
* Extracting all text to a plain `.txt` file first to see if PDF parsing is the bottleneck.
For alternatives, I'm considering:
* **ChatGPT Advanced Data Analysis**: Can handle uploads, but it's not as purpose-built for source-grounded Q&A.
* **Claude Pro**: Better context window, but again, not the same notebook-style interface.
* **Local setups** with `LlamaIndex` + `GPT-4All`, though that's a heavier lift.
Has anyone found a better approach or a configuration tweak? I really want to like NotebookLM for this, but the latency is a real workflow killer when you're in a deep analysis session.
--diver
Data is the new oil - but it's usually crude.
Yeah, it's probably all three factors you listed, but the chunking/indexing is the main culprit. The laggy follow-ups are the giveaway - if it were just the model's context window, you'd see timeouts or refusals, not a steady slowdown.
I've had the same issue. For workarounds, I gave up on their native PDF handling and pre-process everything myself. Use `pdftotext` or `pymupdf` to extract text, clean it up with a script, then feed the plain text chunks in. You lose formatting, but the latency drops to a couple seconds.
NotebookLM's strength is the grounding, but their ingestion pipeline feels like an afterthought. For a real "single source," you might be better off with a local setup like `llama.cpp` and `chromadb`, though that's a whole other can of worms.
My sandbox is bigger than yours.