For this I selected the MIMII dataset (malfunctioning industrial machine investigation and inspection). This dataset contains several industrial machine sounds (fan, pump, valve). Each is labeled as normal or abnormal operation. The challenge is to build a model that can label the incoming audio to predict whether the machine is in a normal or abnormal state.

I built a CNN-based autoencoder model — an unsupervised architecture that learns two functions: an encoder that compresses the input into a compact representation, and a decoder that reconstructs the original input from that representation. The goal is to learn an efficient internal encoding of the data without requiring labeled examples.

In my concrete use case, this means I first trained only on normal data. The loss of the model’s output is low. Then, if I give the model an abnormal audio sample, the loss should be high, since it does not know how to decode abnormal samples.

I first preprocessed the data with Torchaudio’s mel spectrogram. A spectrogram shows the frequencies that make up the sound, from low to high, and how they change over time, from left to right. Then I forwarded this image to the CNN model. I used the PyTorch's implementation. The model got progressively downsampled.

I got 0.98 AUC on the fan id_02 dataset compared to a baseline AUC of 0.99 reported in research paper. Using a trivial model like measuring loudness, I got only 0.40 AUC on the fan dataset.

I used wandb to track training metrics and experiment with different thresholds, but eventually I set the threshold at the 90th percentile of reconstruction error on normal data — any sample with higher loss is flagged as anomalous.

Eventually I exported the model to ONNX format and I published it to Hugging Face Space using the Gradio frontend library. As is visible in the Hugging Face repository I also dockerized and published the model with FastAPI. Lastly I added Prometheus and Grafana in order to experiment with metrics collection.

In this project I tried to use as many professional tools as possible.

• Weights & Biases (W&B): Learned to track training runs, compare hyperparameter sweeps, and visualize threshold selection instead of relying on printed logs.

• ONNX: Learned to export a PyTorch model into a framework-agnostic format for portable inference outside the training environment.

• Gradio: Learned to wrap a model in a minimal web UI.

• FastAPI: Learned to expose the model as a REST endpoint.

• Prometheus+Grafana: Learned to collect, store and visualize live inference metrics from a running service

Most of them were so-called ‘unknown unknowns’, meaning I did not even know that they existed. With this challenge next time I will be able to use these tools more thoughtfully.

I mostly relied on the “Derivation of backpropagation in convolutional neural network (cnn)” paper by Zhang, Zhifei.1

Why from scratch?

I want to understand the inner mechanisms of neural networks. Using high-level libraries (such as PyTorch) without understanding what happens internally can lead to the illusion of understanding. One might start to believe that building a neural network is simply a matter of writing a few lines of code, rather than understanding the underlying concepts. Implementing a model from scratch makes these computations explicit and exposes details that would otherwise be hidden.

Why in rust?

I selected rust because I am already quite fluent in C# and wanted to learn a programming language with zero cost abstraction. C++ has a messy ecosystem, I think the ecosystem would have taken away the focus from the already hard system-programming-language concepts. In hindsight I had zero difficulty with Rust’s ecosystem, so my choice seems to be justified.

The model:

This figure defines a CNN model with 2 convolutional layer with sigmoid activation layer and two average pooling layer, and one linear layer.

1. The first convolution layer’s kernel has 1 channel, 6 filters and the size is 5x5.

2. The pooling layer averages each 2×2 region into a single value, halving the input in both height and width

3. The second convolution layer’s kernel has 6 channel, 12 filters and the size of 5x5

4. The same average pooling layer as the first one

5. The final linear network part has 10x192 size meaning it takes 192 input and converts it to 10 output corresponding to the 10 digits.

6. Although the paper uses sigmoid activation in the final layer with mean squared error cost function, I decided to use cross entropy loss with softmax function.

The model did not visibly overfit. Possible contributing factors are small parameter count (3898), polling layer discarding image noise, and Xavier initialization stabilizing early training.

I tried to write a relatively clean code for easily model extendibility. Being my first Rust project, I was not able to write fully idiomatic code — for example, I relied on .clone() more than ownership rules would require. Still I managed a clean extendable code:

        let kernel: Array4<f32> = {
            xavier2(&[1, 6, 5, 5]) // [channel, filter, height, width
                                   // as in the model description figure: 
                                   // 1 channel, 6 filter, 5x5
                .into_dimensionality::<ndarray::Ix4>()
                .expect("kernel initialization failed")
        };

        let kernel2: Array4<f32> = {
            xavier2(&[6, 12, 5, 5])
                .into_dimensionality::<ndarray::Ix4>()
                .expect("kernel initialization failed")
        };

        let layers: Vec<Box<dyn CnnLayerable>> = vec![
            Box::new(ConvolutionalMatlab::new(kernel, alpha)),
            Box::new(CnnSigmoidActivation::new()),
            Box::new(CnnPoolingLayer::new()),
            Box::new(ConvolutionalMatlab::new(kernel2, alpha)),
            Box::new(CnnSigmoidActivation::new()),
            Box::new(CnnPoolingLayer::new()),
        ];
        let linear_layers: Vec<Box<dyn Layerable>> = vec![
            Box::new(Layer::new(192, 10, alpha)),
            //Box::new(ActivationLayer::sigmoid())-> I removed for cross entropy loss + softmax
        ];

