Abisearch: vector search on Hungarian-language documents

Over the past years we ran into the same problem in several customer support and knowledge base projects: search does not find what the user is looking for, because they do not use the same words as the document. In Hungarian this is especially painful. Abisearch grew out of that experience: it is our own SaaS vector search API, available at abisearch.abigel.ai. In this post we describe the technical background and the decisions behind it.

Meaning instead of keywords

Traditional keyword search (an inverted index with BM25 ranking) works well when the search term and the document use the same word forms. A query for “comfortable running shoes” will not find a description of “lightweight trainers for jogging”, even though that is exactly what the user wants.

Vector search works on a different principle. An embedding model turns every piece of text into a numeric vector of several hundred dimensions, in such a way that texts with similar meanings end up close to each other. Search then compares vector distance rather than word matches. The model is multilingual, so a Hungarian question also finds an English document, and vice versa.

This does not fully replace keyword search: for identifiers, part numbers and exact phrases, matching still matters. So Abisearch works in hybrid mode: it complements the vector hits with keyword signals, and the final ordering comes from a combination of the two.

The difficulties of Hungarian

Hungarian is an agglutinative language: dozens of suffixes can attach to a single stem, and the forms “cipő”, “cipőt”, “cipőben”, “cipőjükkel” are four different words to a keyword system. Stemming helps in part, but it is often too aggressive or simply wrong, and compound words (“futócipő”, “edzőcipő”) are a problem of their own.

Multilingual embedding models are considerably better at this, because tokenisation is at the subword level and the model learned meaning rather than surface form. What we still had to handle in practice:

• long Hungarian sentences use more tokens than their English equivalents, so we set the chunking size per language,
• accented and unaccented spellings (“cipo” and “cipő”) require normalisation in the keyword branch,
• vectors for short, one- or two-word queries are “noisy”, so the keyword branch gets more weight for those.

The customer does not have to configure any of these rules; the API detects the language and works accordingly.

Upload and API

Our goal was to make it usable without any machine learning knowledge. So data ingestion accepts two formats: JSON (an array of records with arbitrary fields) and Excel spreadsheets (one record per row, one field per column). At upload time you specify which fields go into the searchable text and which stay as filterable metadata.

Search is a single REST endpoint: the request is a natural-language query plus optional filters, and the response is a list of hits with a relevance score and the original record. It can be called from cURL, Python, JavaScript or PHP exactly like any HTTP API. The API key goes in a header, and responses include the remaining quota.

Behind the scenes, chunking documents, computing embeddings and updating the index all happen asynchronously, in a queue, so that one large upload does not slow down other customers’ searches. This is the same multi-tenant pattern we wrote about earlier: per-tenant limits and queues on shared infrastructure.

Re-ranking

Vector distance on its own does not always give the best ordering: the right answer is often among the top twenty hits, but not necessarily first. So we offer an optional re-ranking step: a large language model (Gemini) re-evaluates the best candidates in the context of the query, and that determines the final order.

Re-ranking is slower and more expensive than the base search, so it can be switched on per request. It is worth enabling for knowledge bases and support articles; for quickly filtering a product catalogue the base result list is often enough.

Operations, data handling, pricing

Abisearch runs entirely in a data centre inside the European Union, and the uploaded data and indexes stay there too. Data handling follows GDPR; an uploaded data set can be deleted at any time, and deletion removes it from the index as well.

Pricing is usage-based: every account gets 100 requests a day for free, and above that we charge 0.001 euro per request. There is no monthly minimum and no package to buy up front. This is a deliberate decision: small projects (an internal document store, a webshop with a few hundred products) can try it at no cost, while larger ones pay for actual traffic.

If you try it at abisearch.abigel.ai and want to share any experience or report a bug, we are at info@procats.hu. Our next steps point towards voice-based systems, where search will be just one component of the conversation.