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

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

Design patterns are reusable solutions to common problems in software design. 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 particularly useful in AI and machine learning contexts, along with Python examples.

Why Design Patterns Matter for AI Engineers

AI systems often involve:

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

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

• Creational Patterns: Focus on object creation. (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 a class has only one instance and provides a global access point to that instance. This is especially valuable in AI workflows where shared resources—like configuration settings, logging systems, or model instances—must be consistently managed without redundancy.

When to Use

• Managing 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.

Implementation

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 point to the same instance, making all configurations globally accessible and consistent.
3. AI Use Case: Use this pattern to manage global settings like paths to datasets, logging configurations, or environment variables.

2. Factory Pattern

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

When to Use

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

Implementation

Let’s build a Factory for creating models for different AI tasks, like 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 task type and creates an instance.
3. Extensibility: Adding a new model type is straightforward—just implement a new subclass and update the factory’s task_mapping.

AI Use Case

Imagine you are 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 extend the system as new models become available without modifying existing code.

3. Builder Pattern

The Builder Pattern separates the construction of a complex object from its representation. It is useful when an object involves multiple steps to initialize or configure.

When to Use

• Building multi-step pipelines (e.g., data preprocessing).
• Managing configurations for experiments or model training.
• Creating objects that require a lot of parameters, ensuring readability and maintainability.

Implementation

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 allows chaining for an intuitive and compact syntax when defining pipelines.
2. Step-by-Step Execution: The pipeline processes data by running it through each step in sequence.
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 the behavior to change dynamically at runtime. This is especially useful in AI systems where the same process (e.g., inference or data processing) might require different approaches depending on the context.

When to Use

• Switching between different inference strategies (e.g., batch processing vs. streaming).
• Applying different data processing techniques dynamically.
• Choosing resource management strategies based on available infrastructure.

Implementation

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: Each strategy (e.g., BatchInference, StreamInference) implements the logic specific to that approach.
3. Dynamic Switching: The InferenceContext allows switching strategies at runtime, offering 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 its 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 like accuracy or loss during model training.
• Real-time updates for dashboards or logs.
• Managing dependencies between components in complex workflows.

Implementation

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 notifies them when its state changes. In this example, the ModelMonitor class tracks metrics.
2. Observers: Perform specific actions when notified. For instance, the LoggerObserver logs metrics, while the AlertObserver raises alerts if a threshold is breached.
3. Decoupled Design: Observers and subjects are loosely coupled, making the system modular and extensible.

How Design Patterns Differ for AI Engineers vs. Traditional Engineers

Design patterns, while universally applicable, take on unique characteristics when implemented in AI engineering compared to traditional software engineering. The difference lies in the challenges, goals, and workflows intrinsic to AI systems, which often demand patterns to be adapted or extended beyond their conventional uses.

1. Object Creation: Static vs. Dynamic Needs

• Traditional Engineering: Object creation patterns like 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 Engineering: Object creation often involves dynamic workflows, such as:
  • Creating models on-the-fly based on user input or system requirements.
  • Loading different model configurations for tasks like translation, summarization, or classification.
  • Instantiating multiple data processing pipelines that vary by dataset characteristics (e.g., tabular vs. unstructured text).

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

2. Performance Constraints

• Traditional Engineering: Design patterns are typically optimized for latency and throughput in applications like web servers, database queries, or UI rendering.
• AI Engineering: Performance requirements in AI extend to model inference latency, GPU/TPU utilization, and memory optimization. Patterns must accommodate:
  • Caching intermediate results to reduce redundant computations (Decorator or Proxy patterns).
  • Switching algorithms dynamically (Strategy pattern) to balance latency and accuracy based on system load or real-time constraints.

3. Data-Centric Nature

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

4. Experimentation vs. Stability

• Traditional Engineering: Emphasis is on building stable, predictable systems where patterns ensure consistent performance and reliability.
• AI Engineering: AI workflows are often experimental and involve:
  • Iterating on different model architectures or data preprocessing techniques.
  • Dynamically updating system components (e.g., retraining models, swapping algorithms).
  • Extending existing workflows without breaking production pipelines, often using extensible patterns like Decorator or Factory.

Example: A Factory in AI might not only instantiate a model but also attach preloaded weights, configure optimizers, and link training callbacks—all dynamically.

The post Design Patterns in Python for AI and LLM Engineers: A Practical Guide appeared first on Unite.AI.