How does it differ from collaborative filtering?

Collaborative filtering primarily uses patterns across users and items, while a knowledge-based system reasons from explicit requirements and domain knowledge.

Can it recommend a new item?

Yes, if the item's relevant properties are known and represented.

Can it combine with machine learning?

Yes. Hybrid systems can use learned ranking while preserving knowledge-based constraints.

AI Glossary / AI and machine learning / Intermediate

Knowledge-based recommender system

Definition

A knowledge-based recommender system suggests items by reasoning about explicit user requirements and knowledge of how items meet those requirements. It relies on domain relationships, constraints or relevant cases rather than depending mainly on patterns of past user ratings.

What it means

A person buying an industrial machine or choosing a specialized service may make that purchase rarely. There may be little personal history and few directly comparable users. A knowledge-based recommender can ask what the person needs and use facts about the available options to identify suitable candidates.

For example, a recommendation can depend on capacity, compatibility and a stated budget. The system can explain that an item is suggested because it meets those needs, rather than because similar users clicked on it.

This approach can reduce some cold-start difficulties, but it has a different cost: relevant knowledge must be represented and maintained. It also needs a way to handle incomplete or conflicting requirements. Knowing what an item can do is not the same as knowing everything the user values.

How it works

The system represents item features and domain knowledge connecting those features to user needs. It gathers requirements through forms, conversation or examples and then applies a recommendation method.

Constraint-based approaches identify items satisfying stated conditions. Case-based approaches compare the current requirements with items or cases using a similarity model and may support critiques such as “less expensive” or “more portable.” Some systems combine these ideas with learned ranking or collaborative signals.

If no item satisfies every condition, the system should explain the conflict and support an explicit trade-off. It should not silently treat a mandatory requirement as optional. Knowledge updates, item availability and changing user preferences all affect the recommendation. Evaluation needs to consider suitability, explanation quality and the effort required to reach a decision, not only whether a user clicks an item.

Three practical examples

1. An equipment adviser recommends machines that meet a required throughput and fit the available installation space.

2. A travel-planning tool compares accommodation against explicit requirements such as room capacity and accessibility features, with source checks for the relevant details.

3. A software-selection assistant matches a team's required integrations and deployment constraints to documented product capabilities.

Think of it this way

Think of a specialist salesperson who asks what you need and checks the catalog against those needs. The limit is that the software's advice is bounded by its represented knowledge and requirement model; it cannot assume the practical understanding or accountability of a human specialist.

Worked example

Suppose a fictional user needs a device costing no more than 600 units with battery life of at least 8 hours. Device A costs 550 and lasts 6 hours. Device B costs 590 and lasts 9 hours. Device C costs 650 and lasts 10 hours.

Only B satisfies both constraints. A fails the battery requirement and C fails the budget requirement. If the user changes the budget to 700, B and C become feasible candidates, and another preference may be needed to rank them.

This is a simple constraint-based example. The system has identified suitability under stated conditions; it has not proved that B is best on every unmentioned criterion.

Illustrative case study

A fictional procurement portal recommends printers to small offices. It initially asks only for budget and print volume. Customers later discover that some recommended models lack a required connection method.

The team adds compatibility questions and distinguishes mandatory requirements from preferences. When no printer fits all conditions, the portal explains which requirement excludes each near match and lets the user decide whether to revise it.

The case shows that a recommendation can be logically correct under an incomplete requirements model and still disappoint the user. Gathering the right knowledge is as important as the matching procedure.

Common misconceptions and mistakes

Knowledge-based recommendations need no data. They need reliable item and domain knowledge, even if rating histories are unnecessary.
Passing constraints makes an item universally best. It only establishes suitability under those constraints.
Cold start disappears entirely. Missing domain knowledge or unclear user needs can still prevent useful recommendations.

Business use

Knowledge-based recommendation is useful for infrequent, complex or constraint-heavy choices where explicit requirements matter. It can complement collaborative and content-based methods rather than replacing them in every setting.

Maintain the item facts and the rules connecting needs to features. Make explanations specific enough for users to inspect and distinguish factual compatibility from preference ranking. Evaluate whether users find suitable options with reasonable effort, and track cases where no match is found. Those cases may reveal gaps in the catalog, knowledge base or questions asked.

Check your understanding

Why should a recommender distinguish a mandatory compatibility requirement from a preference for a lower price?

Answer: Violating compatibility may make an item unusable, while a price preference may permit an explicit trade-off. Treating both as interchangeable scores can recommend an unsuitable option.

Related terms

Learn next

Read recommender systems and constraint satisfaction. Write a short requirement list for a complex purchase and separate non-negotiable conditions from preferences before ranking candidates.

Constraint satisfaction

Sources

Uta and colleagues, Knowledge-Based Recommender Systems: Overview and Research Directions, author research article: https://pmc.ncbi.nlm.nih.gov/articles/PMC10925703/. Burke, Knowledge-Based Recommender Systems (2000), author publication record and paper access: https://www.researchgate.net/publication/2378325_Knowledge-Based_Recommender_Systems. The devices and procurement portal are fictional. Source review: PMC direct access presented a browser challenge. The same article was consulted at its publisher, including the case-based and constraint-based methods: https://www.frontiersin.org/journals/big-data/articles/10.3389/fdata.2024.1304439/full.

Previous: Knowledge-based configuration Next: Knowledge-based systems