Document AI · Experimentation and evaluation
AI document insights
During my Pfizer externship, I investigated a practical question: how can someone find an answer in a collection of PDFs and check that it came from the right source? I worked through a document-question-answering pipeline, compared extraction and retrieval approaches, and examined where the answers went wrong, with AI assistance for code and documentation. The most useful findings came from tracing those failures back to the source documents.
- My work
- Experimentation, evaluation, and technical documentation
- Environment
- Python notebooks · Google Colab · Gradio
- Methods
- OCR · PDF parsing · Embeddings · Retrieval-augmented generation
- Status
- Historical experiment · not a production system
Overview
Finding a lot number or a test method in a PDF sounds straightforward until the files mix selectable text, scanned pages, and repeated document types. Reading the text is only the first step. The answer also has to refer to the document the person meant to ask about.
I broke the problem into extraction, retrieval, and answering so I could inspect what happened between a question and the final response. That made it possible to compare individual parts of the pipeline and check the evidence passed to the answer model.
Three cases shaped the conclusions: a reranker removed information the answer needed, a real value came from the wrong certificate, and an error in my answer key made the evaluation misleading. Together, they showed why a fluent answer and a high score both need closer examination.
A plausible answer is only useful if it comes from the intended source.
Approach
Separate extraction, retrieval, and answering
The final evaluation reads the PDF's digital text first and uses Tesseract OCR when a page has too little text. Extracted text is split into overlapping chunks, embedded with BGE-small, and stored in a LlamaIndex in-memory index. Retrieval selects context before Mistral generates the answer.
That separation matters when investigating an error. A missing field might originate in extraction. An incomplete answer might result from retrieval discarding a passage. A wrong identifier can still be a generation error even when the correct passage was found.
- 01
PDF text or OCR
- 02
Chunks and metadata
- 03
Embeddings and index
- 04
Retrieve context
- 05
Generate with sources
Each stage can fail differently. Check the extracted text and retrieved passages before attributing an error to the answer model.
Compare the parts before judging the whole
I compared Tesseract, PaddleOCR, and EasyOCR on one scanned certificate. I also compared MiniLM, E5, and BGE embeddings on one document and three queries. In the embedding comparison, the language model was disabled so I could examine the retrieved chunks directly instead of confusing retrieval quality with the model's writing.
A later experiment compared a baseline retriever, a similarity threshold, and cross-encoder reranking on the same query. These were small, targeted comparisons. They helped expose behavior worth investigating rather than establish a generally superior configuration.
Findings
Reading the fields was not the whole OCR problem
All three OCR engines captured the core fields on the tested certificate. What differed was how they grouped labels with values, handled the table, and covered the surrounding text. PaddleOCR kept a label and its value together; Tesseract captured more text and handled the table row.
The report records 220 words for Tesseract and 36 regions for PaddleOCR. Those are different units, so the counts are not a ranking of accuracy. The engines' confidence scores are also not a shared accuracy scale. The useful finding was a tradeoff between text coverage, grouping, and setup effort on that particular page.
I recommended combining extraction strategies because the tools handled different parts of this page well. Degraded scans and unfamiliar layouts would need their own tests before carrying that recommendation further.
| Engine | What the comparison recorded | Reported output |
|---|---|---|
| Tesseract | Broader text capture; table row read; labels and values split | 220 words reported |
| PaddleOCR | Label and value grouped; table row partial; more setup friction | 36 regions reported |
| EasyOCR | Core fields captured; fragmented grouping and table handling | 47 regions reported |
The more elaborate retriever lost useful context
The baseline answer included all four quality-control methods expected for the tested query. Adding the similarity threshold produced the same answer. Adding the reranker reduced five retrieved chunks to three, and the final answer omitted three of the four methods.
I would check answer completeness before keeping that extra stage. Retaining fewer passages looked cleaner, but in this one-query comparison it meant losing three expected methods. A broader test set would be needed to decide whether reranking helped overall.
5 chunks retained
4 of 4
5 chunks retained
4 of 4
3 chunks retained
1 of 4
Bars share a four-method denominator. This comparison describes one document and one query.
A correct value can belong to the wrong document
The evaluation PDF contains two certificates of the same type. A generic question about a lot number returned a real value from the wrong certificate. A source citation can therefore be genuine while the answer still addresses the wrong document.
That failure points to a requirement for the next version: establish which document the user means before returning a value. A document identifier, page range, or clarifying question could resolve the ambiguity. Filtering only by document type would leave the same problem.
Keep an unexplained model choice visible
MiniLM was fastest in the recorded embedding comparison, while the capstone and final evaluation used BGE-small. The reason for that change was not recorded. I can describe the discrepancy, but I cannot reconstruct a decision that was never documented.
A useful next experiment would compare the models against the final pipeline's own input and chunking settings. The earlier comparison used a different, narrowly scoped setup.
Evaluation
I checked the source PDF and wrote five questions with expected answers and page references. The final evaluation covered ten pages split into twenty-eight chunks. The figures below are reported historical results from that test, not a new run performed for this case study.
- Exact Match
- 100%
- On five questions, after correcting the answer key
- Recall@4
- 100%
- Expected evidence retrieved in the first four results
- Precision@4
- 45%
- Relevant context among the first four results
- MRR
- 0.87
- Reported mean reciprocal rank
These results describe this five-question test set after the answer-key correction. They do not establish accuracy on new documents or questions.
Check the answer key before changing the model
The first evaluation reported 80% Exact Match and 60% Recall. Investigating the apparent misses exposed a wrong page label and an ambiguous lot-number question in the manually prepared answer key. After correcting the key against the PDF, the reported scores were 100% and 100% on the same five-question test set.
The correction changed how the result was scored. It did not demonstrate an improvement to the model. Keeping that distinction visible is more informative than presenting the final percentages alone.
| Scoring reference | Exact Match | Recall |
|---|---|---|
| Initial answer key | 80% | 60% |
| Corrected answer key | 100% | 100% |
Finding the answer is different from selecting only useful context
Recall@4 was 100%, while Precision@4 was 45%. The expected evidence was found, but the selected context also contained substantial irrelevant material. A high recall result did not mean that retrieval was clean or efficient.
The reported average response time was about 292 seconds per query, compared with 88 milliseconds for retrieval. Those measurements describe different parts of the workflow. The response time was a practical limitation for interactive use, even on questions the pipeline answered correctly.
- Average response time
- 292 s
- Historical evaluation average
- Retrieval time
- 88 ms
- Reported retrieval measurement, not total response time
Reflection
The most consequential errors were easy to miss in the final answer. The wrong lot number existed in the source collection. The reranked answer sounded complete. The evaluation percentages looked precise even when the answer key needed correction. Inspecting the passages and source pages explained what those outputs concealed.
These findings give me specific checks for the next version. I would test document selection and answer completeness explicitly, keep retrieval timing separate from full response time, and record why a configuration changed. Each check follows a problem found in these experiments.
The public edition now provides fictional documents and a small offline reference demo. The remaining evaluation work is broader: test unfamiliar layouts, repeat the ambiguous-document case, and compare configurations on the same questions. The five-question result is a starting point for that work, not evidence of production reliability.
Deliverables
3 DELIVERABLESDeveloped during the Pfizer externship using guided learning resources and starter material. The public repository contains sanitized notebooks and a separate fictional-document reference demo. The results on this page come from the original experiments.