Forem: Yurii Lozinskyi

When the Matrix Breaks: Failure Modes of Early Matching Systems

Yurii Lozinskyi — Wed, 11 Feb 2026 14:53:57 +0000

In previous articles, we discussed how to build a matching system without Big Tech resources, why matrices come before neural networks, when ML finally becomes justified, and why explainability is a survival mechanism.

Now it’s time to talk about something less comfortable.

How these systems actually break.

Not with exceptions. Not without outages.
But with slow, silent degradation.

This article is about the failure modes that appear before ML and why recognizing them early matters more than adding another model.

1. Failure Mode: Matrix Saturation

At some point, everything starts to look “kind of relevant.”

Different requests produce similar top results. Explainability payloads look correct but uninformative. Users say: “It always suggests the same profiles.”

This is matrix saturation. It usually happens when:

dimensions are too coarse,
feature buckets are too broad,
context modifiers are missing.

The system technically works, but it has lost resolution.
Adding ML here doesn’t fix the problem as it learns the same flat landscape.

2. Failure Mode: Signal Dominance

One signal quietly takes over.

Every explanation looks like:

“Ranked highly because of X.”

Other signals still exist, but they no longer matter.

This often comes from:

improper normalization,
early weight tuning,
missing caps or decay functions.

Before ML, this was already dangerous.
After ML, it becomes irreversible.

The model will learn that only one thing matters, even if it shouldn’t.

3. Failure Mode: Silent Bias Accumulation

The system slowly favors a narrow subset of supply.

No rule explicitly enforces it. The metrics appear stable, but diversity is declining.

This happens because:

positive feedback loops reinforce visibility,
negative signals are missing or ignored,
UX choices shape behavior unintentionally.

Without explainability, this bias remains invisible.
With ML, it becomes institutionalized.

4. Failure Mode: Gaming the System

Supply-side actors adapt faster than the system.

They learn:

which fields matter,
which keywords boost ranking,
which signals are easy to fake.

Over time:

features lose meaning,
similarity collapses,
relevance becomes performative.

This is not malicious behavior. It’s rational optimization.
If you don’t design for it, it will happen.

5. Failure Mode: Explainability Drift

This one is subtle and dangerous.

Explanations still sound reasonable, but they no longer reflect real scoring logic.

Why?

scoring logic evolved,
explanations didn’t,
versions diverged.

At this point:

product teams can’t reproduce decisions,
auditors lose confidence,
trust erodes quietly.

Explainability without versioning is technical debt.

6. Why “Just Add ML” Makes This Worse

When ML is added at this stage, it learns from:

saturated rankings,
dominant signals,
accumulated bias,
gamed features.

The model doesn’t fix the system.
It freezes its worst behaviors into weights.

Now the problem is harder to see and harder to undo.

7. Designing Matrices That Expect to Break

Healthy systems assume failure.

This means:

monitoring signal distributions, not just outcomes,
treating explainability as a contract, not a debug tool,
embedding governance hooks early.

Matrices are not temporary scaffolding.
They are operational components.

8. A Practical Checklist

Ask these questions regularly:

Are top-N results diversifying over time?
Do explanations meaningfully change across requests?
Is any single signal dominating rankings?
Can product teams reproduce decisions?
Are new supply actors ever surfaced?
Do explanations still match scoring logic?

If you can’t answer these confidently, the matrix is already breaking.

Final Thought

Early matching systems rarely fail catastrophically.

They fail quietly.
They fail politely.
They fail while still “working.”

The teams that succeed are not the ones who rush to ML.
They are the ones who understand how their systems break — and design for it.

Before you teach a system to learn,
make sure it knows how to fail.

Yurii Lozinskyi - AI Delivery Lead & AI Practice Director

Part 1. Building an AI Matching Engine Without Big Tech Resources
Part 2. AI Matching: Matrix First, Neural Nets Later
Part 3. From Matrix to Model: When Is It Finally Safe to Train ML?
Part 4. Explainability in AI: Not a Feature, but a Vital Mechanism
Part 5. When the Matrix Breaks: Failure Modes of Early Matching Systems

Explainability in AI Is Not a Feature. It’s a Survival Mechanism.

Yurii Lozinskyi — Sat, 07 Feb 2026 19:54:36 +0000

