I've been evaluating Humata for our internal documentation corpus, which is a mix of architecture decision records, runbooks, and vendor PDFs. We have about 500 documents to start with, so the batch upload feature is a critical requirement for us. I ran a test with a subset of 50 files (mix of .md, .txt, and .pdf) via the web interface's batch uploader.
Here's what I found regarding the upload process and context isolation:
**Batch Upload Mechanics:**
* The uploader accepted all files in a single drag-and-drop operation. It showed a queue with individual progress bars.
* There's no apparent API for this yet, which is a downside for automation. I had to do it manually through the UI.
* Processing time was linear; a 1GB batch took roughly 20 minutes. No failures, but the status feedback is minimal.
**Context Per Document - The Core Question:**
Yes, it does maintain separate context per document. This is verifiable when asking questions. If you ask a question that could be answered by content in multiple uploaded documents, the response will typically cite one specific source document and its relevant passages. I tested this with two contradictory configuration examples in separate runbooks.
Example test:
* Document A (`postgres-ha-setup.md`): Recommended `max_connections: 100`
* Document B (`legacy-postgres-guide.md`): Recommended `max_connections: 50`
When I asked "What should max_connections be set to?", the answer was framed as "According to [postgres-ha-setup.md], it should be 100" and did not conflate or average the two values. It seems to treat each document as an independent knowledge unit unless you explicitly ask a cross-document comparative question.
**A Major Caveat on "Separate Context":**
While queries seem to anchor to one document at a time, I am not convinced the underlying vector store or indexing is fully isolated. I asked a follow-up question referencing a term only defined in Document A, but while citing Document B. This suggests some potential blending at the embedding level, or perhaps the chunking strategy pulls in adjacent context during retrieval. It's not a pure, hard wall between documents.
**Open Questions/Pitfalls:**
* Is there a document count or total corpus size where this separation starts to degrade?
* What's the chunking strategy? If a document is split into multiple chunks, is the context preserved within that document's chunks better than across documents?
* How does batch upload handle versioning? If I upload `v2.md` of a runbook, does it supersede `v1.md` or are they now two separate, conflicting contexts?
The batch upload works for getting a large corpus in, and the per-document context is adequate for straightforward Q&A. However, for complex, cross-document technical analysis, I'd be cautious. I wouldn't rely on it to resolve nuanced differences across architecture records without very careful, manual querying.
Automate everything. Twice.
Your test on context isolation is a key finding. In my experience with similar platforms, that "one specific source document" behavior you observed can be a double-edged sword for operational queries. It's great for sourcing accuracy, but it can fragment answers to process-based questions that are naturally described across multiple runbooks. Have you tried a follow-up prompt specifically asking it to synthesize steps from Document A and Document B? That's where the true workflow fit gets tested.
The lack of an API for batch operations is a significant total cost of ownership concern you've identified. Manual uploads for a corpus of 500 documents is a one-time pain, but ongoing governance where you need to update or archive subsets of documents becomes a major operational drag. Did you get any sense from their documentation or support about an API roadmap?