In the code above I show that adding a new layer is only a adding an extra line of code.

//For linear layers
pub trait Layerable: fmt::Debug{
    fn forward(&mut self, x: &Array2<f32>) -> Array2<f32>;
    fn backward_propagation(&mut self, dc_da: &Array2<f32>) -> Array2<f32>;
}
//For convolutional layers
pub trait CnnLayerable: fmt::Debug{
    fn forward_propagation(&mut self, x: &ImageData) -> Array3<f32>;
    fn backward_propagation(&mut self, delta_c: &ImageData) -> Array3<f32>;
}

I made it extensible using traits. Each layer implements one of these traits. For forward propagation, I simply execute forward_propagation on each layer in order, for backpropagation, I call backward_propagation in reverse.

With a linear neural network, using 2D matrices for inputs and outputs seemed reasonable. Only when I started implementing the convolutional part did I realize that a CNN actually needs 3D matrices. I didn’t want to break my working code, so I created a new trait. By the end of the project, I also realized that for better performance I should be using 4D matrices (the extra dimension being the batch size). If I rewrote this project, I would be using a single trait that works across different matrix dimensions.

CNN Insights:

• I realized that the standard CNN implementations most of the time does not utilize convolution, but cross correlation. The difference being that cross correlation does not mirrors the kernel. It has no practical effect on the training but still important to pinpoint out for mathematical correctness.

• Most of the time the neural network is depicted the following way. This is actually wrong. In reality every node has a bias term.

• As I already implemented the linear network part, I knew how subtle bugs can be in backpropagation. To minimalize the headache I added gradient check as a unit test. It is basically a mathematically proved “debugging tool”. It works by comparing the analytical gradients (computed by backprop) against numerical gradients (approximated using small perturbations to the weights). If the two match closely, your backprop is likely correct. If they don't, you know there's a bug in your derivative calculations.

• Gradient check helped me identifying a bug in my sigmoid activation layer. Although the loss function’s value decreased in the first hundred epochs it started to grow significantly afterwards. At first I thought it must have happened because of the learning rate being too great. Eventually it turned out that I implemented the sigmoid activation function incorrectly.

  The correct equation would be:

  delta_l = sigma'(a_l) ⊙ delta_(l+1)

  Where a_l is the cached output of the forward pass and delta_(l+1) is the incoming gradient from the next layer and sigma’() is the sigmoid’s derivative function.
  Instead of the equation above I implemented the following equation

  delta_l = sigma'(delta_(l+1))

Rust insights:

I enjoyed to program in rust. It clarified a lot in the inner working of C# as well. Such clarifications were:

• In C#, interface dispatch is always virtual (runtime). In Rust you choose explicitly: dyn Trait gives dynamic dispatch via a fat pointer (data pointer + vtable pointer, type erased), impl Trait or a generic <T: Trait> gives static dispatch, where the compiler generates a separate concrete function per type at compile time.

• I C# the garbage collector collects the unused references automatically. It guarantees memory safety on the expense of performance. With rust adhering to a few rules you can have a same effect without performance erosion. It takes a while until one get use to these rules. However all effort is compensated in the moment of running the application in release mode knowing that language’s abstractions have no runtime overhead.

Then I started a project to build a simple equation parser to convert expressions into an abstract syntax tree for calculating the expression. (Supporting + - * / and () operators with * / having operator precedence)

I tried to minimize the help coming from outer sources and maximize my own ingenuity. I only knew the application should have a string mathematical expression as an input and its result as output. My only clue for building a tree structure was the project name itself. It took multiple attempts before I figured out what a reasonable architecture could be. Initially I thought I can finish it within a few hours, eventually I needed a week with a few hours of work every day.

Learning about F# (or another functional programming language alike) helps a lot adopting modern C# techniques. It is not a coincidence that most of the modern C# features are actually coming from the functional paradigm. (lambda, higher order function, records, switch expression).

Functional Programming (FP) and Object-Oriented Programming (OOP) solve the same problems using fundamentally different abstractions. I felt as if I had to adopt a new thinking, orthogonal to the typical OOP solution.

