Modelpublic

hassanabdel/llama-3.2-3b-support-ticket-lora

sourceHugging Faceupdated 24d agoView on Hugging Face

0likes24downloads

Model Card

Llama 3.2 3B Customer Support Ticket LoRA

A LoRA adapter fine-tuned from `meta-llama/Llama-3.2-3B-Instruct` for structured customer-support ticket analysis.

The adapter is designed to analyze a customer-support conversation and produce a structured JSON response containing ticket triage, function/tool selection, internal analysis, and a customer-facing draft response.

This repository contains a LoRA adapter, not a standalone model. The adapter must be loaded with the exact base model specified below.

Model Details

Property	Value
Base model	`meta-llama/Llama-3.2-3B-Instruct`
Fine-tuning method	Supervised Fine-Tuning (SFT)
Adapter	LoRA
Quantization	4-bit
Framework	LlamaFactory
Sequence length	1024
Epochs	3
LoRA rank	8
LoRA alpha	16
LoRA dropout	0.05

Intended Task

The model is trained to transform customer-support tickets into structured operational information.

Given a ticket containing:

—Customer name
—Conversation history
—Current customer message

the model produces:

1.Triage
2.Department
3.Priority
4.Sentiment
5.Estimated resolution time

1.Function call
2.Function/tool name
3.Function arguments

1.Internal notes
2.Issue category
3.Root cause analysis
4.Suggested solution steps

1.Draft response
2.Tone
3.Customer-facing email body
4.Actions required from the customer

Input Format

The model is trained using the following input structure:

json

{
  "ticket": {
    "customer": "Customer Name",
    "history": [
      {
        "role": "customer",
        "content": "Previous customer message"
      },
      {
        "role": "agent",
        "content": "Previous agent response"
      }
    ],
    "current_message": "Current customer message"
  }
}

Important

The following dataset fields are not provided to the model as input:

—ticket_id
—domain
—issue_types

These fields may exist in the underlying dataset for organization and evaluation purposes, but they are intentionally excluded from the model input.

Output Format

The expected output is a JSON object with the following structure:

json

{
  "triage": {
    "department": "string",
    "priority": "low | medium | high | critical",
    "sentiment": "string",
    "estimated_resolution_time": "string"
  },
  "function_call": {
    "name": "string",
    "arguments": {}
  },
  "internal_notes": {
    "issue_category": "string",
    "root_cause_analysis": "string",
    "suggested_solution_steps": [
      "string"
    ]
  },
  "draft_response": {
    "tone": "string",
    "email_body": "string",
    "actions_required_from_customer": "string"
  }
}

Output Schema

`triage`

Provides an initial classification of the ticket.

json

{
  "department": "billing",
  "priority": "medium",
  "sentiment": "neutral",
  "estimated_resolution_time": "2 business days"
}

`function_call`

Specifies the function or tool that should be used and the arguments required to execute it.

json

{
  "name": "initiate_refund",
  "arguments": {
    "order_id": "QB12345678",
    "amount": 2.5
  }
}

The model predicts the function call. It does not execute external functions itself.

The application or agent layer should validate the generated arguments and execute the corresponding function.

`internal_notes`

Contains structured reasoning intended for internal support workflows.

json

{
  "issue_category": "billing_dispute",
  "root_cause_analysis": "The system may have automatically applied a standard service fee.",
  "suggested_solution_steps": [
    "Locate the order in the system",
    "Confirm whether the service fee applies",
    "Process a refund if the fee was incorrectly applied"
  ]
}

`draft_response`

Contains the customer-facing response.

json

{
  "tone": "neutral",
  "email_body": "Hello Noah,

Thank you for contacting us...",
  "actions_required_from_customer": "None"
}

Architecture

The intended production architecture separates model reasoning from tool execution:

text

Customer Support Ticket
        │
        ▼
┌─────────────────────────┐
│ Fine-tuned Llama 3.2 3B │
│                         │
│ • Ticket analysis       │
│ • Triage                │
│ • Classification        │
│ • Function selection    │
│ • Argument extraction   │
│ • Draft response        │
└────────────┬────────────┘
             │
             ▼
      Structured JSON
             │
             ▼
┌─────────────────────────┐
│ Agent / Backend Layer   │
│                         │
│ • Validate arguments    │
│ • Apply permissions     │
│ • Execute functions     │
│ • Handle API/database   │
└─────────────────────────┘

This adapter is therefore intended to be one component inside a larger customer-support agent system.

Training

The model was fine-tuned using:

—Base model: meta-llama/Llama-3.2-3B-Instruct
—Training method: Supervised Fine-Tuning (SFT)
—Parameter-efficient fine-tuning: LoRA
—Quantization: 4-bit QLoRA
—Epochs: 3
—LoRA rank: 8
—LoRA alpha: 16
—LoRA dropout: 0.05
—Maximum sequence length: 1024
—Training framework: LlamaFactory

