Türkçe
AI Assisted Development

AI Assisted Development: From Voice Assistants to MCP Chatbots

RAG, MCP and STT-LLM-TTS pipelines are now part of my regular toolkit.

· Full Stack Developer · Updated:

Getting a voice assistant to answer a question over the phone takes a few different pieces working together behind the scenes. An STT-LLM-TTS pipeline converts speech to text, sends that text to a language model, then converts the response back to speech. RAG, or Retrieval-Augmented Generation, means the model pulls relevant information from an external source before generating an answer, instead of relying purely on what it learned during training. MCP, the Model Context Protocol, gives an AI model a standard way to connect to outside services, databases or APIs.

I built this pipeline for a hotel reservation AI call assistant. A RAG-based knowledge base answers questions about the hotel, room types and availability, and the STT-LLM-TTS flow was tuned to keep latency low, because anyone talking on the phone notices a few seconds of dead air right away.

For an apartment management system, I built an MCP-based AI chatbot that talks to external services directly, so it answers from live data rather than a fixed dataset. Alongside Angular 20 work on admin panels, these kinds of components have become a regular part of what I build.

AI-assisted coding tools are in my daily workflow too now, they stopped being a separate topic and just became part of how the work gets done.

The mechanics behind RAG are fairly straightforward: source text gets converted into vectors by an embedding model, the user's question gets embedded the same way, and the chunks that are semantically closest get pulled from a vector store and inserted into the prompt as context before the LLM answers. Chunk size is one of the real decisions here, smaller chunks match more precisely but can leave out surrounding context, larger chunks preserve context but drag in irrelevant text that adds cost and latency. For the hotel assistant, keeping chunks small and narrow worked better for structured data like room types and availability, while policy text in free form needed wider chunks to stay coherent.

There's a common assumption that RAG eliminates hallucination, but it only raises the odds the model sees the right information, it can still ignore what retrieval handed it and answer from what it already 'knows,' or misread an irrelevant chunk as relevant. Giving a caller the wrong room rate or availability over the phone is a real problem, so the prompt needed explicit instructions to only answer from the retrieved context and say 'I don't know, let me transfer you' when nothing matched. RAG isn't the right call for everything either, if the rules are small and static, putting them straight into the system prompt is simpler and has fewer failure points than standing up a vector store and a retrieval pipeline.