Most people's first instinct with AI and tender documents is to paste the whole package into a chatbot and start asking questions. It works, for a while. Then the document gets long, the answers get vague, and the cost per question climbs in a way that doesn't show up until the invoice arrives.
A detailed technical breakdown of both approaches, tested side by side on a real construction drawing set, found the difference wasn't marginal — a 46 to 72x reduction in tokens used per question, with accuracy going up, not down.
The problem with feeding raw documents to AI
A tender package is often 100-200 pages of drawings, specs, BOQs, and clauses. Every time you ask the AI a question — "what's the reinforcement spec for footing F6?" — a naive setup re-reads the entire document to find the answer. On a large tender, that's roughly 100,000 tokens per question. Ask ten questions and you've burned through a million tokens for information that could have been answered from a page.
Beyond cost, this approach is also where accuracy quietly breaks down. Large documents dumped into a single context window make it easy for a model to lose track of which drawing a detail came from, or blend information from two similar-looking sections.
The alternative: index once, query cheaply
The fix isn't a smarter prompt. It's a different structure entirely — index the document once into an organized database, then query that database instead of the raw file.
The workflow has four steps:
- Split the package into individual pages or sections, so each piece is addressable on its own.
- Extract the underlying data — the text and reference tags embedded in the document, not just what's visually on the page.
- Build a structured database, organized by object, not by page number. Instead of "page 14, page 15, page 16," you get "all footings," "all slabs," "all pipe runs" — each entry citing exactly which drawing and section it came from.
- Query the database. Every question gets answered from the structured index first. The AI only goes back to the original document when something genuinely needs visual confirmation.
In that comparison, this brought each question down to roughly 1,400 tokens instead of 100,000+ — and because the database entries are structured and cited, cross-checking an answer against its source drawing takes seconds.
Why this matters for tendering specifically
Tender review is naturally repetitive: the same document gets queried dozens of times across pricing, technical review, and clarification requests. That repetition is exactly where the cost of the naive approach compounds — and exactly where the database approach pays for itself. The upfront cost of building the index is real (indexing is more expensive than a single raw query), but it's a one-time cost. Every question after the first one is where the savings show up.
There's a second, quieter benefit: the structured database becomes a real audit trail. When a number in your pricing needs to be traced back to its source clause or drawing, you're not scrolling through 150 pages — you're looking at a database entry that already cites exactly where it came from.
What this looks like in practice
You don't need custom software to do this. The core idea — index once into a structured, object-organized file, then query that instead of the raw document — works with general-purpose AI tools and a bit of upfront organization. The discipline that matters is resisting the shortcut of just pasting the whole thing in and hoping for the best.
If you're processing tender documents regularly, the database-first approach isn't a marginal optimization. It's the difference between AI-assisted review being genuinely usable at scale, or something that works for a five-minute demo and falls apart on a real 150-page package.