RAG System

I built a RAG system. RAG stands for Retrieval-Augmented Generation, which is a fancy way of saying "the AI reads your actual documentation before answering." You upload game guides, FAQ pages, patch notes, wiki content, even code files, and the AI pulls from that material when responding to players. It doesn't hallucinate about features that don't exist because it's grounded in what you actually wrote.

The system works with multiple AI providers. Google Gemini, OpenAI, Claude. You pick based on what you want to spend and what quality you need. Cheaper models handle FAQ-type questions fine, and you route trickier conversations to more capable models.

I also added budget tracking after my first month of testing, when the API bill was more than I expected. You set a daily cap, get alerts at 80% and 100% usage, and can see what each conversation costs broken down by model.

After a while I realized I was answering messages but had no idea what the bigger patterns were. What topics come up most? What's the average response time? Am I actually getting fewer repeat questions since adding the AI?

This is where it gets interesting for the lean studio idea. If you're one person managing communities for multiple games, you can't read every conversation. But you can look at a report that says "40% of questions this week were about level 12 difficulty" and know exactly what to fix in the next patch. The data does the work that a community manager would normally do.

So I built reporting. Daily analytics, topic breakdowns, response time metrics, AI cost per model. Everything exports to CSV or JSON if you want to do your own analysis.

Then I brought on a part-time community manager and realized she could see and change everything, including AI settings and conversation deletions. I needed access control. So I built role-based permissions: Super Admin, Admin, Agent, and Viewer roles. Granular enough that the community manager can reply to chats and look at analytics but can't touch the AI configuration or delete conversations.

At some point I was running TeleChat on three different sites and managing them separately was annoying. This is exactly the scenario I was building toward: multiple games, one small team, one set of tools. Multi-site support lets one installation handle multiple websites or games, each with their own widget look, their own knowledge base scope, and their own Telegram bot routing. One dashboard, one Telegram, all your games.

The Knowledge Graph

This one surprised me. After uploading 30-something documents to the knowledge base, I had no good way to see how they related to each other. Which FAQ answers were saying the same thing? Which game mechanics were explained in multiple guides with slightly different wording?

I built a Knowledge Graph that automatically maps relationships between documents. It uses keyword extraction and optional LLM-powered entity recognition. It scores node importance with something like PageRank, detects topic clusters, and lets you search by concept.

Is this overkill for one game's FAQ page? Yes. But I was running multiple sites with overlapping documentation, and it turned out to be good at catching gaps and redundancies I wouldn't have noticed otherwise.

I built a Telegram-powered live chat widget because Intercom costs too much