If your AI system works but no one can explain why, it doesn’t really work.

That statement may sound provocative, but it captures a hard-earned lesson from building AI-powered matching systems under real-world constraints. Many systems don’t fail because their models are inaccurate. They fail because no one (users, delivery teams, or auditors) can understand why a decision was made.

Explainability is not a UI feature you add later.

It’s a survival mechanism.

This article continues the thread from the previous ones:

first we built a matching system without Big Tech resources,
then we showed why matrices come before neural networks,
then we discussed when it’s finally safe to train ML.

Now we address the next unavoidable question:

How do you keep an AI system trustworthy once it starts making decisions?

1. Why explainability becomes unavoidable

At some point, every AI-powered delivery or matching system reaches the same moment.

The system produces results.
Metrics look reasonable.
Accuracy appears acceptable.

And then someone asks:

“Why did the system choose this option?”

This question doesn’t come from engineers first.

It comes from product owners, business stakeholders, compliance teams, and end users.

In matching systems like marketplaces, supplier selection, and regulated workflows, people don’t just want a score. They want a reason. Without it, trust erodes quickly, even if the system is technically correct.

Explainability becomes unavoidable the moment your system influences real decisions.

2. Explainability vs observability vs governance

These concepts are often discussed together, but they solve different problems.

Explainability answers why a specific decision was made.
Observability shows what is happening inside the system over time.
Governance defines what is allowed, what is risky, and who is accountable.

They form a layered stack:

   +--------------------+
   |     Governance     |
   |   (Rules, Risks)   |
   +---------+----------+
             |
   +---------+----------+
   |    Observability   |
   |  (Metrics, Drift)  |
   +---------+---------=+
             |
   +---------+----------+
   |   Explainability   |
   |  (Why this match)  |
   +--------------------+

Without explainability, observability becomes abstract.
Without observability, governance becomes blind.
Without governance, explainability is just storytelling.

3. Why do matching systems need explainability more than most AI systems

Matching is not classification.
It’s not a prediction.
It’s multi-factor ranking under constraints.

Users don’t ask:

“Is this prediction correct?”

They ask:

“Why is this option higher than the others?”

If the system cannot answer:

why supplier A ranked above supplier B,
why a campaign brief changed the ranking,
why similar requests produced different results,

then users will bypass the system, even if it’s statistically “good”.

4. What real explainability looks like

Explainability is not a single number or a heatmap.
It’s a structured explanation tied to signals.

Example explainability payload for a match:

{
  "campaign_id": 123,
  "influencer_id": 456,
  "score_breakdown": {
    "matrix_compatibility_score": 0.78,
    "semantic_similarity_score": 0.32,
    "caption_similarity_score": 0.15,
    "model_prediction_score": 0.61
  },
  "why": [
    "Campaign.blog_type=expert aligns with influencer.social_status=micro",
    "High semantic overlap in professional tags",
    "Lower caption similarity due to missing niche terms"
  ],
  "audit_meta": {
    "timestamp": "2025-01-12T10:32:00Z",
    "model_version": "matching-v1.3.0",
    "feature_flags": ["caption_v2"]
  }
}

This payload doesn’t just show a score.
It explains how the system reasoned.

5. Observability: seeing patterns, not just logs

Explainability becomes powerful only when paired with observability.
Good observability focuses on signal behavior, not just uptime or latency:

distribution of individual scores over time,
correlation between signals and outcomes,
drift in embeddings or matrix usage,
anomalies in ranking patterns.

Example instrumentation:

metrics.histogram("matching.matrix_score", matrix_score)
metrics.histogram("matching.semantic_score", semantic_score)
metrics.counter("matching.explainability_gaps", missing_explanations)

These metrics allow teams to answer:

Is the system behaving as designed?
Which signals dominate decisions?
Where does behavior diverge from expectations?

6. Explainability enables governance and compliance

In regulated or high-stakes environments, explainability is not optional.

Auditors don’t want probabilities.
They want rationales.

Governance logic often depends on explainability:

if user.role == "auditor":
    include_full_decision_trace(match_id)

This enables:

audit trails,
historical decision reviews,
risk analysis,
regulatory compliance.

Without explainability, governance becomes guesswork.

7. Explainability and AI agents

AI agents amplify the importance of explainability.

