# retrieval-augmented-gen Published articles for retrieval-augmented-gen. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From Zero to Hero: Localization-Led Generative AI at Udemy DevFeed: [From Zero to Hero: Localization-Led Generative AI at Udemy]() Original publisher: [Read original article]() Author: Nishanth Gandhidoss Published: 2025-09-22T17:47:18Z Content type: article Language: en Sources: [Udemy Engineering]() Topics: [Localization (l10n)](), [Generative AI](), [Large Language Model](), [datasets]() Tags: [ai](), [features](), [generative-ai](), [generative-ai-tools](), [implementation](), [llm](), [llm-applications](), [machine-learning](), [machine-translation](), [retrieval-augmented-gen](), [techniques](), [translation]() ### AI overview Udemy describes how it localized generative AI features, including Skills Mapping and its in-course AI Assistant, to serve learners in multiple languages. The article compares translation management systems, multilingual LLMs, and hybrid strategies, emphasizing trade-offs among implementation speed, language coverage, fluency, cultural nuance, and domain precision. ### Source excerpt By Nishanth Gandhidoss, Senior Staff Data Scientist @ Udemy Why Multilingual Generative AI Matters Generative AI is rapidly changing how people learn and work, but those gains are only realized when the technology speaks the user's language. Over the past year at Udemy, we prioritized breaking the English-only barrier so our Gen AI features, most critically Skills Mapping and the in-course AI Assistant, could deliver value for learners across the globe. Our approach balanced speed, coverage, and quality, allowing us to move quickly without sacrificing fidelity in markets where nuance matters. Below we describe the localization strategy we adopted, why we made those trade-offs, and the operational practices that made the rollout repeatable, scalable, and quick. Localization Strategies When deciding how to localize a Gen AI product, it is helpful to think of options on a spectrum from low to high complexity. The simplest approach provides broad language coverage fast, while the most involved approach optimizes for fluency, cultural nuance, and domain precision. At Udemy, we researched and organized our work around three primary strategies: a translation management system (TMS) for rapid implementation with broader coverage, a multilingual LLM system (MLS) for high-fidelity experiences, and a hybrid approach to balance reach and quality. As each strategy is introduced below, we briefly explain the industry-standard localization techniques they draw on, with examples, so the differences are clear. Translation Management System (TMS) At the simplest end of the spectrum, we have the TMS approach. With a TMS, the user interacts in their own language, but the AI model itself operates in English input/output. The system first detects the user's input language, say, in Spanish, and sends the input through a machine translation (MT) service that converts it into English. The LLM then generates an English response, and that response is translated back into the user's input lang ## Building an LLM-Powered Slackbot DevFeed: [Building an LLM-Powered Slackbot]() Original publisher: [Read original article]() Author: Christian Monaghan Published: 2024-12-13T17:32:12Z Content type: tutorial Language: en Sources: [Benchling]() Topics: [Large Language Model](), [Retrieval Augmented Generation (RAG)](), [Slack](), [Terraform](), [Amazon Bedrock](), [cloud-infrastructure](), [Self-hosted]() Tags: [amazon-bedrock](), [building](), [infrastructure](), [knowledge-base](), [large-language-models](), [llm](), [rag](), [retrieval-augmented-gen](), [self-hosted](), [slackbot](), [terraform]() ### AI overview Benchling describes building an internal Slackbot that uses Retrieval-Augmented Generation and Amazon Bedrock to help engineers find answers to Terraform Cloud questions from sources including Slack, Confluence, and the web. ### Source excerpt Background At Benchling we run cloud infrastructure across several regions and environments. To coordinate and manage this complexity, our team operates a self-hosted implementation of Terraform Cloud, managing around 160,000 terraform resources across five data centers. About 50 engineers from across the engineering org release some form of infrastructure change within a given month -- some are infrastructure specialists, and others are application engineers who are completely new to Terraform Cloud. Understandably, we get a lot of questions about how to use Terraform Cloud or how to debug a specific issue, and that forum is usually in Slack. We have a glorious 20-page FAQ in Confluence that answers most questions, supplemented by numerous Slack threads documenting previous problems and their eventual solutions. So we have good documentation, but finding it is a pain. Who wants to read through a 20-page FAQ? Or go Slack spelunking to find that answer 40 messages deep into a thread? We set out to solve this problem by building a Slackbot that could dynamically answer any user question without doing any tedious searching. To accomplish this we implemented a Retrieval-Augmentated Generation (RAG) Large Language Model (LLM). Here's the story of how we did it and what we learned along the way. What we built We built an internal Slackbot that enables Benchling engineers to interact with a knowledge base to answer common Terraform Cloud questions. It also serves as a reference implementation for future LLM-powered tools at Benchling. It demonstrates how we can combine disparate information sources, both internal and public (web, Slack, Confluence), with the latest Large Language Models to expose this to the user through a familiar Slack interface. This pattern can be reused to develop Slack assistants for other specialized knowledge areas such as answering HR questions, surfacing past solutions to customer issues, or explaining software error codes. Here's what the interfa