OOP emphasizes nouns. What should achieve something, the verbs (methods) can only exist in relation to the noun. It tends to be stateful because it models systems as objects that change their internal data over time. Any instance method has implicitly the this parameter allowing changes in the object state.

On the other hand FP emphasizes verbs that act on immutable data transformations rather than state changes. It transforms, combines, or analyzes data without causing side effects.

What I like more in FP:

* No exceptions but discriminated unions: Exceptions are avoided in functional programming because hidden outputs break referential transparency. FP utilizes the Result pattern, where a function returns either a value or an error type. On the caller side, you must use pattern matching to handle every case. While this remotely resembles “throwing and catching an exception,” there is a fundamental difference. With exception the return type does not encode the error case. You no longer get a well-defined result from the method because errors are not part of the return type. I believe the Java development team tried to solve this by adding checked exceptions. However, this approach makes things worse, as checked exceptions violate the Open/Closed Principle. Every intermediate layer must be adjusted when changes occur, even if it doesn’t handle the error itself. In C#, a common solution is using helper NuGet packages such as OneOf.

Example:

//typical approach

public int BusinessLogic(Tree<AstNode> tree){
    //If cannot cast exception is thrown
    //The method no longer has a well defined behavior for every input
    //The unhappy paths can be handled with statements
    Operator op = (Operator)tree;
    //logic

}

let rec CalculateTree (tree: Tree<AstNode>) =
    match tree with
    | Leaf(Number n) -> Ok n
    | Node(Operator operator, left, right) ->
        match CalculateTree left, CalculateTree right with
        | Ok l, Ok r -> Ok(operator.Calculate l r)
        | _ -> Error “Incorrect abstract syntax tree”
    | _ -> Error “Incorrect abstract syntax tree”

# Consume:

    match CalculateTree lastOperator with
    | Ok resultValue -> printfn $”Happy path the number is: %d{resultValue}”
    | Error errorValue -> printfn $”Unhappy path, %s{errorValue}”

//Psuedo Result class

public Result<int> BusinessLogic(Tree<AstNode> tree){
    Operator op = tree as Operator;
    if(op is null) {
        return Errors(“unhappy path with an error”)
    }
    //logic
    return Ok(number);

}

public void Calculate(){
    var result = BusinessLogic(MyAstNodes);
    if(result.IsError){

    }
}

* Higher order function: until I learned about functional programming I didn’t realize that higher order functions can replace most of the popular programming loops. I over used for loops when a mapping (select) would have been a much more appropriate choice. I was not aware just how versatile higher-order functions can be.

public IEnumerable<int> MappingWithStatements(IEnumerable<int> myNumbers){
    List<int> returnList = new List<int>();
    foreach(var number in myNumbers){
        if(number == 42){
            //Filtering
            continue;
        }
        var numberWithTransformation = number * 2;
        returnList.Add(numberWithTransformation)
    }
    return returnList;
}

public IEnumerable<int> MappingWithExpression(IEnumerable<int> myNumbers) 
    => myNumbers
        .Where(number => number != 7)
        .Select(number => number*2)

Before reflecting on higher order function I would not realize that these two code describes the same thing, the second using a much concise syntax.

* Pipe operators: C# does not have a universal pipe operator for arbitrary functions, so chained function must be read backwards.

buildTree(getTokens(input).ToList())

let main2 (input: string) =
    input
    |> getTokens
    |> Seq.toList
    |> buildTree

Luckily it doesn’t apply to Linq functions and you can easily define your own mini Pipe operator anyway.

* Statements: Historically C# is a statement based language, but it is moving toward expressions. (opposed to F#). In modern C#, expression should almost always be favored to statements. There is more and more support for expression in every newer version of the language (Such as the switch expression) Of course within reasonable limits, for instance it would be awkward to use .ContinueWith() instead of using await.

What I disliked:

* Recursive functions/learning the loop replacement: Imperative languages rely on a few general-purpose loop constructs, functional programming uses a broader library of specialized higher-order functions and recursion. This requires a steeper initial learning curve, and takes time to get used to recursion but also shifts the developer’s focus from manual iteration logic to high-level data transformation patterns.

let groupTokens (tokens: string list) =
    let rec parse current (remaining: string list) =
        match remaining with
        | [] -> List.rev current, []
        | “)” :: tail -> List.rev current, tail
        | “(” :: tail ->
            let inner, next = parse [] tail
            parse (Group inner :: current) next
        | token :: tail -> parse (Scalar(strToOperator token) :: current) tail

    let result, _ = parse [] tokens
    result

In idiomatic functional programming there are no loops, recursion is used for achieving its effect. It was the first time I have seen this “pattern”. With an immature team it slows the development time down.

My repository is available here.