Design Patterns in Python for AI and LLM Engineers: A Practical Guide

As AI engineers, creating clean, efficient, and maintainable code is critical, especially when building complex systems.

Design patterns are reusable solutions to common software design problems. For AI and Large Language Model (LLM) engineers, design patterns help build robust, scalable, and maintainable systems that handle complex workflows efficiently. This article dives into design patterns in Python, focusing on their relevance in AI and LLM-based systems. I’ll explain each pattern with practical AI use cases and Python code examples.

Let’s explore some key design patterns that are especially useful in AI and machine learning contexts, along with Python examples.

Why design patterns are important for AI engineers

AI systems often include:

1. Complex object creation (e.g. loading models, data preprocessing pipelines).
2. Managing interactions between components (e.g. model inference, real-time updates).
3. Dealing with scalability, maintainability and flexibility for changing requirements.

Design patterns address these challenges, providing clear structure and reducing ad hoc solutions. They fall into three main categories:

• Creation patterns: Focus on creating objects. (Singleton, factory, builder)
• Structural patterns: Organize the relationships between objects. (Adapter, Decorator)
• Behavioral patterns: Manage communication between objects. (Strategy, observer)

1. Singleton pattern

The Singleton pattern ensures that a class has only one instance and provides a global entry point to that instance. This is especially valuable in AI workflows where shared resources, such as configuration settings, logging systems, or model instances, need to be managed consistently without redundancy.

When to use

• Management of global configurations (e.g. model hyperparameters).
• Sharing resources across multiple threads or processes (e.g. GPU memory).
• Ensuring consistent access to a single inference engine or database connection.

Execution

Here’s how to implement a Singleton pattern in Python to manage configurations for an AI model:

class ModelConfig:
    """
    A Singleton class for managing global model configurations.
    """
    _instance = None  # Class variable to store the singleton instance
    def __new__(cls, *args, **kwargs):
        if not cls._instance:
            # Create a new instance if none exists
            cls._instance = super().__new__(cls)
            cls._instance.settings = {}  # Initialize configuration dictionary
        return cls._instance
    def set(self, key, value):
        """
        Set a configuration key-value pair.
        """
        self.settings[key] = value
    def get(self, key):
        """
        Get a configuration value by key.
        """
        return self.settings.get(key)
# Usage Example
config1 = ModelConfig()
config1.set("model_name", "GPT-4")
config1.set("batch_size", 32)
# Accessing the same instance
config2 = ModelConfig()
print(config2.get("model_name"))  # Output: GPT-4
print(config2.get("batch_size"))  # Output: 32
print(config1 is config2)  # Output: True (both are the same instance)

Explanation

1. The __new__ Method: This ensures that only one instance of the class is created. If an instance already exists, it returns the existing one.
2. Shared state: Both config1 And config2 refer to the same instance, making all configurations globally accessible and consistent.
3. AI use case: Use this pattern to manage common settings such as paths to datasets, logging configurations, or environment variables.

2. Factory pattern

The Factory pattern provides a way to delegate object creation to subclasses or special factory methods. In AI systems, this pattern is ideal for dynamically creating different types of models, data loaders, or pipelines based on context.

When to use

• Dynamically create models based on user input or task requirements.
• Manage complex object creation logic (e.g. multi-step preprocessing pipelines).
• Decoupling object instantiation from the rest of the system to improve flexibility.

Execution

Let’s build a factory for creating models for various AI tasks such as text classification, summarization and translation:

class BaseModel:
    """
    Abstract base class for AI models.
    """
    def predict(self, data):
        raise NotImplementedError("Subclasses must implement the `predict` method")
class TextClassificationModel(BaseModel):
    def predict(self, data):
        return f"Classifying text: {data}"
class SummarizationModel(BaseModel):
    def predict(self, data):
        return f"Summarizing text: {data}"
class TranslationModel(BaseModel):
    def predict(self, data):
        return f"Translating text: {data}"
class ModelFactory:
    """
    Factory class to create AI models dynamically.
    """
    @staticmethod
    def create_model(task_type):
        """
        Factory method to create models based on the task type.
        """
        task_mapping = {
            "classification": TextClassificationModel,
            "summarization": SummarizationModel,
            "translation": TranslationModel,
        }
        model_class = task_mapping.get(task_type)
        if not model_class:
            raise ValueError(f"Unknown task type: {task_type}")
        return model_class()
# Usage Example
task = "classification"
model = ModelFactory.create_model(task)
print(model.predict("AI will transform the world!"))
# Output: Classifying text: AI will transform the world!

Explanation

1. Abstract base class: The BaseModel class defines the interface (predict) that all subclasses must implement, ensuring consistency.
2. Factory logic: The ModelFactory dynamically selects the appropriate class based on the job type and creates an instance.
3. Extensibility: Adding a new model type is easy: just implement a new subclass and update it from the factory task_mapping.

