TL;DR
Parallel decomposition with index addressing is a structured data extraction technique that splits a complex task into specialized subtasks and uses numbered lines instead of generating text. The researchers demonstrated it on resumes, but the principle works for any document: customer emails, contracts, reviews, articles.
LLMs handle "extract everything at once" tasks poorly — they lose focus, mix up fields and generate inaccuracies. The biggest pain point: content drift when extracting long descriptions. Instead of an exact quote, the model produces a paraphrase or adds stuff of its own. The reason: when a model generates 100+ tokens, the chance of drifting away from the source grows with every token. Another problem: when you need 15 different fields (name, phone, address, education, experience...), the model gets confused — it skips some fields and duplicates others.
The method solves both problems at once. Parallel prompts — instead of one "extract everything" request, you make 3-4 narrow ones: "extract only the basic info," "extract only education," "extract only work experience." Each prompt focuses on 3-5 fields of a single type and doesn't lose concentration. Index addressing — for long fields the model doesn't retell the text, it returns line numbers like "description in lines 15-25," and you pull the exact text from the source yourself. Zero drift, 100% quote accuracy.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: Number every line of the source text
→ [0]: first line
→ [1]: second line
→ [N]: last line
STEP 2: Run parallel prompts (in separate chats or one after another in the same chat)
→ Prompt A: extract category 1 (e.g., basic info)
→ Prompt B: extract category 2 (e.g., financial data)
→ Prompt C: extract category 3 (e.g., the core question)
STEP 3: For indexed fields, pull the exact text from the source by line number
→ The model returned "lines 15-25"
→ You copy lines [15]-[25] from the source
→ You get an exact quote with no paraphrasingExample in Practice
Task: You're an editor at a personal-finance publication (think NerdWallet or Business Insider) and you've received a long reader letter asking for advice on their situation. You need to quickly extract structured data: basic info about the person, the details of their situation, and the core question without distortion.
Prompt:
Here is a reader letter with numbered lines:
[0]: Hi! I'm 28 and I live in Austin.
[1]: I work as a marketer and take home $5,500 a month.
[2]: A year ago I took out a $350,000 mortgage at 7%; the payment is $2,300 a month.
[3]: I also have a car loan — $18,000 left, I pay $450 a month.
[4]: I have $15,000 in a high-yield savings account at 4.5% APY.
[5]: Right now I'm thinking about paying off the car loan early to lighten the load.
[6]: But on the other hand, maybe it's smarter to put that money into a CD?
[7]: I've also been thinking about a Roth IRA, but I don't really understand it.
[8]: What would you recommend? Thanks!
TASK 1: Extract the basic info as JSON:
{
"age": "",
"city": "",
"income": ""
}
TASK 2: Extract the financial situation as JSON:
{
"debts": [{"type": "", "amount": "", "payment": ""}],
"assets": [{"type": "", "amount": ""}]
}
TASK 3: Extract the core question as JSON:
{
"question_lines": "range of lines where the question is described, e.g.: 5-7",
"question_summary": "the gist in one sentence"
}
For long fields return only line numbers; don't retell the text.
If a field is missing, return an empty string "".Result:
The model outputs 3 structured JSON blocks:
- Task 1:
{"age": "28", "city": "Austin", "income": "5500"} - Task 2: An array of 2 debts (mortgage $350k, car $18k) and 1 asset (high-yield savings $15k)
- Task 3:
{"question_lines": "5-7", "question_summary": "choosing between paying off the car loan early and putting the money into a CD"}
Then you open the source, copy lines [5]-[7] and get the reader's exact wording of the question with no paraphrasing: "Right now I'm thinking about paying off the car loan early to lighten the load. But on the other hand, maybe it's smarter to put that money into a CD? I've also been thinking about a Roth IRA, but I don't really understand it."
Why It Works
An LLM is good at deciding WHAT to extract but bad at COPYING long text verbatim. When a model generates a 100+ token description, it inevitably starts paraphrasing, simplifying or adding its own spin. That's not a bug, it's how generation works: each next token is produced based on the previous ones, and the longer the chain, the higher the chance of semantic drift from the source.
Index addressing plays to the LLM's strength — understanding the structure of text. The model is excellent at determining "the job description is in lines 15-25"; that's a classification/span detection task. But it does NOT try to retell that description — that's a generation task with a high risk of error. You pull the exact text from the source yourself, sidestepping the generation problem entirely.
Parallel prompts work because each prompt is as narrow and specialized as possible. Instead of an overloaded request like "find 15 different fields: name, phone, address, company, title, dates, job description..." the model gets simple tasks: "find only 3 fields: name, phone, email" → "find only the 4 education fields" → "find only the line range with the description." No context overload; every task is crystal clear.
Control knobs:
- Number of subtasks — more prompts = higher accuracy, but slower. For simple data you can merge 2-3 categories into one prompt. Cut down to 2 subtasks to save time; go up to 5-6 for maximum accuracy on complex documents.
- Indexing granularity — you can number lines (fine-grained), paragraphs (for long texts) or sections (for very long documents like contracts). Pick the granularity to fit the task: a customer email → lines, a book → chapters.
- Index format — you can ask for "lines 15-25" (universal), "paragraph 3" (for structured texts), or even "from word X to word Y" (for pinpointing inside long paragraphs). Use whatever is easiest to process afterward.
- Validation rules in the prompt — add checks like: "if the company name isn't found in the given lines → return null". This cuts off hallucinations at the generation stage.
Prompt Template
Here is a {document_type} with numbered lines:
[0]: {text of line 0}
[1]: {text of line 1}
...
[N]: {text of line N}
TASK 1: Extract {category_1} as JSON:
{
"{field_1_1}": "",
"{field_1_2}": "",
"{field_1_3}": ""
}
TASK 2: Extract {category_2} as JSON:
{
"{field_2_1}": "",
"{field_2_2}": "",
"{long_field}_lines": "range of lines, e.g.: 10-15"
}
TASK 3: Extract {category_3} as JSON:
{
"{field_3_1}": "",
"{field_3_2}_lines": "range of lines"
}
RULES:
- For short fields (name, date, amount) return the value directly
- For long fields (description, text of a question) return ONLY line numbers
- If a field is missing, return an empty string ""
- Don't add fields that aren't in the schemaPlaceholders:
{document_type}— customer email, contract, review, article, resume{category_N}— a group of related fields: basic info, finances, education, question{field_N_M}— a specific field to extract (name, age, company, title){long_field}— fields that need an exact quote (project description, question text, review)
🚀 Quick start — paste into the chat:
Here is a template for parallel extraction with indexes. Adapt it to my task: [describe the task — e.g., "extract structured data from customer product reviews"].
Ask me questions to fill in the fields.
[paste the template above]The LLM will ask which data categories you need (basic customer info? purchase details? review text?) and which fields go in each category — because different documents call for different structures. It will take the pattern from the template (line numbering + parallel JSON tasks + indexes for long fields) and adapt it to your specific case.
Limitations
⚠️ Short texts: For documents under 10-15 lines, indexing is overkill — it's easier to extract everything in one request. The method is built for long texts (50+ line resumes, customer emails, contracts).
⚠️ Simple data: If you need 2-3 fields of one type (e.g., just name and email), you don't need parallel prompts. One request is enough.
⚠️ Regular patterns: Dates, emails, phone numbers, amounts — LLMs already extract these well without indexes. Index addressing pays off specifically for long, irregular text: project descriptions, reviews, the wording of questions.
⚠️ Text preparation: The method requires numbering the lines first. For one email that's no problem (a minute by hand). For a stream of documents you'll need automation or a script.
How They Tested It
A team from Alibaba Group tested the system on real HR tasks. They built two datasets: 3,000 synthetic resumes with different layouts (single-column vs. multi-column) and 13,100 real resumes from Alibaba's HR system — messy ones, with custom fonts, mixed Chinese-English content and images.
They compared a fine-tuned compact model, Qwen-0.6B (600 million parameters), against top LLMs: Claude-4, GPT-4o, Gemini-2.5. They measured extraction accuracy (precision, recall, F1) for each field type separately: Period (dates), Named Entity (company and university names), Long Text (job descriptions). They also tracked latency — the time to process one resume.
The main finding: After training on 59,500 examples, the fine-tuned Qwen-0.6B beat Claude-4 on accuracy (F1: 0.964 vs 0.959 on the RealResume dataset) while running 3-4x faster (1.54 sec vs 4.62 sec per resume). The jump was especially big on Long Text fields — from F1=0.136 to F1=0.846, almost 6x.
The surprise: a naive baseline (Claude-4 directly on OCR text without layout parsing) scored F1=0.919, while their full pipeline with layout-aware preprocessing raised it to F1=0.959 — +40 points. This proves that structured text preparation is critical for quality, even with top LLMs.
The system is deployed in production on Alibaba's HR platform, processing 240-300 resumes per minute (4-5 QPS) with 1.54 sec latency. That's industrial scale, not a lab experiment.
Resources
Layout-Aware Parsing Meets Efficient LLMs: A Unified, Scalable Framework for Resume Information Extraction and Evaluation — research by Alibaba Group, Zhejiang Lab, Ant Group, Northeastern University. Authors: Fanwei Zhu, Yuxue Zhang, Jinke Yu, Junhao Ji, Zulong Chen, Ying Zhou, Haoyuan Hu, Zhibo Yang, Zhenghao Liu.