SentenceWindowNodeParser and AutoMergingRetriever, both one callSet expectations up front, something like: "if you already sat through Notebook 02, this one moves fast, you already know what each cell is trying to prove. Today's real question is LangChain or LlamaIndex, and when." Say it in your own words. It stops people expecting brand new theory that isn't coming.
PyPDFLoader(...) BSHTMLLoader(...) Docx2txtLoader(...) # one loader class per format
SimpleDirectoryReader( input_dir=DATA, required_exts=[".pdf",".html",".docx"], ).load_data() # one call, tags each node with its source file
Just run it live and let "loaded 3 document(s) from the folder" speak for itself, don't over-narrate it. Worth a quick mention of LlamaHub too, there are hundreds of connectors beyond local files (Notion, Slack, Google Drive). That's honestly LlamaIndex's biggest ingestion strength, give it ten seconds.
Don't re-run the whole reveal, just say it: "same table, same disaster if you grab the naive reader. Not re-teaching this, just confirming, it's a parser problem, not a LangChain problem or a LlamaIndex problem." Two minutes tops on this one, then move.
| # | Strategy | LlamaIndex | LangChain (Notebook 02) |
|---|---|---|---|
| 1 | Fixed / token | TokenTextSplitter | TokenTextSplitter |
| 2 | Sentence / recursive | SentenceSplitter | RecursiveCharacterTextSplitter |
| 3 | Semantic | SemanticSplitterNodeParser | SemanticChunker (experimental) |
| 4 | Sentence-window | SentenceWindowNodeParser ✓ one-liner | manual metadata window |
| 5 | Small-to-big | HierarchicalNodeParser + AutoMergingRetriever ✓ built-in | ParentDocumentRetriever |
| 6 | Doc-type-aware | MarkdownNodeParser, HTMLNodeParser | MarkdownHeaderTextSplitter, etc. |
Rows 4 and 5 are the ones worth slowing down for, point at them directly. Rows 1, 2, 3, and 6 are just "same idea, new class name," blow through those fast, nobody needs three minutes on TokenTextSplitter twice in one week.
MetadataReplacementPostProcessorPut yesterday's manual Document plus metadata-window code right next to today's SentenceWindowNodeParser.from_defaults(window_size=2, ...), same screen, same time. That line count is the whole lesson. Don't talk over it.
HierarchicalNodeParser builds parent/child nodes at multiple sizes. AutoMergingRetriever matches small leaves, and once enough leaves from the same parent get hit, it merges them up automatically.Run this cell with verbose=True live, let that log line print right there on the projector. Don't paraphrase it on a slide beforehand, it lands better cold. Watching the merge happen in the actual terminal beats any diagram I could draw.
Chains, agents, tool-calling, output parsing. Basically the flexible orchestration and generation side of things, Notebook 01's territory.
Multi-format loading, sentence-window, small-to-big. Data ingestion and the harder chunking and retrieval work.
Give them the honest answer: a lot of production stacks just use both. LlamaIndex for ingestion and retrieval, LangChain or LangGraph for orchestration on top of it. Nobody's picking one forever here.
| Time | Segment |
|---|---|
| 0–3 min | Frame it as Notebook 02's twin, set expectations for a faster pace |
| 3–8 min | SimpleDirectoryReader one-liner, then a quick parsing recap |
| 8–14 min | Strategies 1, 2, 3, 6 briskly, "same idea, new class name" |
| 14–24 min | Strategies 4 & 5 slowly: sentence-window one-liner, then the live auto-merge demo |
| 24–30 min | Framework decision table + hand off to Notebook 04 (embeddings) |
Notebook 04 picks up right here: embeddings, the geometry of meaning that makes semantic search possible in the first place.