Building a Multilingual Intelligent Recipe Search System: A Complete Practice from Architecture Design to Deterministic Sorting

This article introduces a multilingual recipe search API project based on ASP.NET Core. Its core is to separate AI query understanding from deterministic sorting rules, combining layered architecture and cloud-native deployment to provide a reference for building predictable and traceable search systems. The project uses AI to process multilingual input and extract intents, and a rule system to ensure sorting transparency, balancing intelligence and determinism.

Traditional keyword search struggles to handle multilingual, colloquial, and complex ingredient requirements. This project provides a solution: a multilingual API based on ASP.NET Core. The core concept is separation of concerns—AI is used for query understanding (translation, extraction, normalization), while retrieval and sorting rely on a deterministic rule system, avoiding the black-box problem of pure vector search and ensuring result predictability and debuggability.

The system adopts a layered architecture:

1. API Layer: Handles HTTP requests, including controllers, DTOs, validation, rate limiting, etc.
2. Application Layer: Orchestrates search flow, executes sorting logic, and abstracts query understanding services.
3. Domain Layer: Core concept models (Recipe, SearchQuery, etc.).
4. Infrastructure Layer: Dataset loading (local JSON/Azure Blob), in-memory repository, and Azure OpenAI integration. The search process consists of seven steps: Validation → AI Understanding → Retrieval → Deterministic Sorting → Result Return, ensuring debuggability.

Sorting uses a rule-based scoring system:

• Ingredient Matching: Exact phrase (+6), strong match (+4), weak match (+1); extra +2 if the ingredient appears in the title.
• Keyword Matching: Name match (+3), ingredient text match (+2). Results are sorted in descending order of total score; 0-score entries are filtered; entries with the same score retain their original order, ensuring transparency and interpretability.

AI is only used for query understanding:

• Multilingual Support: Detects input language and normalizes it to English (e.g., Swedish 'kyckling' → 'chicken').
• Intent Extraction: Extracts structured ingredients and keywords from colloquial expressions (e.g., a Swedish query extracts 'fish', 'coconut milk', 'spicy').
• Noise Filtering: Excludes irrelevant filler words. Data storage uses in-memory loading (loaded at startup). Advantages: Low latency, determinism, simplified deployment; supports local JSON or Azure Blob, suitable for scenarios with controllable scale.

Testing covers core behaviors (dataset parsing, sorting, filtering, etc.). Deployment is on Azure App Service, using Blob storage for datasets and OpenAI services; configuration manages sensitive information via key management. Design trade-offs: In-memory storage, rule-based sorting, no synonym dictionary—suitable for scenarios with controllable datasets, need for interpretable results, and mandatory multilingual support. For million-level data, specialized search infrastructure is required.

The project demonstrates the design idea of 'AI-enhanced but not over-reliant': AI handles natural language understanding, while the rule system ensures predictable sorting. Value for developers: Provides code references and design philosophy—emphasize determinism and interpretability while embracing intelligence; systems that users can understand and developers can debug have greater practical value.