AI search across 67,000 entries in a national culture archive

The client and the brief

The Magyar Popkulturális Értéktár is a digital collection of Hungarian popular music, literature, film and visual culture. No single organisation sits behind it. Zsuzsi Berta, marketing director of A38 Hajó, described it at the launch as carrying on the legacy of Bahia Kiadó, working with A38 Hajó, MTVA, Petőfi TV and the Artisjus rights organisation, and building on the music-history work of Béla Szilárd Jávorszky.

The brief is easy to state and hard to deliver: a search over the repository that answers real questions instead of returning a hit list. Project lead András Nyírő described the starting point at the launch. They had begun to think about how artificial intelligence could help find information more effectively across their enormous digital archive.

What made it hard

Two problems, neither of them a question of technology fashion.

The first is language. Nyírő said the thing out loud at the launch that every Hungarian-language AI project starts from: ChatGPT opened new possibilities, but the language model is built primarily on English and brings Anglo-Saxon culture with it, which raised the question of how they could show their own culture in that setting. A model tuned on English is not bad at Hungarian music history because it cannot speak Hungarian. It is bad because it does not know the material, and it fills the gap confidently.

The second is context. Berta pointed out that searching for a performer or a genre on the open web returns a tsunami of information ordered by someone else's engine, and that this is a clear loss of value for a national culture, because the hits arrive torn out of their original cultural setting. A search that hands back ten links does not help in that situation.

„Az értéktár esetében nem pusztán egy adatbázisban lehet keresni, hanem értelmes kérdésekre értelmes válaszokat kaphatunk.”

With the repository you are not merely querying a database, you can ask meaningful questions and get meaningful answers.

One thing the article does not mention, but which shaped the work throughout: in a cultural archive a wrong answer costs more than elsewhere. A webshop chatbot getting a delivery date wrong is annoying. A repository search attaching the wrong year or the wrong label to a performer will be quoted by somebody.

How a search like this is built

An honest dividing line belongs here. Everything above comes from the public source. What follows is a general engineering account of how an AI search over a large, heterogeneous corpus gets built. It is not documentation of the repository's implementation, which is not ours to publish.

1. 1. Ingestion and normalisation

   Entries, publication records, photo metadata and record data live in different schemas. The first step is always a shared internal shape where every item has an identifier, a type, a source and a timestamp. This stage looks dull and decides the fate of the project.

2. 2. Chunking

   A corpus of 67,000 items cannot be handed to a model whole. Text has to be cut into units that still stand on their own. For an artist profile that is usually a section boundary; for a record description, the item itself.

3. 3. Embeddings and index

   Each chunk gets a vector encoding its meaning and goes into a vector database. A conventional literal index runs alongside it. On Hungarian material the two together are markedly better than either alone: the vector side finds the paraphrased question, the lexical side finds the exact name form.

4. 4. Hungarian language handling

   Inflection, accent-free typing, stage names alongside legal names, bands that renamed themselves. A model does not solve this by itself. It needs lists and rules, and the lists need maintaining.

5. 5. Relevance and reranking

   Raw hits have to be ordered. This is where it emerges whether the user wants a release year or wants to know who played with whom in 1987. Those two questions need different results even though the words look alike.

6. 6. Grounded answer generation

   The model may only work from the retrieved chunks, and the answer has to carry which item it came from. Where there is no coverage, the correct answer is that there is no data. Demos tend to skip this part, and it is the part that matters in production.

Károly Nehéz, director of the Computing Institute at the University of Miskolc, who helped shape the repository's AI module, spoke at the launch about how the generative layer behaves. He explained that instead of the single optimal word the language model settles on, the system can also offer the second and third candidate, which is what makes the answer variable. That is sampling, and it is one reason the same question does not come back as word-for-word the same sentence twice.

„Ez is egy gép, de bonyolultabb minden eddiginél, amelyet az emberiség történelme során létrehozott.”

This too is a machine, only more complicated than any humanity has built before.

We wrote up the technical background in more depth in our article on RAG knowledge bases, and the agent side in AI agents fundamentals.

What we took away from it

A few things this work taught us that we now say on the first call of every knowledge-base project.

We talked about the scale of this kind of work at AI Summit Budapest 2025 as well, where our talk covered how we processed 100 GB of data and turned it into a working AI system.

Which organisations this suits

The pattern is the same everywhere: a large body of your own content, mixed formats, and a search that today runs on keywords.

Where the content is thin, or already sits in well-structured tables, a decent filtered search is cheaper and more precise. We say so on the scoping call before anyone pays for anything. The full service description lives on the AI development page, and further production projects are in the AI portfolio.