← Back to blog

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 "??? ? ??????", STT may output something like "?? ? ? ??????", and AI should correct it to "LogP ? ??????".

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 /[?-?]\s?[?-?]\s?[?-?]/ /(?|??|??|??)/ /(??|?|?|??|??)/

That meant normal conversation got sent to AI corrections.

I narrowed the triggers to likely technical term patterns.

javascript /[?-?]{2,}(?|?|?)/ /(??\s??|?????|???)/ /[A-Za-z]{2,}\d+/

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