Making LLMs Efficient for Survey Cleaning: My Journey from Arrays to Choice Maps
Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
No comments yet. Be the first to comment.
I was building an AI pipeline to clean survey responses. The data structure was like this:
Sample Question:
{
"id": 3271,
"text": "How satisfied are you with our service?",
"choices": [
{ "id": 1, "label": "Very Satisfied" },
{ "id": 2, "label": "Neutral" },
{ "id": 3, "label": "Dissatisfied" }
]
}
Sample Response:
{
"responseId": 1001,
"responses": [
{ "questionId": 3271, "responses": "2" }
]
}
Simple na? The user selected 2, meaning "Neutral".
Now, when sending batches of survey responses to LLM for cleaning and fraud detection, I had a big question in mind: How to send questions and responses efficiently without wasting tokens and making model slow?
Initially, I thought - "Aree yaar, just send the full questions array and responses array. Simple."
So I was packing:
Full questions (with choices array)
Full responses (with choiceIds)
Every batch was sending the same choices again and again. Every user response needed LLM to read question choices, scan array, match choiceId.
Even a small survey was eating 2k-3k tokens easily just for system context!
Then I thought:
"What if instead of sending same data again and again, I somehow make the choice lookup easier for the model?"
Each question has choices: [{ id, label }] array.
Response uses choiceId.
LLM scans array to match.
Pros: Tiny initial payload.
Cons:
Model has to do O(n) array scanning.
Slow reasoning.
Wastes attention and tokens if survey grows.
(Imagine scanning 10 choices manually every time — uff..)
Instead of sending choiceId, I replace it with "Neutral", "Dissatisfied", etc.
Responses directly readable by model.
Pros: Fast LLM understanding.
Cons:
Response size doubles or triples.
Huge token waste.
Not good for 10k+ responses batch.
(At small scale ok, but at big scale — 🪦RIP tokens!)
{
"3271": {
"1": "Very Satisfied",
"2": "Neutral",
"3": "Dissatisfied"
}
}
Response stays as choiceId ("2").
LLM just does O(1) lookup using map.
Pros:
One-time small cost.
Fastest reasoning.
Smallest token usage long term.
Bulletproof at 100k, 1M responses scale.
Cons:
(But haan yaar... once done, clean and scalable!)
Survey Questions (choices array)
↓
Preprocess into Choice Map (one time)
↓
Store Choice Map in System Context
↓
Send Responses with choiceId only
↓
LLM does O(1) lookup from Map
↓
Efficient fraud detection and response validation
✅ Pucho advantages kya hai ?
No duplicate choices in every batch.
No ballooning of response size.
No array scanning overhead for LLM.
| Approach | Token Usage | LLM Speed | Scale Readiness |
| Choices as Array | Medium | Medium | Ok only for small surveys |
| Expanded Labels | High | Fast | Very costly at scale |
| Prebuilt Choice Map | Low | Fastest | Best for 100k+ responses |
Sometimes, small design decisions, like, whether to send a list vs a map, matter A LOT when you want to scale cleanly.
I learned this by thinking deeply from the angle of:
Token cost
LLM cognitive load
Real-world scaling for lakhs of survey responses
This idea is not only for surveys! It can be applied wherever structured choices are involved.
Some real examples:
Auto-grading MCQ exams at scale (education apps).
Screening candidate forms in HRTech startups.
Cleaning healthcare intake forms efficiently.
Processing ecommerce customer feedback forms cheaply.
Analyzing product satisfaction surveys in SaaS platforms.
Main benefits of using Maps in AI pipelines:
✅ Save massive tokens.
✅ Make LLM think faster.
✅ Scale to millions of records easily.
✅ Keep backend and API payloads clean and simple.
Thanks for reading! 🙏
If you're building AI pipelines like this, comment your thoughts and approaches.