LLMQuant / LLMQuant/quant-mind
PaperFlow verbatim-quote validation rejects faithful quotes due to PDF extraction artifacts (whitespace, ligatures, hyphenation, page numbers, chunk boundaries)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 3k
- Forks
- 484
- PR merge metrics
- No merged PRs in 30d
Description
Summary
_validate_research_draft in quantmind/flows/_paper_summary.py requires a research finding's quote to be an exact substring of the cited chunk's text (finding.quote not in chunk.text). With PDF-sourced papers, pymupdf's extracted text contains layout artifacts inside sentences, so a model that quotes the words faithfully — but normalizes layout — fails the check, and PaperFlow.build() raises ValueError: research finding quote is not present in its chunk.
We hit this repeatedly running PaperFlow on the repo's own example paper (arXiv 1706.03762v7) with a non-OpenAI model (kimi-k3 via the litellm path), at temperature 0 and 1. Every rejected quote we inspected was word-for-word present in the paper; none was fabricated.
Artifact classes observed (all real cases from 1706.03762v7)
- Line breaks / irregular indentation inside sentences — extracted text:
"permission to\nreproduce the tables and figures in this paper solely for use in journalistic or\n scholarly works."; the model quotes the sentence with single spaces. - Ligature glyphs — pymupdf emits
ff/fi(e.g.effective); models writeeffective. NFKC normalization folds these. - End-of-line hyphenation —
"English-\nto-German"(hyphen must be kept when joining) vs. cases where the hyphen should be dropped. Neither plain whitespace collapsing nor unconditional dehyphenation handles both. - Page numbers interleaved mid-sentence at page breaks —
"...faster than recurrent layers when the sequence\n6\n\nlength n is smaller than..."(the6is the page number). A faithful quote naturally omits it. - Chunk-boundary spans and near-miss chunk attribution — with
chunk_size=512, chunk_overlap=64, a faithful quote can cross the cited chunk's boundary, and models sometimes cite a neighboring chunk index within their group. The quote is verbatim in the material the agent was shown, but not within the single cited chunk.
Suggested direction
Keep the anti-fabrication guarantee (every quoted fragment must appear verbatim in the text the agent saw) but compare on a normalized form:
- NFKC-normalize + collapse whitespace runs on both sides before the substring test;
- try both hyphenation joins for end-of-line hyphens (
-\n→""and-\n→-); - strip standalone page-number lines;
- as a fallback, match against the overlap-deduplicated concatenation of the agent's chunk group (treating
chunk_index/page_numberas provenance hints rather than exact pointers), so boundary-spanning quotes pass.
We implemented exactly this as a local wrapper around _validate_research_draft and confirmed: (a) all previously rejected faithful quotes pass, (b) a deliberately fabricated quote is still rejected, and (c) PaperFlow then completes end-to-end on 1706.03762v7. Happy to turn it into a PR if the direction sounds right.
Environment
- quant-mind @
10e9dbd0(v0.2.0), editable install, Python 3.12.13 (aarch64 linux) - Model:
litellm/moonshot/kimi-k3(also reproduced with a local qwen3:14b vialitellm/ollama_chat/...) - Same behavior at
temperature=0.0and1.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in quantmind/flows/_paper_summary.py at _validate_research_draft and trace how PaperFlow.build() supplies chunks and provenance. Reproduce with arXiv 1706.03762v7, then cover the listed extraction artifacts and chunk-boundary cases while preserving rejection of fabricated quotes. Done means faithful quotes pass, fabricated quotes remain rejected, and the end-to-end PaperFlow run completes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100