← Back to blog
AIBug FixVORA

How I Fixed AI Over-correction

A small bugfix story from a meeting speech-to-text assistant app where AI was over-correcting too aggressively. What this app does The app converts spoken conversation into live text. Since STT frequently misrecognizes technical terms, AI auto-correc...

by Jay··2 min read·VORA B.LOG

Series: VORA B.LOG

  1. 1. Why I shipped VORA before writing a single line of backend code
  2. 2. From Python Server to Pure Browser: The Architecture Pivot That Changed Everything
  3. 3. The Whisper WASM Experiment: Why Browser AI Is Harder Than It Looks
  4. 4. Why We Killed Speaker Identification (And What We Learned from Two Weeks of Failure)
  5. 5. Building an N-Best Reranking Layer for Better Korean STT (Without Extra API Calls)
  6. 6. Building the Priority Queue: How We Stopped Gemini API Chaos — and Why the First Two Designs Both Failed
  7. 7. Groq Dual-AI Integration: Why We Added a Second AI and What It Actually Fixed
  8. 8. The Meeting Summary Timer Bug: Why setInterval Isn't Enough for Reliable Scheduling
  9. 9. Building a Real Meeting Export: From Raw Transcript to a Usable Report
  10. 10. The Dark Theme Redesign: Building a UI That Looks Like a Professional Tool (After It Looked Like a Hobbyist Project)
  11. 11. The Branding Journey: From a Functional Name to VORA
  12. 12. How We Made VORA Bilingual Without a Heavy Localization Stack
  13. 13. Deploying to Cloudflare Pages: Static Hosting, CORS Headers, and the Sitemap/Robots Incident
  14. 14. How I Fixed AI Over-correction ← you are here

A small bugfix story from a meeting speech-to-text assistant app where AI was over-correcting too aggressively.

What this app does

The app converts spoken conversation into live text. Since STT frequently misrecognizes technical terms, AI auto-corrects those parts afterward.

If someone says "Let's check the LogP value", STT may output something like "Let's check the log pee value", and AI should correct it to "Let's check the LogP value".

The problem: AI corrected too much

Even normal meeting lines were modified:

  • changes particles and word order
  • inserts technical terms that are not present
  • rewrites polite greetings and casual speech

The root cause was three things combined.

Cause 1: Prompt composition ran twice

The pipeline built a prompt in two steps and appended the same instruction twice, so the model became overly aggressive.

`javascript // Before: append to an already-prepared prompt let prompt = personaPrompt || defaultPrompt; if (this.meetingContext) { prompt += meetingContext; } if (this.priorityTerms) { prompt += priorityTerms; }

// After: use the prompt as-is when already complete if (personaPrompt) { return personaPrompt; } `

Cause 2: The filter was too broad

A Korean text trigger was matching almost every sentence.

javascript /[\uAC00-\uD7A3]\s?[\uAC00-\uD7A3]\s?[\uAC00-\uD7A3]/ // any 3 Korean syllables /(the|and|but|or)/ // common particles /(is|was|do|has|be)/ // common verbs

That meant normal conversation got sent to AI corrections.

I narrowed the triggers to likely technical term patterns.

javascript /[\uAC00-\uD7A3]{2,}(ase|ide|ine)/ // Korean + pharma suffix /(drug\s?name|compound|dosage)/ // domain-specific terms /[A-Za-z]{2,}\d+/ // alphanumeric identifiers like CYP3A4

Also, I skip AI correction for very short sentences.

Cause 3: Instructions were not explicit enough

"Correct only when sure" is ambiguous. So the model still changed uncertain fragments.

I made the rule explicit:

  1. Correct only technical terms.
  2. If uncertain, keep original text.
  3. Never change normal conversation (greetings, small talk, meeting flow).
  4. Do not change sentence structure, particles, or endings.

Results

  • normal greetings stay untouched
  • technical corrections still work (e.g. LogP)
  • fewer AI calls and faster response time

2026.02.24

← All posts