Context
Ask attendees why they paid for a conference and most say "the people". Yet the networking feature in most event apps is a directory you search by name, which only helps if you already know who to look for. We wanted the Eventify app to say: here are a handful of people worth meeting, and here is why. The feature now ships as AI matchmaking across the platform described in the Eventify platform study.
The challenge
- Cold start. Many profiles have a name, a job title and two interest tags. The engine must do something sensible with little.
- Popularity bias. A naive similarity ranking sends everyone to the same twenty well-known speakers and investors, who then ignore all of the requests.
- Reciprocity. A good suggestion is someone who would also want to meet you.
- Truthful reasons. "You both work in fintech" is useful if true and damaging if invented.
- Privacy and consent. Opt-in, visibility settings and deletion with the event.
- Cost. Thousands of attendees, recomputed as profiles change, without a large model call per pair.
What we built
The engine has three stages, each using the cheapest technique that does the job.
- Retrieve. A profile text is composed from interests, role, company, bookmarked sessions, exhibitor categories and the optional goal. It is embedded and stored in a vector index inside the event's tenant scope: pgvector for most deployments, Milvus for very large ones. For each attendee we pull a wide set of nearest neighbours as candidates.
- Score. Plain rules re-rank the candidates: overlap of declared interests, role complementarity such as buyer and seller or mentor and mentee, an estimate of reciprocity from the candidate's own profile, availability of meeting slots, exclusion of colleagues from the same company, and a cap on how many times any one person can be suggested across the event.
- Explain. A language model writes one or two sentences on why to meet, given only the overlapping fields that both people have made visible. A template sentence is used as a fallback when the model is unavailable or when a validator rejects the output.
Suggestions appear in the app with a one-tap meeting request. Accept and decline responses feed back into the scoring for the rest of the event.
Architecture
Key decisions
1. Hybrid, not "ask the model to pick"
Handing the whole attendee list to a language model and asking for matches is expensive, slow, non-deterministic and impossible to explain to an organiser. Vectors are good at recall and rules are good at policy, so each does its own job. The model never sees the ranking problem.
2. The model writes the reason, never the rank
The explanation prompt receives only the fields that both profiles share and have made visible. A validator checks that every claim in the sentence maps to one of those fields; if it does not, the template sentence is shown instead. This is the same grounding discipline we apply in knowledge base work.
3. Exposure caps and diversity
Without a cap, similarity ranking concentrates requests on a few popular people. The scoring stage limits how often anyone is suggested and spreads suggestions across roles and companies. Popular attendees get a manageable inbox; everyone else gets suggestions that might actually reply.
4. Recompute cheaply and often
Embeddings are recomputed when a profile changes; candidate sets are rebuilt nightly and at the start of the event; scoring runs on demand because it is cheap. The expensive part, the explanation, is generated once per suggestion and cached.
5. Opt-in and scoped
Attendees opt in, control what is visible, and can hide from matchmaking without leaving the directory. Vectors sit in the event's tenant scope and are deleted with the event. See AI data privacy for how we handle the same questions in client systems.
6. Evaluate offline before online
We hold out accepted and declined requests from past events and check whether a scoring change would have ranked the accepted ones higher. Only then do we watch acceptance at a live event.
Outcome
Suggestions are acted on far more readily than directory browsing ever was, and organisers field fewer "who should I talk to" questions. Popular attendees are no longer overwhelmed. The explanation sentence turned out to matter as much as the match: people trust a suggestion they can see the reason for. The engine runs on modest infrastructure because the model is called only to write a sentence.
What this means for you
The same shape, retrieve with vectors, rank with rules, explain with a model, fits any recommendation problem where trust and fairness matter: mentoring programmes, partner marketplaces, internal expertise finders, member communities. If you are weighing a build, our vector database selection guide and recommendation engine page are the places to start, and a discovery sprint will tell you how much signal you already have.