Client Equity Research Platform

An analyst researching a company needs to find the relevant figures, compare reporting periods and collect evidence for a conclusion. This platform lets the analyst ask a question, receive an answer assembled from company documents and follow each reference back to the original passage. It brings the searching and evidence-gathering work into one research workflow.

The client was a US-based startup building a hedge fund equity analyst platform. The delivery window was six weeks, and the defining cost challenge was bringing a projected $120,000 document-processing iteration inside a $50,000 budget.

The resulting platform combined financial document retrieval with source-grounded answers and paragraph-level citations. Moving the parsing approach from LlamaParse to Mistral models reduced the equivalent iteration cost by 60%, to approximately $48,000, with a modest accuracy trade-off accepted for the initial release.

The problem behind the search box

An equity analyst rarely needs a plausible paragraph about a company. They need the right issuer, the right reporting period and evidence that supports a specific conclusion. A value without its currency, units or accounting context can be worse than no answer.

Consider an illustrative research question: “How did operating margin change, and what did management say caused it?” The required evidence might span two reporting periods, financial tables and an earnings-call explanation. Finding a passage containing the words “operating margin” does not complete that task.

The product therefore had two connected responsibilities: help the analyst locate and synthesize relevant material, and make verification practical. An answer had to lead back to the passage that supported it. Otherwise the analyst still had to search the original reports manually before trusting the output.

Constraints that shaped the delivery

The budget was for a parsing iteration. It was not the entire company’s funding, total project spend or ongoing operating cost. Keeping those quantities separate made the trade-off clear.

Our process: make the full evidence path work

1. Translate the analyst’s task into evidence requirements

Requirements work focused on the research outcome: what question the analyst was trying to answer, which documents could support it and how the analyst would verify the result. That connected the backend pipeline to the user interface from the start.

It also made failures concrete. The wrong issuer, the wrong period, a detached table header and a citation that opened the wrong location were distinct problems. They required different fixes even if all of them appeared to the user as an unreliable answer.

2. Connect ingestion, retrieval and inspection

We built around separate background ingestion and interactive retrieval paths. FastAPI provided service boundaries, Celery handled asynchronous work and Qdrant supplied the vector-search foundation. The UI completed the path by letting an analyst move from the answer to the relevant document passage.

The architecture kept expensive document processing outside the interactive request. It also made the boundaries between parsed text, retrieval passages, selected evidence and rendered sources visible enough to reason about independently.

3. Rework the component that made delivery unaffordable

LlamaParse provided a high-accuracy starting point, but the complete parsing iteration was estimated at approximately $120,000. That exceeded the available budget by $70,000 before considering another iteration.

We moved the parsing approach to Mistral models and assessed the quality trade-off in the context of the analyst’s evidence needs. A modest accuracy reduction was acceptable for the initial release. The equivalent cost fell to approximately $48,000, bringing the iteration within budget.

4. Complete the product with source inspection

We connected paragraph references to PDF, HTML and text viewers. Page navigation, scaling, text highlighting and bounding-box overlays made the evidence accessible from the answer itself.

This mattered because retrieval quality and verification effort are related but different. A correctly retrieved paragraph can still be frustrating to use if the analyst has to locate it again inside a long report.

The parsing decision, in numbers

The important result was feasibility: the client could pursue a complete parsing iteration within the available budget. These are equivalent estimates for the same document set, rather than a claim of $72,000 in recurring savings.

The narrow remaining headroom also explains why reprocessing matters. A parser choice affects more than the first successful run: retries, document changes and extraction corrections can consume the budget again. The broader technical series develops artifact reuse, selective reprocessing and parsing escalation as the next operational controls.

Architecture: documents became retrievable evidence

The platform had several connected layers:

The deeper series separates the delivered components from subsequent reference designs. For example, it develops stricter issuer, time and access constraints, bounded agentic research and current cloud deployment options. Those extensions should not be mistaken for measured capabilities of every path in the original six-week release.

Why financial chunking needed special treatment

The ingestion code exposed different chunkers for annual reports, 10-K and 10-Q filings, earnings calls, conference calls and proxy material. That was a useful architectural boundary because the documents organized evidence differently.

A table value depends on its row, column, unit and sometimes a footnote. An earnings-call answer depends on the question and speaker. A paragraph can be textually relevant while lacking the context needed to interpret it correctly.