A non-explainable agent output looks like this:

Suggested match
Score: 0.86

A usable agent output looks like this:

Suggested match
Score: 0.86
Reasons:
- Strong compatibility prior
- Professional semantic alignment
- Low risk based on historical patterns

Agents without explanations are dangerous.
They produce confident answers without accountability.

Explainability turns agents from black boxes into collaborators.

8. A real failure that explainability revealed

In one deployment, aggregate metrics looked healthy.
But users reported “odd” matches for specific campaign types.

Explainability revealed that:

embedding similarity-dominated decisions in edge cases,
compatibility priors were being overridden unintentionally,
recent data drift affected only a subset of campaigns.

The fix wasn’t a new model.
It was correcting signal weighting and drift detection.
Without explainability, the system would have failed silently.

9. Putting it all together

Explainability is not something you add after ML.
It’s part of the architecture that enables ML to be sustainable.

It connects:

decision -> reasoning,
reasoning -> observability,
observability -> governance.

In AI-powered delivery systems, explainability is not a “nice to have”.
It’s what keeps systems trustworthy, auditable, and correctable.

Final thought

Machine learning can optimize decisions.
Explainability ensures that those decisions withstand real-world scrutiny.

If your system produces answers but cannot explain them, it may look intelligent, but it will eventually fail where it matters most.

Yurii Lozinskyi - AI Delivery Lead & AI Practice Director

From Matrix to Model: When Is It Finally Safe to Train ML?

Yurii Lozinskyi — Wed, 04 Feb 2026 14:15:55 +0000

Most teams don’t fail at machine learning because of bad models.

They fail because they try to train models before the system is ready to learn.

After shipping a matrix-based matching system, the next inevitable question appears:

“Okay, when do we finally replace this with ML?”

To answer that honestly, we need to step away from abstract ML theory and examine how real systems evolve.

1. A concrete scenario: supplier selection in a marketplace

Let’s ground this discussion in a real-world use case.

Imagine a B2B marketplace that helps companies select service providers — agencies, vendors, or contractors.

The platform sits between two sides with very different expectations.

On the demand side:

some clients care about reputation and risk,
others prioritize niche expertise,
others want speed and flexibility.

On the supply side:

providers differ in size,
maturity,
credibility,
and communication style.

At launch, the platform has:

no historical performance data,
no clear notion of “successful” vs “failed” matches,
no reliable feedback loops.

Yet users still expect reasonable recommendations on day one. (Details in Article: Matrix-first matching.)

This is where many teams ask:

“Shouldn’t we train a model?”

And this is where most ML-first approaches break.

2. Why ML fails first in this scenario

Before talking about solutions, it’s important to understand why ML struggles here.

In early-stage marketplaces:

a rejected supplier does not mean “bad match”,
a selected supplier does not mean “good match”,
outcomes depend on off-platform conversations.

From a data perspective:

labels are weak or missing,
feedback is delayed or ambiguous,
user behavior is heavily shaped by defaults and UI ordering.

Training a model at this stage doesn’t produce intelligence.

It produces a confident replication of noise.

The problem isn’t model choice.

The problem is learning from signals that don’t mean what we think they mean.

3. Why a compatibility matrix exists in the first place

This is where explicit priors come in.

Instead of asking the system to learn relevance, we start by encoding expectations.

For example:

conservative enterprise clients expect established suppliers,
startups often prefer smaller, flexible providers,
regulated industries prioritize reputation and compliance.

These expectations can be expressed explicitly using a small set of stable features.

A compatibility matrix does exactly that:

it encodes domain knowledge,
enforces product constraints,
and produces consistent behavior without training data.

Importantly, the matrix does not predict outcomes.

It defines what is reasonable.

4. The matrix as a stabilizing prior

In the marketplace example, the matrix plays three critical roles.

First, it enforces constraints.

High-risk suppliers are discouraged for conservative clients without hard rejection.

Second, it enables explainability.

The system can say:

“This supplier ranks higher because their profile aligns with your request type.”

Third — and most importantly — it shapes early behavior.

Early interactions are not random.

They happen within a controlled decision space.

That matters because early behavior becomes future data.

If early matches are arbitrary, future training data will be arbitrary too.

5. When the system starts producing usable data

Over time, something changes.

