Back to Writing

Learning Note

What I learned building a hybrid recommendation prototype

An honest account of combining Elo-style ranking with collaborative and content-based signals in an academic futsal-management project.

Filed under
  • Algorithms
  • Django
  • React
  • Recommendations
  • Academic Project

Recommendation is a decision problem, not a single formula

In Hamro Futsal, we explored recommendations because a team looking for an opponent has more than one consideration. It is not enough to know that another team exists; the system should try to surface a team that makes sense to play against.

Our academic prototype combined three related ideas: an Elo-style rating that changes after results, collaborative filtering based on patterns in match history, and content-based filtering based on available team and venue attributes. The intention was to test whether several imperfect signals could be more useful together than relying on a single score.

What each signal contributed

Collaborative filtering looked for similarity in past team behaviour. In the project, this included signals such as matches played, win rate, and average goal difference; cosine similarity was used to compare those profiles. This approach is more helpful when there is enough previous match activity to compare.

Content-based filtering approached the problem from another direction. It used characteristics such as Elo rating, a weighted score, and venue preference, with Euclidean-distance-based similarity. Because it can use attributes rather than depending entirely on long match histories, it offered a useful alternative when a team had less historical data.

The Elo-style rating then supplied a dynamic competitive context. Rather than treating a team strength as static, it was updated after a result according to expected and actual outcomes.

Why we chose a hybrid approach

Each technique had blind spots. Collaborative filtering becomes less informative when there is little history. Content-based filtering can be useful early, but it cannot fully represent everything that happened in prior matches. A rating can describe competitive context, but it is not a complete recommendation by itself.

We therefore experimented with a weighted hybrid score, combining collaborative and content-based outputs. The group refined the approach through trial and error: we considered which inputs could reasonably contribute to team suggestions and how their relative influence should be balanced. The work was a prototype and learning exercise—not a claim that we discovered a universally optimal recommendation formula.

  • Collaborative signal: learns from match-history patterns when data is available.
  • Content signal: compares known team and venue attributes, including for lower-history cases.
  • Elo signal: keeps competitive context responsive to reported outcomes.
  • Hybrid weighting: provides a way to balance the signals rather than treating any one of them as absolute.

The hard part was choosing meaningful data

The main challenge was not writing only the similarity calculations. It was deciding which attributes were useful enough to include, how to avoid letting a single signal dominate the result, and how the recommendation should appear within a real booking and team-management flow.

That work involved collaboration. Sujal Karki initiated the algorithm direction and led backend and algorithm refinement. Rupesh Acharya and I built and refined the frontend experiences, while the group tested and discussed the parts that could contribute to collaborative and content-based recommendations. I also supported overall refinement and complex backend work where necessary.

What I handled

  • Worked on the frontend and overall product refinement that made ranking and recommendation ideas visible in the futsal workflow.
  • Collaborated with Sujal Karki and Rupesh Acharya to test how team history, attributes, and ranking information could appear as understandable suggestions.
  • Helped connect algorithm-oriented backend work with the booking, team, match, and results experience.

What I would improve next

A stronger version would need real usage data and evaluation criteria before making claims about recommendation quality. Future work could include:

  • Defining an evaluation method for recommendation relevance and competitive balance.
  • Capturing user feedback after suggested matches.
  • Tuning the hybrid weights against observed outcomes instead of selecting them only through prototype testing.
  • Handling new teams, incomplete records, and changes in behaviour more deliberately.
  • Testing how recommendations affect the actual booking and match-acceptance journey.

Reflection

This project made the limits of recommendation work clearer to me. A hybrid model can be a useful design choice, but combining techniques does not automatically make a recommendation correct. The quality of the input data, the weights, the interface, and the way users respond all matter.

The most valuable lesson was to make the system honest about what it knows. The prototype could turn match history, attributes, and ratings into structured suggestions. Validating whether those suggestions genuinely improve real match selection would require a later phase with real users and measured outcomes.