Starting Over, Smarter Building an AI Guide for Life in a New Country
Telegram bot and AI assistant for finding useful information in the local community groups for a newcomer in Valencia (Spain)
Problem statement
For many people, relocation is their choice, but not for Ukrainians. Millions of Ukrainians were forced to leave their home and move to other countries to safer places and start building their lives from scratch.
I was one of them. I'm Oleksii Bebych - AWS Ambassador, AWS Community Builder, and I moved to Spain in 2026 and have to build my life over again.
Moving to a new country sounds exciting. But very quickly, excitement turns into a long list of questions:
- How do I get the right documents?
- How do I find a doctor?
- How do I enrol my child in school?
- Where should I live?
- How does the tax system work?
And all of this happens while you are dealing with a new language, a different culture, unfamiliar laws and a lot of bureaucracy.
I faced exactly this problem after moving to Spain.
And I realised that the problem was not really the lack of information.
The information was actually everywhere.
There are government websites. There are dozens of Telegram groups. There is Google, Facebook, friends, schools, doctors and local communities. But the information is fragmented.
One useful answer might be hidden in a Telegram discussion from six months ago. Another one is on an official Spanish website. And sometimes those two sources even seem to contradict each other.
So the real problem becomes:
How do I turn all this scattered information into a single useful answer?
That led us to a very simple product idea.
What if, instead of searching through all of these sources, you could just ask?
Solution
This is Valencia Info Bot . The interface is intentionally simple. You open Telegram and ask the same question you would normally ask someone who has been living in Valencia for a few years.
For example:
“Where can I find a Russian-speaking doctor?”
Or:
“What school can I find for my five-year-old child?”
(English, Ukrainian and Russian languages are supported)
The important part is that the bot does not just send the question to an LLM and hope for a good answer. Behind this very simple interface lies a retrieval pipeline.
Let me first show you that pipeline at the highest level.
A question goes through four main stages.
First, we search our community knowledge base.
Then we rerank the results because a discussion can relate to a topic without actually answering the question.
Then, when necessary, we verify or enrich the information using fresh web sources.
And only then do we ask an LLM to produce the final answer.
So the LLM is not our database.
It is the final reasoning and presentation layer on top of the retrieved information.
The most interesting part for me was how we made thousands of Telegram discussions searchable in the first place.
We do not train an LLM on Telegram chats.
Instead, we use RAG — Retrieval-Augmented Generation.
We collect messages from local Telegram communities and reconstruct conversations into discussion threads.
Then BGE-M3 converts those discussions into embeddings — numerical representations of their meaning.
When a question arrives, we use two types of search.
Semantic search helps us find discussions with similar meaning, even when the wording is different.
Full-text search helps with exact terms such as TIE, EX-17 or specific school names.
We combine both signals in a hybrid search.
This gives us a relatively broad set of candidates.
Then a reranker asks a much more precise question:
“Does this discussion actually help answer this user’s question?”
Only the best discussions go into the final context. At that point, we have the AI pipeline.
But for this audience, there is another important question:
Where does all of this actually run?
From the AWS side, we deliberately separated the system into services.
The Telegram bot is just the interface.
The main application logic lives behind a FastAPI service.
PostgreSQL with pgvector stores the community knowledge and provides vector and full-text retrieval.
A separate models service runs BGE-M3 for local embeddings.
For generative tasks, we currently use OpenAI behind the OpenRouter.
For production reranking, we use JEV through OpenRouter.
And Perplexity provides fresh web research when we need to verify information that may have changed.
Everything is deployed as containerised workloads, with the infrastructure managed through Terraform.
What I like about this architecture is that the AI components are still just services with clear responsibilities.
It looks surprisingly similar to any other distributed application.
Of course, architecture diagrams are nice.
But eventually, there is only one question that really matters:
Are people actually using it?
This is still an early pilot. So I am not going to try to impress you with millions of users.
So far, about 100 people have used the bot and asked their questions.
But what is encouraging is what they are asking about.
- Healthcare
- Schools
- Immigration
- Housing
- Taxes
These are exactly the problems we originally wanted to help with. And 42% of the early users asked more than one question.
Behind those answers, we already have more than 350,000 community messages organised into around 55,000 discussion threads.
So at this stage, I see this less as proof of scale and more as early validation that the problem is real.
And those first users have already taught us something else:
Making an AI application work is very different from making it work well.
The first lesson is latency.
Our median response time is currently around 52 seconds, and the 95th percentile is around 83 seconds. For a conversational interface, that is simply too slow. And this happens because one question can trigger several operations: query rewriting, embeddings, retrieval, reranking, web research and multiple LLM calls.
The second lesson is retrieval coverage.
We already have around 55,000 discussion threads, but semantic embeddings currently cover only part of them. Full-text search still allows us to search the rest, but completing semantic coverage should improve retrieval quality.
The third lesson is retention.
Our dataset is still too small to draw strong conclusions, so we need to validate this with more users over a longer period.
And finally, trust.
For this type of product, giving an answer is not enough. Users need to understand where the information came from and whether it is still current. So better citations, feedback and continuous evaluation are important next steps.
One of my biggest lessons from this project is:
Building an AI application is still distributed systems engineering.
Models matter.
But so do latency, observability, fallbacks, data quality and user experience.
Conclusion
The best way for us to improve this product is not another architecture diagram.
It is more real users asking difficult questions.
We started with Valencia, because this is the community and the problem we know.
But the idea itself is not really about Valencia.
Any city or community has fragmented local knowledge that is difficult for newcomers to access.
So if you are here today, I would love you to try the bot.
Ask it something difficult.
Try to break it.
And if the answer is bad, please tell me.
For us, a bad answer with good feedback is probably more valuable than another perfect demo.
And maybe one of your ideas will become the next improvement we build.
Thank you.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article