The marketplace now observes:

which suppliers were shown,
which were shortlisted,
which were contacted,
which engagements progressed.

Crucially:

events are logged intentionally,
success criteria are defined upfront,
the matching logic remains stable during data collection.

This is the moment many teams miss.

ML becomes viable not when data exists,

but when data reflects intentional system behavior.

Data collected accidentally is rarely useful for learning.

6. From matrix to model: the safe transition

At this stage, teams often expect neural networks to be the next step.

In practice, they rarely are.

The first successful transition usually involves:

learning-to-rank models,
gradient-boosted trees,
or simple linear models.

The compatibility matrix does not disappear.

It becomes just another feature.

The model learns:

when the matrix over-penalizes,
when exceptions occur,
which signals matter more than expected.

ML does not replace judgment.

It refines it.

7. Why synthetic data doesn’t fix this problem

Some teams try to accelerate learning by generating synthetic data.

In marketplaces — especially B2B or regulated ones — this is dangerous.

Synthetic data assumes:

known distributions,
known success criteria,
known user behavior.

Early-stage systems have none of that.

A model trained on synthetic outcomes optimizes for imagined users.

That’s worse than using a matrix.

The matrix, while imperfect, stays honest.

8. The full evolution path, revisited

In this marketplace scenario, a healthy evolution looks like this:

Phase 1 — Explicit priors

Matrix-based compatibility and explainable defaults.

Phase 2 — Instrumentation

Structured logging, defined outcomes, and feedback loops.

Phase 3 — Hybrid ranking

ML learns residuals while the matrix remains a prior.

Phase 4 — ML dominance

Models lead; matrices constrain edge cases.

Skipping phases doesn’t accelerate this process.

It breaks it.

Final thought

In real marketplaces, especially high-stakes or regulated ones,

ML is not the starting engine.

It’s the turbocharger.

If your system behaves sensibly before you train a model, you’re not behind.
You’re building the only kind of foundation that machine learning can learn from.

Yurii Lozinskyi - AI Delivery Lead & AI Practice Director

AI Matching: Matrix First, Neural Nets Later

Yurii Lozinskyi — Sat, 31 Jan 2026 23:37:27 +0000

How to get day-one relevance when you don't have data (and probably never did)

Everyone wants an "AI-powered matching engine".

In practice, this usually means one thing:

"We'll train a neural network and let it figure things out."

That sounds reasonable --- until you ask the first uncomfortable question:

Where exactly will the training data come from?

This article is about that gap between ambition and reality.

It's about building matching systems before you have Big Data, feedback loops, or ML infrastructure - and still delivering relevance from day one.

1. The real business problem: "Where do we get data to train a neural network?"

Let's start with the problem most teams avoid articulating clearly.

Neural networks do not fail because they are bad.

They fail because they need data that doesn't exist yet.

To train a meaningful matching model, you need:

historical matches
outcomes (success/failure)
user behavior (clicks, acceptances, conversions)
enough volume to avoid overfitting

Early-stage systems have none of that.

This creates a paradox:

you need good matching to get users
you need users to get data
you need data to train matching

Most teams quietly ignore this and ship:

random relevance
overconfident AI labels
or brittle rule engines disguised as "ML"

That's not a technical issue.

That's a product and architecture problem.

2. A concrete use case: choosing the right marketing channel or agency

To make this tangible, let's define a clear use case.

Imagine a company launching a new marketing campaign.

They want to choose the right advertising channel, agency, or influencer.

Their constraints are realistic:

limited budget
brand reputation at stake
unclear expectations about what will work
no historical performance data in this exact setup

On the supply side (channels, agencies, influencers), you have:

different levels of reach
different credibility
different risk profiles
different communication styles

The business question is not:

"Which option is statistically similar to this campaign?"

The real question is:

"Which option best fits the expectations and constraints of this campaign?"

That's a compatibility problem, not a similarity problem.

3. Why "just train a neural network" doesn't work here

At this point, someone usually says:

"Let's just embed everything and train a model later."

That works only if:

you already have outcomes
you already have labels
you already have scale

In our use case, you don't.

Trying to use neural networks here leads to one of three failures:

The model overfits on tiny data
The model outputs noise that looks confident
The team disables the model "temporarily" --- permanently

The real issue is not lack of ML talent.

