Skip to content
Notifications
Clear all

Am I the only one who thinks the accuracy drops significantly after ~500 pages per chat?

7 Posts
7 Users
0 Reactions
2 Views
(@crm_hopper_2027)
Reputable Member
Joined: 2 months ago
Posts: 133
Topic starter   [#9538]

Alright, gather 'round the digital campfire. I’ve been running Humata through its paces for the past three months, using it to digest everything from legacy sales playbooks to technical integration docs for a migration project. The initial glow-up was real—for the first 500 pages or so in a given chat, it felt like a revelation. Pinpoint citations, decent synthesis, the whole promise.

But then, the wheels start to wobble. I've replicated this across three separate, massive document sets now. Once you push past that roughly 500-page threshold within a single chat session, the model's grip on the material seems to degrade in a very specific, frustrating way.

It’s not that it becomes useless. It’s that the accuracy and relevance of its responses become… speculative. The tell-tale signs I’ve documented:

* **Citation Confidence Plummets:** It starts citing pages with an almost heroic disregard for context. You'll ask a hyper-specific question about, say, "the SLA terms for the Enterprise API," and it will cite a page from a marketing brochure that merely mentions the word "Enterprise" in a header. The link is there, but the substance is a mirage.
* **Hallucination of Structure:** In one instance, after feeding it 600+ pages of a CRM's internal data schema, it began confidently inventing field names and object relationships that simply did not exist in the source material. It wasn't paraphrasing poorly; it was constructing entirely new entities, presented as fact.
* **The "Summarize Everything" Dodge:** When you ask a complex, connective question that requires understanding disparate sections, it increasingly defaults to a generic, high-level summary of the *entire* document set, rather than performing the analytical heavy lifting it managed earlier in the chat.

This feels like a hard limit in the context window management, or perhaps a cost-optimization step that prioritizes speed over depth once a certain token count is breached. I’ve tried the classic tricks—breaking into multiple chats, using more explicit prompts—but that defeats the purpose of having a single, continuous conversation with your entire corpus.

I’m curious if this is a documented limitation they quietly acknowledge, or just the inevitable entropy of current architectures. For comparison, I’ve seen similar drop-offs in other platforms, but usually at a much higher page count. For a tool marketed at large document analysis, a 500-page ceiling per conversation feels… quaint. Is my experience an outlier, or has anyone else hit this invisible wall and started drafting their migration plan to the next promising beta?



   
Quote
(@carolp)
Estimable Member
Joined: 1 week ago
Posts: 89
 

Nailed it. That "heroic disregard for context" is exactly right. I hit the same wall.

My workaround is to treat each chat like a disposable Terraform module. I chunk the doc set into logical units (e.g., network specs, IAM policies, compliance docs) and keep each chat under 300 pages. It's more manual, but the signal-to-noise ratio stays usable.

The model seems to prioritize token proximity over semantic meaning past a certain density.


—cp


   
ReplyQuote
(@david_chen_data)
Estimable Member
Joined: 3 months ago
Posts: 129
 

The chunking-as-Terraform-module analogy is accurate. I've been running similar experiments and the decay isn't linear either. It's more like a cliff after the first 300-400 pages of active context. What I've found is that the model's attention mechanism seems to collapse into a "recency-weighted" state where it anchors on the last 50 pages of tokens and treats everything earlier as a vague prior.

One thing I'd add to your approach: be careful about chunking too finely. If each chat is under 100 pages, you lose the cross-referencing ability that makes these tools useful for integration work. I've seen teams split a network topology doc into three chats and then get contradictory answers about which subnet the load balancer lives in. The model can't "see" the other chat.

My current threshold is 250 pages with a 20% overlap between sessions if I need to chain them. Even then, I'm manually verifying every citation past the 200-page mark. The time savings are still real, but the quality ceiling is lower than I'd like.

Have you tested whether the degradation is uniform across document types, or does it hit harder with dense technical specs vs. narrative prose?


data is the product


   
ReplyQuote
(@bookworm)
Estimable Member
Joined: 1 week ago
Posts: 72
 

Your documentation of the citation confidence drop is consistent with what I've observed in internal benchmarks. The model starts to rely on keyword salience rather than true document understanding.

The hallucination of structure is the critical failure mode. Past the context limit, I've seen it invent entire sections - like a "Data Retention Policy" appendix that doesn't exist - and then cite plausible but fictional page ranges. It's not just being wrong; it's constructing a false internal representation of the document corpus.

This suggests the degradation isn't just about attention. It's about the model's ability to maintain a coherent, indexed map of the source material. Once that map breaks down, it defaults to statistical pattern matching, which produces those superficial keyword-based citations.


prove it with data


   
ReplyQuote
(@cloud_sec_enthusiast)
Estimable Member
Joined: 2 months ago
Posts: 90
 

You've hit on the core issue - it's not just a performance drop, it's a context overload. That citation drift you described is spot on.

This reminds me of finding overly permissive IAM roles in a massive cloud deployment. You can see the policy statement that *should* be granting access, but because the role has 100 other statements, its actual effective permissions are completely unpredictable. The system can't hold it all together coherently.

Chunking helps, like others said, but you lose cross-reference integrity. Have you tried using a persistent, external index (like a vector store) for the main corpus and then only feeding the model dense, relevant snippets for each query? It's more setup, but it bypasses the chat's native context limit.


security by default


   
ReplyQuote
(@bench_beast)
Reputable Member
Joined: 1 month ago
Posts: 231
 

Agreed on the hallucination of structure. I've seen the same pattern in my own tests with technical RFCs. It doesn't just invent sections, it starts citing them with a confidence that makes the errors harder to spot.

Your point about the model defaulting to statistical pattern matching is key. The citations aren't random - they're pulled from a degraded internal map that's lost its spatial accuracy. It's like the model is navigating by a low-res thumbnail of the document.


Benchmarks don't lie.


   
ReplyQuote
(@annaw)
Estimable Member
Joined: 1 week ago
Posts: 96
 

> "Hallucination of Structure"

Yes, this is the one that gets me. I've seen it inventing a "Product Roadmap 2025" section in a doc that was purely a pricing sheet from 2023. The weird part is the citations looked legit at first glance - right page range, plausible font. But when I checked, that page was actually a table of contents.

I think the issue isn't just raw page count but also document diversity. If you feed it 500 pages of pure sales playbooks (similar structure, repeating terms), the degradation seems faster than if you mix in different formats. Like the model gets bored and starts pattern-matching on the fly instead of indexing. Have you noticed any difference in how it handles homogenous vs. varied document sets?



   
ReplyQuote