PART 1 OF 14 · 7 MIN READ · ARUNANK SHARAN · 2 OCTOBER 2025

A million documents, six weeks, and a $50,000 constraint

A hedge fund analyst rarely starts the day thinking about vector databases. There is a company to understand, an earnings release to interpret, or an investment thesis to challenge. The difficult part is finding the right evidence, checking that it describes the right period, and deciding whether it changes the view of the business.

The client’s platform was built for this workflow: a hedge fund equity analyst platform, developed for a US-based startup, with RAG over more than one million financial documents. The work discussed here took place in 2025. The startup had $2 million in funding, the delivery window was six weeks, and the budget for one complete parsing iteration was $50,000.

The first high-accuracy approach, using LlamaParse, put that iteration at approximately $120,000. Before any discussion about the best embedding model, there was a commercial problem: the proposed ingestion approach exceeded the iteration budget by $70,000.

This series follows the decisions that connected those two realities—the analyst’s need for dependable evidence and the startup’s need for a product that could actually be delivered.

Start with the person using the answer

The end user was the equity analyst. That distinction matters. A general question-answering demo can stop after producing a plausible paragraph. An analyst has to inspect it, compare it with another source, and carry the evidence into a research note or a discussion with a portfolio manager.

Consider three representative research requests:

• “What caused the change in operating margin, and was it recurring?” The answer needs the financial table, management’s explanation, and the distinction between a reported fact and an interpretation.
• “Did management change its language about demand between the last two earnings calls?” This requires the correct calls, comparable speaker passages, and evidence from both periods.
• “How much debt matures next year?” This requires the maturity schedule, currency and scale, reporting date, and relevant footnotes. A nearby number in the wrong column is a wrong answer.

These are worked examples of the workflow, with a fictional issuer used throughout the series. They make the system requirements concrete without relying on a reader’s familiarity with a particular company.

The analyst’s workflow also explains why paragraph-level citations became part of the product. A link to a 150-page filing still leaves the analyst with a search problem. The answer needs to open the document at the supporting passage and make that passage visible.

Convert the workflow into an acceptance contract

Requirements collection should produce observable behaviour. “Accurate financial RAG” is too broad to guide a six-week build. A more useful contract connects each research task with the evidence required to finish it.

This is the level at which architecture decisions become useful. A parser is valuable because it preserves row-to-column relationships. A retrieval filter is valuable because it stops a newer filing entering an earlier-period comparison. A viewer is valuable because it lowers the cost of checking the answer.

A compact task contract can travel with an evaluation case:

{
  "task_id": "margin-change-01",
  "issuer_id": "example-co",
  "question": "Why did operating margin change in FY2024?",
  "required_evidence": [
    "FY2024 operating income and revenue",
    "FY2023 comparable operating income and revenue",
    "management explanation for the change"
  ],
  "answer_requirements": [
    "show period and units",
    "cite each material factual claim",
    "separate calculation from management commentary"
  ],
  "completion": "answer_with_support_or_state_missing_evidence"
}

The contract is deliberately independent of the LLM provider. It remains useful if the parser, embedding model or generation model changes.

The architecture follows the evidence

The implementation was organised around ingestion and retrieval services, with a document viewer for inspecting evidence. FastAPI exposed the service boundaries; asynchronous ingestion used Celery; embeddings and retrieval used Qdrant; the UI used Next.js, React and TypeScript.

There are two clocks in this architecture. The ingestion clock measures how quickly a document becomes searchable. The interactive clock measures how quickly an analyst receives a supported answer. A large ingestion job should not occupy the resources required to answer a query about documents that have already been indexed.

A third clock is easy to miss: verification time. An answer that streams immediately but takes several minutes to check may be less useful than a slower answer with precise, usable citations. This is why the viewer belongs in the system design rather than being treated as a final UI task.

The constraint that changed the parser decision

The LlamaParse path delivered high parsing accuracy. It also produced a projected cost that did not fit the client’s budget. Moving to Mistral models reduced the parsing cost by 60% for the same complete document set, bringing the estimate to approximately $48,000.

The arithmetic is straightforward:

Original estimate                 $120,000
Reduction                         $120,000 × 60% = $72,000
Revised equivalent iteration      $120,000 × 40% = $48,000
Budget remaining                  $50,000 − $48,000 = $2,000

There was a small loss in parsing accuracy. The resulting quality was acceptable for an initial release. This was a delivery decision about a specific corpus and workflow, not a claim that Mistral was universally better than LlamaParse.

It also did not create a large reserve. The $2,000 difference was only 4% of the parsing budget. Uncontrolled retries or repeatedly parsing unchanged documents could consume it quickly. The economics therefore lead directly to engineering requirements: persist parsing outputs, version the configuration, identify failed pages and rerun only the work that needs to change.

Six weeks changes the order of work

A six-week deadline rewards a narrow, complete path through the system. The critical sequence is to establish what the analyst needs, demonstrate representative evidence retrieval, connect the answer to the viewer, and then validate that cost and quality remain acceptable as coverage grows.

The following is the delivery structure I would use to organise this work; it is a planning model, rather than a reconstructed weekly diary:

The point is to keep the customer involved in decisions that change the product. A discussion about whether a table can be flattened is also a discussion about whether a debt-maturity question can be answered reliably.

What this series adds to the case study

The historical delivery established the product story: million-document financial RAG, usable citations, and a parser change that made the iteration affordable. The client subsequently went on to raise further funding, with the product part of that progress.

The following articles unpack the implementation and develop the design further. The 2026 designs—including the bounded agentic research loop, expanded evaluation contracts and deployment patterns—are presented where they extend the earlier system. Current provider capabilities are dated so that the original trade-off remains understandable.

The end-to-end question throughout is the same: can the analyst get to a defensible answer, and can the startup afford to keep producing it?

My contribution

My contribution spanned customer requirements, system architecture and implementation: turning the analyst workflow into a concrete product, connecting ingestion and retrieval with source inspection, and working through the parsing cost–accuracy trade-off within the six-week delivery constraint.