After our team migrated a massive archive of legacy contracts to a new vendor portal, we learned a hard lesson: automated extraction tools like ChatPDF are incredibly useful, but you can't fully trust them without a verification step. We had a few close calls where subtle but critical clauses were misrepresented.
To mitigate this risk, I built a simple Python script that cross-chexes ChatPDF's answers against the actual source PDF text. It doesn't rely on perfect OCR; it just checks if the key phrases and terms from the answer genuinely appear in the document's raw text. This has been invaluable for our compliance audits.
Here's the core workflow my script automates:
* **Input:** You provide the PDF file path and paste the ChatPDF answer.
* **Processing:** It extracts text from the PDF (using `PyPDF2` for simplicity) and preprocesses both the source text and the answer (lowercases, removes punctuation).
* **Verification:** It checks for the presence of significant nouns/terms from the answer within the source text. It ignores common stop words.
* **Output:** It generates a report showing:
* A confidence score (percentage of key terms found).
* A list of any claimed "key terms" not found in the source.
* The relevant source text snippets for verification.
For example, if ChatPDF claims a contract includes a "liquidated damages clause of 15%," the script will flag it if "liquidated damages" and "15%" do not co-occur in the actual PDF. It's caught several instances where ChatPDF confidently conflated details from different document sections.
This isn't a silver bullet for hallucinations, but it adds a crucial, repeatable checkpoint. It's especially helpful when dealing with large document batches where manual spot-checking is impossible. I'm happy to share the core logic if anyone is building similar safeguards into their workflow.
- h
Data is sacred.
Oh, this is rich. So after ChatPDF gives you a wrong answer, you need a second script to verify if the first script's work is correct? That's not a solution, that's a symptom of the problem.
You're checking if "key phrases" appear in the raw text, but what if ChatPDF hallucinates a *logical connection* that your script can't catch? For instance, it correctly pulls "Party A" and "liable" and "force majeure" from the text, but then tells you Party A is liable under force majeure when the clause actually says the opposite. Your verification score would be high, but the answer is dangerously wrong.
You've just automated the process of looking for the words, not the meaning. I'm curious if your compliance team knows they're just getting a glorified keyword matcher.
cg
Your point about logical connection hallucination is valid and gets to the core limitation of any keyword-based verification. This is precisely why the script should be viewed as a first-pass filter, not a semantic validator.
A practical next step would be to extend the script to also check for negation phrases around the matched terms. For a simple implementation, you could have a list of negation triggers, like "not liable" or "exempt from", and then examine a window of text around each matched key term from the ChatPDF answer. The report could then flag potential contradictions.
In complex contracts, even that isn't sufficient, but it would elevate the check from a pure keyword matcher to a basic contextual scanner. The real goal is to reduce the manual review load to only those answers that pass the initial term check but might contain inverted logic, which is a smaller subset.
null
That's a smart approach! I've seen similar needs in our gitops flows where we auto-generate K8s manifests from docs. One thing I'd add: consider using `pdfplumber` instead of `PyPDF2` for extraction, it handles tables and formatting way better, which can be critical for contract data.
Have you thought about adding this as a pre-commit hook or a GitHub Action? You could run it automatically when PDFs are added to a repo, then attach the verification report to a pull request. That'd make your compliance audit trail part of the code review process. 😄
git push and pray