AI use case

Imagine designing a system that selects a different LLM (e.g. BERT, GPT or T5) based on the task. The Factory pattern makes it easy to expand the system as new models become available, without changing the existing code.

3. Builder pattern

The Builder pattern separates the construction of a complex object from its representation. This is useful when an object requires multiple steps to initialize or configure.

When to use

• Building multi-step pipelines (e.g. data preprocessing).
• Manage configurations for experiments or model training.
• Create objects that require many parameters, ensuring readability and maintainability.

Execution

Here’s how to use the Builder pattern to create a data preprocessing pipeline:

class DataPipeline:
    """
    Builder class for constructing a data preprocessing pipeline.
    """
    def __init__(self):
        self.steps = []
    def add_step(self, step_function):
        """
        Add a preprocessing step to the pipeline.
        """
        self.steps.append(step_function)
        return self  # Return self to enable method chaining
    def run(self, data):
        """
        Execute all steps in the pipeline.
        """
        for step in self.steps:
            data = step(data)
        return data
# Usage Example
pipeline = DataPipeline()
pipeline.add_step(lambda x: x.strip())  # Step 1: Strip whitespace
pipeline.add_step(lambda x: x.lower())  # Step 2: Convert to lowercase
pipeline.add_step(lambda x: x.replace(".", ""))  # Step 3: Remove periods
processed_data = pipeline.run("  Hello World. ")
print(processed_data)  # Output: hello world

Explanation

1. Chained methods: The add_step method enables chaining for an intuitive and compact syntax when defining pipelines.
2. Step-by-step implementation: The pipeline processes data by executing each step in order.
3. AI use case: Use the Builder pattern to create complex, reusable data preprocessing pipelines or model training setups.

4. Strategy pattern

The Strategy pattern defines a family of interchangeable algorithms, encapsulating each one and allowing its behavior to change dynamically at runtime. This is especially useful in AI systems where the same process (e.g. inference or data processing) may require different approaches depending on the context.

When to use

• Switching between different inference strategies (e.g. batch processing versus streaming).
• Dynamic application of different data processing techniques.
• Choose resource management strategies based on available infrastructure.

Execution

Let’s use the Strategy Pattern to implement two different inference strategies for an AI model: batch inference and streaming inference.

class InferenceStrategy:
    """
    Abstract base class for inference strategies.
    """
    def infer(self, model, data):
        raise NotImplementedError("Subclasses must implement the `infer` method")
class BatchInference(InferenceStrategy):
    """
    Strategy for batch inference.
    """
    def infer(self, model, data):
        print("Performing batch inference...")
        return [model.predict(item) for item in data]
class StreamInference(InferenceStrategy):
    """
    Strategy for streaming inference.
    """
    def infer(self, model, data):
        print("Performing streaming inference...")
        results = []
        for item in data:
            results.append(model.predict(item))
        return results
class InferenceContext:
    """
    Context class to switch between inference strategies dynamically.
    """
    def __init__(self, strategy: InferenceStrategy):
        self.strategy = strategy
    def set_strategy(self, strategy: InferenceStrategy):
        """
        Change the inference strategy dynamically.
        """
        self.strategy = strategy
    def infer(self, model, data):
        """
        Delegate inference to the selected strategy.
        """
        return self.strategy.infer(model, data)
# Mock Model Class
class MockModel:
    def predict(self, input_data):
        return f"Predicted: {input_data}"
# Usage Example
model = MockModel()
data = ["sample1", "sample2", "sample3"]
context = InferenceContext(BatchInference())
print(context.infer(model, data))
# Output:
# Performing batch inference...
# ['Predicted: sample1', 'Predicted: sample2', 'Predicted: sample3']
# Switch to streaming inference
context.set_strategy(StreamInference())
print(context.infer(model, data))
# Output:
# Performing streaming inference...
# ['Predicted: sample1', 'Predicted: sample2', 'Predicted: sample3']

Explanation

1. Abstract strategy class: The InferenceStrategy defines the interface that all strategies must follow.
2. Concrete Strategies: Any strategy (e.g. BatchInference, StreamInference) implements the logic specific to that approach.
3. Dynamic switching: The InferenceContext enables switching strategies at runtime and provides flexibility for different use cases.

When to use

• Switch between batch inference for offline processing and streaming inference for real-time applications.
• Dynamically adjust data augmentation or preprocessing techniques based on the task or input format.

5. Observer pattern

The Observer pattern establishes a one-to-many relationship between objects. When one object (the subject) changes state, all dependents (observers) are automatically notified. This is particularly useful in AI systems for real-time monitoring, event handling, or data synchronization.