It's that the system has no prior understanding of what "fit" means.

So you need a prior.

4. Reframing the problem: similarity vs compatibility

This is the key conceptual shift.

Most ML tooling is built around similarity:

cosine similarity
Euclidean distance
nearest neighbors

Similarity answers:

"How alike are these two things?"

But matching in business systems rarely asks that question.

Instead, it asks:

"How appropriate is this option for this context?"

That's compatibility.

Compatibility is:

asymmetric
expectation-driven
domain-specific

And it can be expressed explicitly, without pretending to learn it from non-existent data.

5. Solution: Compatibility Matrix (feature matrix, not ML)

Now we get to the core idea.

Instead of trying to learn relevance, we encode domain knowledge as a matrix.

We define two small, stable feature spaces.

Campaign side

blog_type ∈ { corporate, brand_voice, expert, personal }

This captures:

how formal the communication should be
how much authority is expected
how much personal storytelling is acceptable

Supply side (agency / influencer / channel)

social_status ∈ { celebrity, macro, micro, nano }

This captures:

perceived authority
reach expectations
risk tolerance
credibility

Now we define a compatibility matrix:

compatibility[blog_type][social_status] → score ∈ [0..1]

This matrix answers:

"Given this campaign style, how appropriate is this level of authority?"

It is not a guess.

It is a product hypothesis.

6. Example: a simple 4×4 compatibility matrix

Let's make this concrete.

           | celebrity | macro | micro | nano
-----------|-----------|-------|-------|------
corporate  | 1.0       | 0.8   | 0.4   | 0.2
brand_voice| 0.7       | 1.0   | 0.8   | 0.5
expert     | 0.6       | 0.9   | 1.0   | 0.7
personal   | 0.3       | 0.6   | 0.9   | 1.0

# Compatibility Matrix lookup (Day 1 matching)
matrix = {
    'corporate': [1.0, 0.8, 0.4, 0.2],
    'brand_voice': [0.7, 1.0, 0.8, 0.5],
    'expert': [0.6, 0.9, 1.0, 0.7],
    'personal': [0.3, 0.6, 0.9, 1.0]
}

def matrix_score(campaign, influencer):
    """O(1) lookup — 1000s RPS без проблем"""
    influencers = ['corporate', 'macro', 'micro', 'nano']
    idx = influencers.index(influencer)
    return matrix[campaign][idx]

# Production usage
score = matrix_score('corporate', 'macro')  # 0.8 ✅
print(f"Corporate ↔ Macro: {score}")

What this represents in business terms:

Corporate campaigns prioritize authority and low risk
Personal storytelling thrives with relatable, smaller voices
Expert campaigns value credibility over raw reach

Important clarification:

These numbers are relative, not absolute
They don't predict success
They define expected fit, not outcomes

7. Why this works without data

At this stage, a reasonable question arises:

"Isn't this just hard-coded logic?"

Yes --- and that's exactly the point.

But it's structured, graded, and explicit, unlike:

binary rules
if/else chains
or fake ML

A compatibility matrix gives you:

deterministic behavior
explainable decisions
controllable bias
and stable early relevance

Most importantly, it gives the system a worldview before data exists.

8. How this evolves into machine learning (without rewrites)

This approach is not anti-ML.

It's pre-ML.

As the system runs, you naturally collect:

which matches were shortlisted
which were accepted
which led to engagement or conversion

At that point, the transition is incremental.

Phase 1 --- Matrix only

score = compatibility_matrix[blog_type][social_status]

Phase 2 --- Hybrid

score = 0.7 * matrix_score + 0.3 * nn_prediction

# Phase 2: Matrix 70% + NN 30%
matrix_score = 0.8
nn_score = nn_model.predict(features)  # 0.75
final = 0.7 * matrix_score + 0.3 * nn_score  # 0.785

Phase 3 --- ML-dominant

score = nn_prediction

The matrix never disappears.

It becomes:

a baseline
a regularizer
a fallback for cold start

This is how production systems actually grow.

9. Why this gives you day-one relevance

The biggest hidden risk in matching systems is irrelevance at launch.

If users see poor matches:

they don't interact
you don't collect data
your ML roadmap dies before it starts

A compatibility matrix avoids that trap.

You get:

