We skipped LangChain for the chunking layer in our patent ingestion pipeline and wrote our own splitter instead. I think that was the right call. Here's my reasoning.

LangChain's text splitters do one thing well: take a blob of unstructured text and cut it into token-sized pieces with some overlap between them, using a cascade of separators, paragraphs first, then sentences, then raw characters if it has to. For a lot of RAG pipelines that's genuinely the right tool. The question wasn't whether LangChain is good. It's whether our problem was the kind of problem it's built for.

It isn't, and the more I looked at what our chunker actually had to do, the clearer that got. Patent documents aren't generic text. They have real structure, and a generic splitter has no way to know about any of it:

  • Grant Red Book descriptions have section headings like TECHNICAL FIELD, BACKGROUND, and SUMMARY, and you can only find them by pattern, short, all caps, no period at the end.
  • Claims split most naturally on semicolons, because that's the convention patent attorneys use to separate limitations, not because semicolons mean anything special in normal English.
  • Every chunk pulled from a claim has to carry claim number, claim type, and dependency straight through from the parser. You can't re-derive that from the text later.

None of that lives inside a generic splitter. If we'd adopted LangChain, we'd still have had to write all of this on top of it. The dependency wouldn't have saved us the work, it would have just sat underneath work we were doing anyway.

The thing that really settled it for me was the split between stored text and embedding text. We persist the exact, non-overlapping chunk, but we generate its embedding from that chunk plus a little borrowed context, trailing tokens from the chunk before it, leading tokens from the one after. That borrowed context gets thrown away once the vector's computed. LangChain doesn't have a concept of "store one version, embed a slightly different one." We'd have had to build that ourselves no matter what splitting library sat underneath it, so bringing one in wouldn't have bought us much.

I don't think this is an argument against LangChain generally. If you're handling a bunch of different document types with loosely defined splitting rules, or you want to plug into its retriever and vector store ecosystem, that's when it's worth using. That's just not what we're doing. We have one document format, one spec-driven algorithm, and a direct line into Elasticsearch.

The splitting logic itself ended up being maybe sixty lines. The actual complexity, heading detection, clause boundaries, the stored versus embedding split, was specific to patents no matter what we built it on top of. So we just wrote the sixty lines. They're easy to read, easy to trace when something looks wrong, and we didn't have to learn someone else's abstraction to get there. That's usually the right trade when the problem in front of you is narrower than the framework built to solve it.

← Back to Articles