{"id":482,"date":"2025-09-11T22:41:07","date_gmt":"2025-09-11T22:41:07","guid":{"rendered":"https:\/\/fin.ai\/research\/?p=482"},"modified":"2025-09-12T09:39:01","modified_gmt":"2025-09-12T09:39:01","slug":"building-a-better-language-detection-model-for-fin","status":"publish","type":"post","link":"https:\/\/fin.ai\/research\/building-a-better-language-detection-model-for-fin\/","title":{"rendered":"Building a Better Language Detection Model for Fin"},"content":{"rendered":"\n

When users ask Fin some question, they expect Fin to respond in the same language in which they ask the question. Detecting the language a user is speaking is a key step in the Fin pipeline. If we detect the wrong language, Fin might respond in a language the user doesn’t understand – leading to a poor (and often frustrating) experience. In this blog, we look at why language detection is tricky, why it needs to be better, and how we’re solving it.<\/p>\n\n\n\n

Why do we need language detection?\u00a0<\/h2>\n\n\n\n

On the surface, the problem looks simple: Fin needs to reply in the same language the user is using. <\/strong>Can\u2019t we just do prompt engineering, like below?<\/p>\n\n\n\n

You are customer support agent. You need to answer customer's question. Reply in the language they asked the question.\n\nHistory:\nFin: Hey There, How can I help you?\nCustomer: Hey, im need help.\n\n...\n\nReply:\n(Fin generates a reply in the user\u2019s language)<\/code><\/pre>\n\n\n\n
But here’s the catch: while large language models can reply in virtually<\/em> any<\/em> language, most Fin customers have human agents who speak only a few. That means Fin can only support a few languages per customer<\/em>. Basically, customers want control over the languages that Fin responds in (they want the ability to constrain it to only languages that they give it permission to).<\/p>\n\n\n\n
Consider a hypothetical setup of Fin by AlpNet Communications, a telecom operator based in Switzerland. They’ve set English as the default language for their Fin workspace and enabled support for German, French, and Italian (the country’s official languages). So far, so good: if a customer writes in French, Fin replies in French; if they use Italian, Fin responds in Italian.<\/p>\n\n\n\n
But what happens when someone messages in Dutch? Technically, Fin can reply in Dutch, but it shouldn’t, as the customer has “prevented” it from happening. AlpNet doesn\u2019t support that language, and chances are, their agents can\u2019t either. This is where fallback logic comes.<\/p>\n\n\n\n
First, Fin checks whether the user’s language is supported. If it\u2019s not, it looks at the user\u2019s browser locale. If the locale is also unsupported, say it\u2019s Dutch, Fin falls back to English, the workspace\u2019s default.<\/p>\n\n\n\n
You could<\/em> try to encode all that logic directly into a single prompt, but that quickly gets messy. A better approach is to handle the decision-making upstream and keep the prompt simple. This upstream logic itself can be handled by a separate LLM call, like below<\/p>\n\n\n\n
Determine the language the user is writing in this message: \n\nUser: Hey, im need help.\n\nAI: <detected_language><\/code><\/pre>\n\n\n\n
That helps, but extra LLM calls slows things down, and we want Fin to be fast. What if we use lighter models, trained for just one job: detecting language?<\/p>\n\n\n\n
How do we do language detection?<\/h2>\n\n\n\n
We used FastText<\/a> in production to detect the language. FastText\u2026<\/p>\n\n\n\n