reasonable defaults
behavior aligned with business expectations
trust from users
and data that actually reflects intent

All without pretending you have Big Data.

# Day 1: 100% matrix, no training data needed
def get_matches(request, suppliers, min_score=0.6):
    matches = []
    for supplier in suppliers:
        score = matrix_score(request.campaign_type, supplier.category)
        if score >= min_score:
            matches.append((supplier, score))
    return sorted(matches, key=lambda x: x, reverse=True)[14]

# Real metrics: 47 suppliers → 12 matches → 3% conversion
# O(n) complexity, 1000s RPS, zero cold start

Final takeaway

If there's one idea worth remembering:

Similarity is a mathematical concept.

Compatibility is a business concept.

Neural networks are excellent at learning similarity ---

after the world gives you data.

Compatibility matrices let you act before that moment arrives.

Matrix first.

Neural nets later.

That's not a compromise. That's how real matching systems survive long enough to learn.

Yurii Lozinskyi - AI Delivery Lead & AI Practice Director

Building an AI Matching Engine Without Big Tech Resources

Yurii Lozinskyi — Fri, 09 Jan 2026 22:32:25 +0000

Pairfect IO Case Study + Practical Framework

Most people think matching in marketplaces is just filters + sorting.

It isn’t.
Matching is architecture. It's the mechanism that decides who should meet whom.

When matching fails, the entire marketplace collapses — no UX, no design, and no advertising budget can save it.

This post is about how we built an AI-powered matching engine for Pairfect IO, a marketplace connecting brands with influencers — without:

training data
behavioral signals
feedback loops
GPUs
ML ops stacks
Pinecone/Milvus/Weaviate
and without 200 ML engineers like LinkedIn

Everything ran on PostgreSQL + pgvector, with explainability, determinism, and an evolution path.

If you're building a marketplace and need matching that works before you have Big Tech data — this is for you.

Why Matching Is Harder Than It Looks

Matching looks trivial from the outside. But production-grade matching is an outcome-driven system.

Take LinkedIn. Their matching works because it learns from:

applications
acceptance rates
recruiter behavior
network overlap
engagement signals
retention data

In other words: LinkedIn doesn’t “guess relevance”. It learns relevance from outcomes.

Now contrast that with a seed-stage marketplace.

Pairfect started with:

no labeled data
no behavioral data
no interactions
no click-through signals
no embeddings graph
no GPUs
Postgres as the only accepted infra

Completely different world.

Yet a common mistake early teams make is trying to copy Big Tech architecture without Big Tech data. It doesn’t work.

The Real Beginning: Constraints, Not Models

Most teams begin matching by asking:

“Which ML model should we use?”

We started by asking a different question:

“What constraints make certain architectures impossible?”

Below is a simplified version of our real constraint table:

Constraint	Impact
Self-funded	No GPUs, no distributed systems
Must run on Postgres	Matching logic must be SQL-native
No labels	No LTR, no two-tower training
CPU only	Lightweight embeddings only
MVP in 3 months	Simple > complex
Need explainability	No black-box ranking
Sparse metadata	Must extract from text
Minimal DevOps	No vector DB clusters

This table was the architecture.

Before we wrote a single line of code, we knew what we couldn’t build.

And ironically, that saved Pairfect, a self-funded startup.

Defining What “Good Match” Means (Critical & Often Missed)

You cannot architect matching until you define what a good match means in your domain.

For LinkedIn, a “good match” means:

hired + retained

For Pairfect, a “good match” meant:

semantic fit between campaign & influencer
audience expectations align
tone compatibility
price compatibility
content format alignment
worldview alignment (yes, that matters in creators)

If your team cannot answer:

“What constitutes a good match here?”

Then any discussion of embeddings vs rules vs transformers is premature.

Why We Didn’t Go Straight for SOTA Models

We evaluated the standard architectural options. Most didn’t survive the constraint filter:

Option	Why Not (At MVP Stage)
Rules-only	Too rigid
Pure embeddings	Too noisy without deterministic anchors
LLM ranking	Too slow + expensive on CPU
Learning-to-Rank	Needs labeled data
Two-tower	Needs training data + GPUs
Collaborative filtering	Needs behavior data
Graph models	Needs graph maturity

That left one viable category:

Hybrid Matching