When to use

• Monitoring metrics such as accuracy or loss during model training.
• Real-time updates for dashboards or logs.
• Manage dependencies between components in complex workflows.

Execution

Let’s use the Observer Pattern to monitor the performance of an AI model in real time.

class Subject:
    """
    Base class for subjects being observed.
    """
    def __init__(self):
        self._observers = []
    def attach(self, observer):
        """
        Attach an observer to the subject.
        """
        self._observers.append(observer)
    def detach(self, observer):
        """
        Detach an observer from the subject.
        """
        self._observers.remove(observer)
    def notify(self, data):
        """
        Notify all observers of a change in state.
        """
        for observer in self._observers:
            observer.update(data)
class ModelMonitor(Subject):
    """
    Subject that monitors model performance metrics.
    """
    def update_metrics(self, metric_name, value):
        """
        Simulate updating a performance metric and notifying observers.
        """
        print(f"Updated {metric_name}: {value}")
        self.notify({metric_name: value})
class Observer:
    """
    Base class for observers.
    """
    def update(self, data):
        raise NotImplementedError("Subclasses must implement the `update` method")
class LoggerObserver(Observer):
    """
    Observer to log metrics.
    """
    def update(self, data):
        print(f"Logging metric: {data}")
class AlertObserver(Observer):
    """
    Observer to raise alerts if thresholds are breached.
    """
    def __init__(self, threshold):
        self.threshold = threshold
    def update(self, data):
        for metric, value in data.items():
            if value > self.threshold:
                print(f"ALERT: {metric} exceeded threshold with value {value}")
# Usage Example
monitor = ModelMonitor()
logger = LoggerObserver()
alert = AlertObserver(threshold=90)
monitor.attach(logger)
monitor.attach(alert)
# Simulate metric updates
monitor.update_metrics("accuracy", 85)  # Logs the metric
monitor.update_metrics("accuracy", 95)  # Logs and triggers alert

1. Subject: Manages a list of observers and alerts them when their status changes. In this example the ModelMonitor class keeps statistics.
2. Observers: Take specific actions when notified. For example the LoggerObserver logs statistics, while the AlertObserver warns if a threshold is exceeded.
3. Decoupled design: Observers and subjects are loosely coupled, making the system modular and expandable.

How design patterns differ for AI engineers versus traditional engineers

Although design patterns are universally applicable, they take on unique characteristics when implemented in AI engineering compared to traditional software engineering. The difference lies in the challenges, goals, and workflows inherent in AI systems, which often require patterns to be adapted or extended beyond their conventional use.

1. Object creation: static versus dynamic needs

• Traditional technique: Object creation patterns, such as Factory or Singleton, are often used to manage configurations, database connections, or user session states. These are generally static and well defined during system design.
• AI technology: Creating objects is often about dynamic workflowssuch as:
  • Create models on-the-fly based on user input or system requirements.
  • Load different model configurations for tasks such as translation, summarization, or classification.
  • Instantiating multiple data processing pipelines that vary based on the characteristics of the dataset (for example, tabular versus unstructured text).

Example: In AI, a factory pattern can dynamically generate a deep learning model based on the task type and hardware constraints, while in traditional systems it can simply generate a user interface component.

2. Performance Limitations

• Traditional technique: Design patterns are typically optimized for latency and throughput in applications such as web servers, database queries, or UI rendering.
• AI technology: Performance requirements in AI extend to model inference latency, GPU/TPU usage and memory optimization. Patterns must be suitable for:
  • Cache intermediate results to reduce redundant computations (Decorator or Proxy patterns).
  • Dynamically switch between algorithms (Strategy Pattern) to balance latency and accuracy based on system load or real-time constraints.

3. Data-centric nature

• Traditional technique: Patterns often operate on fixed input-output structures (e.g. forms, REST API responses).
• AI technology: Patterns need to interact variability of data both in structure and scale, including:
  • Streaming data for real-time systems.
  • Multimodal data (e.g. text, images, videos) require pipelines with flexible processing steps.
  • Large-scale datasets that require efficient preprocessing and augmentation pipelines, often using patterns such as Builder or Pipeline.

4. Experimentation versus stability

• Traditional technique: The emphasis is on building stable, predictable systems where patterns ensure consistent performance and reliability.
• AI technology: AI workflows often are experimental and involve:
  • Iterating on different model architectures or data preprocessing techniques.
  • Dynamically update system components (e.g. retraining models, exchanging algorithms).
  • Extending existing workflows without disrupting production pipelines, often using extensible patterns such as Decorator or Factory.

Example: A Factory in AI can not only instantiate a model, but also add preloaded weights, configure optimizers, and chain training callbacks – all dynamically.