The retrospective also identified an important implementation detail: one path used a 512-word target, while another used a 512-token target. The financial BGE model had a 512-token input limit. Equal-looking configuration values were therefore not equivalent budgets. The technical article develops tokenizer-aware validation to catch silent truncation before embedding.

This is a useful lesson from the work: a high-level “chunk → embed → search” diagram can conceal a representation mismatch that directly affects which evidence is retrievable.

Retrieval was a sequence of decisions

Financial BGE embeddings supplied domain-oriented representations, and the design combined dense and sparse retrieval before reranking. Metadata such as document type, sector and industry helped organize the search space. The cross-encoder then assessed candidate passages in relation to the query.

Each stage had a different responsibility. Candidate generation needed to recover the relevant evidence. Reranking needed to prioritize it. Context assembly needed to preserve enough supporting material for the answer. A better reranker could not recover a passage that never entered the candidate set.

For financial research, scope was equally important. Similar language from a different period or issuer could look compelling while answering the wrong question. The series develops that observation into a more explicit retrieval contract, with validated issuer identity, reporting periods, source availability and entitlements.

Citations were part of the engineering, not decoration

Paragraph-specific citations connected backend evidence to the analyst’s inspection workflow. The viewer supported PDF, HTML and text, including page navigation, scaling, bounding-box overlays and text highlighting.

The frontend used Next.js, React, TypeScript and Zustand, with PDF.js through react-pdf. For PDF inspection, source coordinates were transformed relative to page dimensions so the highlight could follow the rendered document’s scale.

That introduced a second kind of correctness. The answer could cite the right logical passage while the interface highlighted the wrong visual region. Parsing locations, page numbering, coordinate conventions and document rendering all had to agree for the inspection experience to be useful.

The technical series develops a stronger evidence contract with stable document versions, passage identities and source regions. It also explains the limitations of text matching and why a citation’s existence is separate from whether it actually supports the claim.

Quality, trade-offs and what the outcome means

The parsing decision accepted a modest reduction in accuracy to make the initial release affordable. No numerical accuracy score is attached to that historical trade-off because the public record does not contain a matched benchmark.

The relevant quality questions follow the evidence path: did parsing retain the necessary value and context; did retrieval recover it; did reranking retain it; did the answer use it correctly; and could the analyst inspect it? This breakdown helps avoid treating every problem as an LLM failure.

Likewise, one million documents describes the corpus, not a measured request rate or a claim that every document was equally retrievable. The 60% figure describes parsing economics, not a 60% reduction in total platform cost. Analyst time saved would require its own workflow study.

My contribution

As architect and lead, I worked across the customer-facing requirements and the implementation of the research product.

• Requirements and scope: connected analyst research needs to a complete six-week delivery path, including evidence inspection.
• Architecture: shaped the separation between ingestion, retrieval and the frontend experience, with Python services, background work and Qdrant.
• Parsing economics: worked through the LlamaParse-to-Mistral decision and the cost–accuracy trade-off that brought the iteration estimate within the $50,000 budget.
• Retrieval and evidence: contributed across document handling, retrieval and the connection between returned passages and supported answers.
• Source inspection: connected paragraph citations to the document-viewing experience so an analyst could verify the result.

The continuity across these areas was central to the engagement. A cheaper parser would not have solved the problem if it broke the evidence the analyst needed, and an accurate answer would still have been incomplete without usable source inspection.

Outcomes

The work delivered an equity research platform around 1M+ financial documents, paragraph-level citations and a parsing approach whose equivalent iteration estimate fell from $120,000 to approximately $48,000. It connected a large corpus to an analyst-facing product within the six-week delivery constraint.

The client subsequently raised further funding, with the product part of the company’s progress. The earlier $2 million describes the funding context during the engagement; it is not the amount of that later round.

The enduring lesson was to make the evidence chain and the economics agree. The product needed to be useful to an analyst, inspectable when it was uncertain and affordable enough for the company to keep improving.

Explore the engineering in depth

• Parsing economics: LlamaParse to Mistral
• Financial document chunking
• Hybrid retrieval and scope
• Paragraph citations and source inspection
• Evaluating the evidence chain
• The full fourteen-article financial RAG series