Instruction-Oriented Multi-Turn Dialogue Rewriting Model for Smart Home Central Displays

Model Summary

This model performs instruction-oriented multi-turn dialogue rewriting in smart home central display scenarios. It takes multi-turn dialogue history and the current user utterance as input, then generates a correct, clear, and complete instruction for the current turn.

The rewritten instruction is designed to improve downstream understanding, parsing, and execution. It preserves the user's original intent while resolving ambiguity, completing omitted information, standardizing expression, and aligning the utterance with downstream processing requirements.

Key Features

• Multi-turn dialogue understanding: Tracks context, references, ellipsis, and speaker intent across turns.
• Current-turn instruction rewriting: Produces a normalized and executable instruction for the latest user turn.
• Dynamic rule configuration: Supports runtime rewriting rules without retraining.
• Cross-scenario rule compatibility: Handles conflicting rules across multiple capability domains and scenarios.
• Strong instruction following: Optimized for precise compliance with rewriting constraints.
• Low-latency and high-concurrency oriented: Suitable for online serving in complex end-to-end pipelines.
• Domain-oriented design: Tailored for smart home central displays and similar human-machine dialogue systems.

Task Definition

Intended Uses

Direct Use

• Rewriting user instructions in multi-turn smart home dialogues.
• Normalizing ambiguous, elliptical, or context-dependent user utterances.
• Preparing clean instructions for downstream intent parsing, planning, or device control.
• Applying dynamically configured rewriting rules in production dialogue systems.

Downstream Use

This model is intended to be integrated as a component in a larger dialogue pipeline. It can serve as a pre-processing or mid-processing module before downstream intent recognition, slot filling, task planning, device control, or response generation.

Out-of-Scope Use

• Safety-critical decision-making without additional guardrails.
• Legal, medical, financial, or other high-risk advice.
• Scenarios requiring certified privacy or security compliance without proper system-level protection.
• Any use that intentionally generates misleading, harmful, or unauthorized instructions.

Scenario and Challenges

The smart home central display scenario is complex and covers multiple specialized capability domains. Rewriting requirements vary significantly across capability types. For example, device control, information query, media playback, schedule management, and home automation may each require different normalization and completion strategies.

To support such diversity, the model is designed to handle:

• Dynamic rewriting rule configuration
• Multi-scenario conflict rule compatibility
• High requirements for instruction understanding and instruction following
• Consistent behavior across heterogeneous downstream tasks

Engineering Constraints

Instruction rewriting is a critical component of an end-to-end pipeline, with complex processing both upstream and downstream. Therefore, the model must operate under strict latency and concurrency constraints while jointly optimizing:

• Instruction-following capability
• Inference efficiency
• Rewriting accuracy
• Stability under concurrent requests

The model is intended to be compatible with common serving optimizations such as batching, KV cache, quantization, and other deployment-level acceleration techniques, depending on the target runtime.

Dynamic Rule Configuration and Conflict Handling

The model is designed to support runtime rewriting rules and multi-scenario rule compatibility.

Rule Configuration

Rules may be provided through one or more of the following sources:

• System prompts
• JSON / YAML rule schemas
• API-level configuration
• Domain-specific or capability-specific policy objects

Rule Scope

Rules can be scoped by:

• Capability domain
• Device type
• Scenario
• User context
• Dialogue state
• Safety or compliance constraints

Conflict Resolution

When multiple rules conflict, the intended resolution strategy may include:

1. Priority-based resolution
2. Specificity-based resolution
3. Recency-based resolution
4. Safety-first constraints
5. Fallback to default rewriting behavior

The exact rule schema and conflict-resolution policy should be documented according to your production implementation.

How to Use

from transformers import AutoTokenizer, AutoModelForCausalLM

model_id = "Xing4.0-29B-A4B-MTDR"

tokenizer = AutoTokenizer.from_pretrained(
    model_id,
    trust_remote_code=True
)

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    trust_remote_code=True,
    device_map="auto"
)

messages = [
    {
        "role": "system",
        "content": (
            "You are an instruction rewriting model for smart home central displays. "
            "Rewrite the current user utterance into a complete, clear, and executable instruction. "
            "Preserve the original intent and follow the provided rewriting rules."
        )
    },
    {
        "role": "user",
        "content": "- User: Turn on the living room light.\n -Bot: OK. -User: Make it brighter. \n\n - Output: "
]

input_ids = tokenizer.apply_chat_template(
    messages,
    return_tensors="pt",
    add_generation_prompt=True
).to(model.device)

outputs = model.generate(
    input_ids,
    max_new_tokens=128,
    do_sample=False
)

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Input and Output Format

Example Input

{
  "history": [
    {"role": "user", "content": "- User: Turn on the living room light.\n -Bot: OK. -User: Make it brighter.\n\n - Output: ",
  "rules": [
    {
      "domain": "device_control",
      "instruction": "Resolve pronouns and ellipsis using dialogue history."
    }
  ]
}

Example Output

{
  "rewritten_instruction": "Increase the brightness of the living room light."
}

Training Details

Training Data

The model was trained on private, domain-specific dialogue data collected from our own smart home central display scenarios. Due to privacy and commercial constraints, the dataset cannot be publicly released. This model card provides a representative example only to illustrate the data format and task definition. No personally identifiable information (PII) is included in the released example.

The training data is formatted as instruction-following samples. Each sample contains:

• instruction: A system-level task instruction that defines the role of the dialogue query rewriting expert, the core task, scenario principles, context-dependency rules, special-case handling rules, and output format constraints.
• input: A multi-turn dialogue history represented as a list of messages. Each message contains a role (user or assistant) and content.
• output: The final rewritten query that the model should generate for the last user turn.

Data Format Example

{
  "instruction": "You are an intelligent dialogue query rewriting expert...",
  "input": [
    {"role": "user", "content": "- User: 查询家庭健康" \n -Bot: 请问您想查询哪位家庭成员的什么健康项目"\n -User: 查一下我爸的 \n -Bot: 好的，请问想查询血压、血糖还是心率\n -User: 血压\n-Bot:请问需要查询哪个时间范围的\n -User: 今天的 \n\n -Output:"}
  ],
  "output": "查一下我爸今天的血压"
}


## Limitations and Risks

- Performance may degrade on out-of-domain utterances, rare devices, or unseen rule combinations.
- Ambiguous or conflicting user intents may require system-level disambiguation.
- Dynamic rules must be validated to avoid unsafe or contradictory instructions.
- The model should not be used as the sole decision-maker in safety-critical scenarios.
- Privacy and security risks should be handled at the system level when processing user dialogue data.



## Citation

If you use this model, please cite:

```bibtex
@misc{mavis8368,
  title = {Instruction-Oriented Multi-Turn Dialogue Rewriting Model for Smart Home Central Displays},
  author = {mavis8368},
  year = {2026},
  howpublished = {\url{https://huggingface.co/mavis8368/Xing4.0-29B-A4B-MTDR}}
}