A Bilingual Knowledge Base That Answers Callers During a Major International Event

#The starting position

Major international sporting events bring huge numbers of visitors to a host city, many of them for the first time and many of them speaking little of the local language. They have questions about venues, schedules, transport, tickets, facilities and rules, and they want answers quickly. Organizers provide information lines staffed by contact centre operators to handle those questions.

The contact centre operator in this engagement provided that multilingual support for a major international multi-sport event. Its operators answered visitors in Japanese and English. The information they needed existed, spread across reference documents covering venues, schedules and services, and it changed as the event approached and while it ran.

The pressure on operators was constant. A visitor would ask a question, often in English, and the operator would search reference material while keeping the caller on the line. Some answers existed only in Japanese documents. Some questions had no documented answer at all. Every search took time, and inconsistent answers between operators were a real risk in a public-facing service where many visitors ask the same thing.

The operator wanted a knowledge base that would put the right approved answer in front of an operator while the caller was still speaking, in either language, and that would get better as the event went on.

#What we built

01 A bilingual knowledge base of approved answers

At the core is a knowledge base of approved questions and answers in English and Japanese. Content is approved by the operator's team, and the system answers only from that content. In public-facing event support, a confident wrong answer does more harm than a short pause, so grounding every suggestion in approved material was a requirement from the start.

02 Live suggestions during the call

As a call progresses, the knowledge base suggests relevant answers to the operator. The operator does not have to stop listening to start searching, because likely answers appear while the visitor is still describing what they need.

03 Manual search

When the operator wants to look something up directly, or the suggestions are not quite right, they can search the knowledge base themselves.

04 Cross-language matching with translated embeddings

Approved content is converted into embeddings, including translated embeddings, so meaning can be matched across languages. A visitor's question asked in English can retrieve an answer that was written in Japanese, and the other way round. The team does not have to maintain two complete sets of content for the system to work in both languages.

05 Operator content management

Operators and content managers maintain the knowledge base themselves through content management screens. They can add, edit and approve answers as information changes, which during an event can be daily.

06 Missing-question tracking

Every question the knowledge base could not answer is recorded. The missing-question log shows content managers exactly where the gaps are and which unanswered questions come up most often, so new content is written where callers actually need it.

#How it works during the event

A visitor calls and asks, in English, how to get from their hotel area to a particular venue on the day of an event. While they are still speaking, the knowledge base suggests the approved answer about transport to that venue, drawn from content originally written in Japanese. The operator reads it, confirms the details with the caller and answers in English.

Later, several visitors ask about something nobody anticipated, such as a newly announced change at one venue. The knowledge base has no answer, so each question is logged. By the afternoon, the content team sees the cluster of missing questions, writes and approves an answer, and publishes it. The next operator who receives the question sees the approved answer suggested immediately.

#Why grounding and gaps matter more than clever AI

It is easy to imagine an AI that simply answers any question about an event from general knowledge. For a public information service, that would be the wrong design. General knowledge goes out of date, varies from what organizers have announced and cannot be held accountable. Answers given to thousands of visitors need to be consistent and approved.

That is why the knowledge base answers only from approved content, and why missing-question tracking matters as much as the search itself. The system's job is to make approved knowledge instantly findable in either language, and to show the team precisely where approved knowledge is missing. The AI provides speed and cross-language reach. The operator's team provides the authority.

#The architecture

The knowledge base is a web application used by operators in the browser. Approved content is stored in a database and converted into embeddings for vector search, including translated embeddings for cross-language retrieval. Language models are used within narrow limits, to match and present approved content, not to invent answers. Content management screens, approval steps and the missing-question log sit around the search, and they are what make the system maintainable by the operator's team during a live event.

The same architecture underpins the operator's other production AI systems, including live call transcription and emergency form extraction, which shortened delivery and gave the team one familiar way of working.

#What operators and managers can see

The knowledge base serves two audiences with different needs, and each has its own view.

Operators see the call in front of them: suggested answers for the question being asked, the ability to search, and the full approved answer with any details they need to read to the caller. The screen is designed to be glanced at while listening, so the most likely answer is the most visible.

Content managers see the knowledge base as a whole: which answers exist in which language, and the missing-question log showing where callers asked something the knowledge base could not answer. That view turns content work into a clear daily task list during the event.

Keeping these views separate matters. Operators should never have to think about content structure while a visitor is waiting, and content managers need the overview that no single call provides.

#How we delivered it, end to end

Start from the operator's question. The design began with what an operator needs in the seconds after a visitor asks something, which led to live suggestions instead of a search page alone.

Approved content as a rule. Grounding every suggestion in approved material was set as a requirement before any model work began.

Cross-language from the start. Translated embeddings were part of the design so the team would not need to maintain duplicate content sets.

Content ownership with the client. Content management and approval were built for the operator's team, so they control what the system says.

Gaps treated as data. Missing-question tracking was built in, turning every unanswered question into a content task.

#The decisions that mattered

Suggest, do not answer. Keeping the operator between the AI and the caller protected accuracy and accountability.

One knowledge base, two languages. Cross-language retrieval avoided the cost and drift of maintaining two parallel content sets.

Log what is missing. The missing-question log made the knowledge base improve during the event instead of after it.

#What changed

#What we would tell an event or contact centre team considering this

Decide first that your AI will answer only from content you approve, then make that content findable in every language your callers speak. Put the content in your own team's hands, and treat every question you cannot answer as the next piece of content to write. Done that way, a knowledge base becomes more useful every day the event runs, which is exactly when it matters most.