Duration: 24:22
PART 1 — Analytical Summary 🚀
Title: Vector-Based Product Similarity in Odoo: A New Paradigm for Recommendations
Speaker: Nicola, Software Engineer at Axon (Gold Odoo Partner)
Context 💼
This talk presents a practical, engineering-driven approach to product recommendations in Odoo, inspired by consumer-grade experiences (think “Customers also viewed” on Amazon). Nicola walks through the shortcomings of naive methods and proposes a robust vector-based similarity model designed to work well with Odoo’s product catalog data. The aim: generate meaningful “similar products” suggestions without relying on user behavior or large datasets.
Core Ideas & Innovations 🧠
The team proposes a vector embedding approach where each product is represented by one or more vectors, and similarity is computed via well-defined mathematical distances. The solution starts from first principles:
- For binary attributes (true/false), fields are directly encoded into 0/1 vectors. The cosine distance is chosen as the similarity metric, since angular proximity reflects meaningful matches.
- For weighted attributes, the model scales vector dimensions, letting more important features “pull” products closer together — a clean way to introduce business-driven signal weighting.
- For categorical fields (e.g., color), the approach uses one-hot encoding, translating a single field into multiple binary dimensions and preserving compatibility with the cosine distance framework.
- For textual data (product descriptions), the team uses a pre-trained, open-source embedding model (sourced from Hugging Face) that projects sentences into a vector space where semantically similar texts are close. This offloads the complexity of language representation while keeping the stack open and flexible.
The result is a two-vector strategy per product: a Characteristics Vector (VC) built from structured fields and an independent Description Vector from unstructured text. When ranking neighbors, the system first sorts by characteristics distance (the most reliable signals), then uses description distance as a tie-breaker for fine-grained ordering. This avoids the pitfalls of collaborative filtering (e.g., confusing complements with substitutes) and works from day one — no user data required.
Implementation Details in Odoo ⚙️
To make this work operationally inside Odoo:
- Vector fields are implemented as stored computed fields and recomputed when product attributes change. Heavy computations (especially embeddings) are deferred using the OCA queue_job module, keeping UI latency low.
- The database uses the PostgreSQL pgvector extension to store vectors, compute distances (including cosine), and leverage specialized indexes for speed and scale.
- A custom Odoo vector field bridges the pgvector data type with Odoo ORM. Defining a vector field is as simple as importing the field class and setting the dimension.
- The Characteristics Vector is constructed deterministically by assigning dimensions to specific attributes and reserving extra “buffer” dimensions to absorb future fields without reindexing all products. Categorical fields are one-hot encoded; numerical weighting can be applied to emphasize high-signal attributes.
Impact & Takeaways 💬
This vector-based design brings a few powerful benefits:
- It prioritizes structured business logic (product attributes) while still capturing nuance from descriptions — leading to high-quality, explainable recommendations.
- It avoids cold-start and privacy concerns by not depending on user tracking or purchase history.
- It gives teams fine-grained control over signal weighting and field inclusion, enabling domain-specific tuning while remaining model-agnostic for text.
- It’s designed for maintainability in Odoo: asynchronous compute, stored fields, and database-native vector operations result in a pragmatic, production-minded solution.
From the Q&A: The team is packaging the characteristics-vector portion for OCA, with plans to generalize field handling and configurability. A proof of concept runs on Odoo 16 (backportable to other versions if pgvector is available). Typical vector sizes mentioned include ~1,000 dimensions for characteristics (with ~384 selected features and buffer room), while text vector size depends on the chosen language model. Performance optimizations come after quality; pgvector offers a strong baseline. The UI concept includes a Kanban of similar products on the product form, with an optional distance threshold to suppress irrelevant suggestions.
Overall, this is a well-reasoned, modern take on recommendations in Odoo — grounded in math, respectful of data reality, and aligned with how product catalogs actually work. 🧩
PART 2 — Viewpoint: Odoo Perspective
Disclaimer: AI-generated creative perspective inspired by Odoo's vision.
When you align recommendations with the data businesses already trust — their product attributes — you reduce noise and increase clarity. That is the heart of simplicity: using structured information first, then enriching with language understanding when it actually helps. It’s the kind of pragmatic integration we value.
I’m also pleased to see the ecosystem spirit at work: open models, pgvector, and OCA modules. Good software is a system of parts that work together seamlessly. If we keep pushing toward integrated, configurable, and explainable features, we make recommendations useful for every company, not just those with massive behavioral datasets.
PART 3 — Viewpoint: Competitors (SAP / Microsoft / Others)
Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
The approach is sound: cosine-based similarity on structured attributes with a secondary text embedding is a clean, explainable stack. For mid-market catalogs, it’s a compelling alternative to collaborative filtering, especially where cold-start and privacy constraints matter. Using pgvector aligns with current database-native AI trends.
Enterprise adoption will hinge on scale, governance, and compliance. Field selection, weighting, and one-hot expansion must be managed carefully to avoid dimensional sprawl. Large product universes necessitate strong indexing and approximate nearest neighbor strategies; monitoring, retraining policies for text models, and multilingual coverage will also be key. UX differentiation could come from transparent “why this product” explanations and admin tooling that balances automation with control.
PART 4 — Blog Footer Disclaimer
Disclaimer: This article contains AI-generated summaries and fictionalized commentaries for illustrative purposes. Viewpoints labeled as "Odoo Perspective" or "Competitors" are simulated and do not represent any real statements or positions. All product names and trademarks belong to their respective owners.