The training dataset consists of customer-support ticket examples paired with their expected structured JSON responses.

Loading the Adapter

Install the required libraries:

bash

pip install transformers peft accelerate bitsandbytes

Then load the adapter with the base model:

python

import torch

from transformers import (
    AutoModelForCausalLM,
    AutoTokenizer,
)
from peft import PeftModel


BASE_MODEL = "meta-llama/Llama-3.2-3B-Instruct"
ADAPTER = "hassanabdel/llama-3.2-3b-support-ticket-lora"


tokenizer = AutoTokenizer.from_pretrained(
    BASE_MODEL
)

model = AutoModelForCausalLM.from_pretrained(
    BASE_MODEL,
    torch_dtype=torch.float16,
    device_map="auto"
)

model = PeftModel.from_pretrained(
    model,
    ADAPTER
)

model.eval()

Example Input

python

ticket = {
    "ticket": {
        "customer": "Noah",
        "history": [
            {
                "role": "customer",
                "content": "I was charged an extra service fee on my order."
            },
            {
                "role": "agent",
                "content": "Could you provide your order number so I can check the charge?"
            }
        ],
        "current_message": "My order number is QB12345678. The extra $2.50 fee shouldn't have been charged."
    }
}

The model should analyze this ticket and return a structured JSON response following the output schema.

Example Output

json

{
  "triage": {
    "department": "billing",
    "priority": "medium",
    "sentiment": "neutral",
    "estimated_resolution_time": "2 business days"
  },
  "function_call": {
    "name": "initiate_refund",
    "arguments": {
      "order_id": "QB12345678",
      "amount": 2.5
    }
  },
  "internal_notes": {
    "issue_category": "billing_dispute",
    "root_cause_analysis": "The system may have automatically applied a standard service fee that needs to be verified.",
    "suggested_solution_steps": [
      "Locate the order in the system",
      "Confirm whether the service fee applies",
      "Process a refund if the fee was incorrectly applied"
    ]
  },
  "draft_response": {
    "tone": "neutral",
    "email_body": "Hello Noah,

Thank you for providing your order number. We will review the additional service fee and verify whether it was correctly applied.",
    "actions_required_from_customer": "None"
  }
}

The exact output will depend on the ticket.

Function Calling

The adapter is trained to select and describe the function that should be executed.

For example:

json

{
  "function_call": {
    "name": "initiate_refund",
    "arguments": {
      "order_id": "QB12345678",
      "amount": 2.5
    }
  }
}

The model does not directly call the function.

A production application should:

1.Parse the model's JSON.
2.Validate the function name.
3.Validate the arguments.
4.Apply authorization/business rules.
5.Execute the function.
6.Return the result to the agent workflow.

This separation prevents the model from having direct unrestricted access to external systems.

Limitations

Adapter, not standalone model

This repository contains only the LoRA adapter.

It requires:

text

meta-llama/Llama-3.2-3B-Instruct

The base model may require appropriate access approval and authentication through Hugging Face.

Structured output is not guaranteed

Although the model is trained to produce the specified JSON structure, generated text from an LLM is not inherently guaranteed to be valid JSON.

Production applications should validate the output against the expected schema before using it.

Function execution

The adapter only predicts the function call and arguments. It does not execute tools, APIs, database operations, refunds, account changes, or other external actions.

Domain limitations

The adapter is specialized for customer-support ticket analysis based on its training data. Performance may decrease on domains, workflows, or function types that are substantially different from the training distribution.

Recommended Production Pipeline

A production implementation should use the adapter approximately as follows:

text

                    ┌──────────────────┐
                    │ Customer Message │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │ Conversation     │
                    │ History          │
                    └────────┬─────────┘
                             │
                             ▼
                 ┌───────────────────────┐
                 │ Llama 3.2 3B + LoRA  │
                 └───────────┬───────────┘
                             │
                             ▼
                     Structured JSON
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
           Triage      Function Call    Draft Reply
                             │
                             ▼
                   Validation / Policy
                             │
                             ▼
                      Tool Execution
                             │
                             ▼
                    Tool/API Result
                             │
                             ▼
                     Support Workflow

License

This adapter is derived from meta-llama/Llama-3.2-3B-Instruct.

Users are responsible for complying with the license and usage terms of the base model, including the applicable Llama 3.2 Community License.

See the base model page for the latest licensing and usage information:

https://huggingface.co/meta-llama/Llama-3.2-3B-Instruct

Acknowledgements

—Meta AI for the Llama 3.2 model family
—LlamaFactory for the fine-tuning framework
—Hugging Face for model hosting and the Transformers/PEFT ecosystem

Repository

Hugging Face:

hassanabdel/llama-3.2-3b-support-ticket-lora