αυτό το άρθρο υπάρχει μόνο στα αγγλικά.
A rule matrix across fifty-odd lifestyle factors, chosen over a trained recommender — because a housing match you cannot explain is a housing match nobody should act on
https://idominikos.com/el/articles/matching-is-not-machine-learning
Every few months someone asks why MyRoomie's compatibility engine is not a trained model. It would be an easy thing to say. It would demo well.
It is a rule matrix, and that is a decision rather than a stage we have not reached yet.
What the decision is actually about #
The matcher weighs somewhere north of fifty lifestyle and behavioural factors and produces a score. A learned model could produce a score too, probably a better one on some metric I could pick in advance.
The difference is what happens when someone asks why.
With a rule matrix I can answer. You scored low against this person because your sleep schedules are six hours apart, because one of you has a cat and the other declared an allergy, because one of you wants guests most weekends. Every term is inspectable and every term is a thing a human being recognises about their own life.
With a trained recommender I can show you a number and a shrug.
Why that matters more here than elsewhere #
If a music recommender is wrong, you skip the track.
If a housing recommender is wrong, someone signs a twelve-month lease with a person they cannot live with, in a market where moving again is expensive and slow. The cost of a bad match is not symmetrical with the cost of a good one, and that asymmetry should show up in the engineering.
There is a second reason, less philosophical. A rule matrix can be wrong in a way you can fix this afternoon. If we learn that noise tolerance matters more than we weighted it, that is a number in a table. Retraining is a different kind of afternoon.
Where the models do live #
This is not a position about machine learning. The property data infrastructure — FairRent, inside PropertyOS — is genuinely model-heavy, because pricing across twenty-eight markets is a problem where you want the model to find structure you did not know to look for, and where being wrong means a slightly off estimate rather than a bad year.
Different problem, different tool. The interesting engineering decision is almost never can we use the model — it is what does being wrong cost here.
The honest caveat #
A rule matrix has a ceiling. It only knows what we thought to ask, and people are worse at self-reporting than they believe. We collect outcome data and we will learn from it.
But whatever we learn will go back into terms someone can read. The explanation is not a feature we bolted on. It is the product.
θέματα που καλύπτονται
σχετικά κείμενα
- Your vibe-coded database is a mess (mine was too)articlesSchema drift is the tax of AI-assisted coding — why it happens to every vibe-coded project, and the tool I built to squash it2 κοινό/ά tag: product, lessons learned
- Πώς είναι να ψάχνεις funding στην ΕλλάδαarticlesΌσα δεν χωράνε στα LinkedIn posts — angels, μικρά tickets, τα κονέ των VC και γιατί πρέπει να βγεις εκτός συνόρων1 κοινό/ά tag: lessons learned
- Τα «ενδιάμεσα» του προϊόντος σου είναι κι αυτά προϊόνarticlesLoading screens, error messages, confirmation dialogs — οι liminal χώροι ενός προϊόντος καθορίζουν το πώς νιώθει ο χρήστης περισσότερο κι από τα features1 κοινό/ά tag: product