Tongyi Wanli Model Recommendation
Recommend the most suitable model from the model library of Alibaba Cloud Tongyi Wanli platform and provide sample calling code based on user scenarios.
Applicable Scenarios
Explicit Selection:
- "Recommend a model", "Which model to choose", "Which model is good to use"
- "Help me compare XX and XX models"
Implicit Selection (users describe what they want to do, implying the need to select a model):
- "I want to build a XX" (customer service robot, translation tool, code assistant...)
- "Help me implement XX function" (image generation, speech synthesis, text summarization...)
- "How to use AI to do XX", "Can large models do XX"
- "What solutions are there for XX scenarios", "I want to access XX capabilities"
Technical Selection:
- "Which is more suitable for YY, XX or XX"
- "How to choose for low-cost/high-concurrency/high-precision scenarios"
Not Applicable:
- Users have confirmed the model and only ask how to call it → directly provide calling code
- Purely querying model parameters/prices → use the bailian-docs-llm-wiki skill
Boundary with bailian-docs-llm-wiki: When users involve both model query and model selection at the same time, prioritize using this skill (this skill will read model data internally to complete the recommendation). Only when users have confirmed the model and only need to check parameters/prices/calling methods, it will be handled by bailian-docs-llm-wiki.
Pre-check
Before executing the recommendation, confirm that the dependent
skill is installed and data is available.
Detection Logic:
- Check if the skill is installed (by checking if
bailian-docs-llm-wiki/models/models.jsonl
- If not installed, execute installation:
npx skills add modelstudioai/skills --skill bailian-docs-llm-wiki -y
If installation fails, inform the user and abort. It is forbidden to recommend models based on memory without data.
Recommendation Process
Step 1: Understand Requirements (Completed directly by Agent, not output to users)
Quickly extract structured requirement information from user descriptions. The JSON structure definition can be found in [references/requirement-schema.md], and the inference rules can be found in [references/capability-codes.md].
Be Fast: Simple field mapping, no complex reasoning. If requirements are unclear, directly ask for specific scenarios, do not output intermediate analysis.
Step 2: Filter Candidates
Comprehensively filter matching models (10~50) from
and
models/groups/<slug>.json
, with both structured fields and semantic information participating in the filtering:
- Remove historical snapshot versions (e.g., ), only retain the main version
- Filter by modality (input/output modalities must be compatible)
- Sort by capability, features, context window, and quality positioning score
- Read the description of group files (group-level + item-level), perform semantic matching between scenario keywords (such as "scientific research", "code", "long text", "customer service") and user requirements to improve the ranking of matching models
- Retain only a small number of models from the same family at most to avoid homogenization
- Relax filtering conditions when there are insufficient candidates
For data source field descriptions, see [references/data-source.md].
Step 3: Select Recommended Models
Select 3 recommendations from the candidate list:
| Position | Strategy |
|---|
| Recommendation #1 (Best Recommendation) | The best model that best meets the user's budget and quality preferences |
| Recommendation #2 (Second-best Option) | A model of another tier, explaining the tradeoff with #1 |
| Recommendation #3 (Alternative Reference) | A choice from a different perspective, explaining scenario differences |
Sorting Logic:
- If the user wants to save money → #1 must be the most cost-effective, not the flagship
- If the user wants the best → #1 must be the most powerful flagship model
- If the user has no preference → #1 selects the model with the highest comprehensive matching degree
- Recommend the most suitable model for the scenario, not the most powerful; infer preferences from user expressions, do not preset tendencies
Constraints:
- Reasons must be associated with the user's specific needs (empty words like "powerful performance" are prohibited), and the three reasons should be from different angles
- When pricing information is available, combine budget trade-offs to help users make cost decisions
- Avoid recommending multiple models from the same family, prioritize stable versions
- Provide multi-tier options and tradeoff explanations, allowing users to decide for themselves
Pipeline Scenario: Models in adjacent steps must be modality-compatible; add a prompt if incompatible.
Step 4: Output Recommendation Results
For each recommended model, read the corresponding group JSON file (
models/groups/<slug>.json
) to obtain the sample calling code in the
field. For the sample code acquisition method and output format, see [references/samples-format.md].
Output recommendations directly in natural language (e.g., "Based on your needs, I recommend the following models..."), each model includes:
- Model Name and ID
- Recommendation Reason — Associated with the user's specific needs, with tradeoff comparison
- Highlights — Key advantage tags
- Specification Information — Context window, maximum output, pricing (if available)
- Sample Calling Code — Obtained from the samples field of the group file (prioritize openai.python, also provide curl)
Output Constraints:
- Do not expose internal process terms (terms like "Stage", "Intention Portrait", "Candidate Recall", "Reranking" are prohibited)
- All recommendations are based on actual data from , do not recommend models based on memory