Not because it's “cool” — but because it’s appropriate for the stage.

The Architecture: Hybrid Matching in Practice

Our hybrid pipeline looked like this:

Hard Filters → One-Hot Features → Embeddings → Fusion → Top-K

Breakdown:

1. Hard Filters

Eliminate impossible cases upfront:

price
language
content format
region
campaign type

This removes garbage noise.

Example (simplified):

SELECT *
FROM influencers
WHERE price BETWEEN 500 AND 1500
  AND language = 'en'
  AND region = 'eu'
  AND format @> ARRAY['video']::text[];

2. One-Hot Signals

Encode domain knowledge explicitly:

tone
niche
vertical
channel
creative style

This prevents “semantic nonsense” (e.g., matching a financial brand with a prank channel).

SELECT influencer_id,
       (CASE WHEN tone = campaign.tone THEN 1 ELSE 0 END) AS tone_match,
       (CASE WHEN vertical = campaign.vertical THEN 1 ELSE 0 END) AS vertical_match
FROM influencers;

3. Embeddings

We generated embeddings for:

bios
captions
descriptions
LLM summaries

Stored in pgvector, similarity via cosine.

SELECT influencer_id,
       1 - (bio_embedding <=> campaign.bio_embedding) AS semantic_score
FROM influencers
ORDER BY semantic_score DESC
LIMIT 50;

4. Rank Fusion (RRF)

This was surprisingly powerful.

RRF allowed us to merge multiple ranking signals into one stable ranking without training.

To merge them without training, we used RRF:

Score = Σ 1 / (k + rank_i)

Example (simplified in SQL/CTE form):

WITH ranked AS (
  SELECT influencer_id,
         ROW_NUMBER() OVER (ORDER BY semantic_score DESC) AS r1,
         ROW_NUMBER() OVER (ORDER BY tone_match DESC) AS r2,
         ROW_NUMBER() OVER (ORDER BY vertical_match DESC) AS r3
  FROM candidates
)
SELECT influencer_id,
       (1.0 / (60 + r1)) +
       (1.0 / (60 + r2)) +
       (1.0 / (60 + r3)) AS final_score
FROM ranked
ORDER BY final_score DESC
LIMIT 10;

Benefits:

no ML pipeline
consistent behavior
explainable scoring
cheap to compute
resistant to noisy embeddings

5. Top-K Output

Return a shortlist, not an infinite scroll.

Top 10 most compatible influencers
+ explanation layer

This is not personalization; it is decision support.

Why Everything Ran on PostgreSQL

Our entire matching system ran on:

PostgreSQL + pgvector + CPU

Reasons:

infra should reduce risk, not increase it
one system > five microservices
fewer moving parts = fewer failures
debugging in SQL is fast & deterministic
product iteration > infra optimization

Hot take:

infra is not tooling, infra is liability

Especially at the MVP stage.

Explainability Was a Feature, Not a Nice-to-Have

We built full explainability into the matching layer:

why this recommendation
which signals contributed
how fusion scored them
what would disqualify it
how to override

Trust matters in early marketplaces.

LinkedIn can hide behind a black box.

Startups cannot.

The Evolution Path (Critical CTO Work)

Founders often ask:

“Will hybrid scale forever?”

No. And it doesn’t need to.

Our planned evolution path looked like this:

Hybrid → Behavioral Signals → LTR → Two-Tower → Graph → RL → Agents

Where each step unlocks the next:

hybrid gives usable matching Day 1
behavior gives labels
labels enable LTR
scale enables encoders
graph enables multiple objective optimization
RL enables personalization
agents enable reasoning

This is how marketplace intelligence actually grows in the real world.

Final Lessons

Three lessons emerged from building Pairfect:

Lesson 1 — Matching is not a model problem; it’s a business constraint problem
Lesson 2 — Appropriate complexity wins at the MVP stage. Over-engineering extends time-to-market
Lesson 3 — You don’t need Big Tech architecture without Big Tech data

The goal is not to replicate LinkedIn.

The goal is to build a system honest about your stage and prepared to evolve.

If you’re building something similar

Happy to discuss:

marketplace matching
ranking architectures
hybrid systems
pgvector setups
evolution paths

DMs open.

Yurii Lozinskyi - AI Delivery Lead & AI Practice Director