The greatest challenge in transforming a machine into human form is deciding where to begin. But once that step is taken, the process becomes manageable—as long as you remain hopeful. To stay aligned with my long-term goal while working on smaller tasks, I rely on the following expectations for this model:

• He is expected to know when to lie, question, insult, joke, or return snark and sarcasm.
• His action space #1 at every state must include the intent probability of invoking a second / third / fourth … response, regardless of whether the user is speaking.
• His action space #2 at every state, conditioned on the system, is a Dirichlet distribution over the questioning state, personal hypothesis states, and factual (base model) hypothesis states, incorporating internet-accessible information.
• Any prompt chains used during streams should eventually be replaced by distance models over time windows t to T, extending up to the k-th batch.
• His preferences and individuality should evolve based on his experiences but remain fundamentally tied to me, the primary user.

I’ve come to realise that, despite the vast complexity of human relationships and communication, it all distils down to how we feel. For example, movie ticket sales largely depend on past user feedback. Perhaps emotions are the one human trait that can be quantified and understood by a machine just enough to guide its own decision-making—assuming, of course, that human relationships are left out of the equation.

The underlying framework for these expectations must converge on a unified build, all tied to the emotion inference model. Narrowed down by Tom’s objectives, the inference tasks are:

1. Predicting the user’s responses. This itself is a mapping function from a vector space to the real numbers.
2. Determining his own emotional responses. A mapping function that ranks text embeddings by emotional cues, assisted by observing the user's reactions.

From an application standpoint, the build can be structured as follows:

1. Temporary state models for streaming responses, where previous inferences become the priors for the next state, and their predictions are compared against the next observed value, as briefed in my previous post.
2. Initiation models. This build unifies all currently available emotion prediction models through ensembling or conditional-distance heuristic models. However, I eventually opted for a single classifier trained on the entire corpus. Impatience drove this decision: I wanted to see how the multivariate approach interacted with my other builds, especially the API serving department.

Major Problem

At that time, I couldn’t pinpoint the problem that kept haunting my mind: What is the link between his decision-making and a large language model? If I relied on traditional text models, i.e. probabilistic methods like n-grams, this problem wouldn’t exist, but I would face a new challenge: the vector representations of the text wouldn’t capture any contextual information, relying solely on character or word frequency. That said, you could mitigate this by leveraging PyTorch’s nn.Embedding to initialize vector representations for N tokens, then applying a fixed-size perceptron or a multi-head attention layer—an approach commonly used in text translation tasks.

A good professor once advised me to begin by understanding my thoughts mathematically. Applying this to the connection between a large language model and emotions, I can reframe the problem as follows:

Defining a function f that maps the weight space of language models to another space of my liking.

The next section lists three implementation methods, covering both real-time use and pre-deployment, ranked from hardest to easiest in my assessment.

Methods

1. Geometric Algebra – Merging Representations

This method involves leveraging Geometric Algebra (GA) to unify different vector spaces, effectively merging the learned representations of language models and classifiers.

2. PPO for LLMs – Defining a Reward Function

Using Proximal Policy Optimization (PPO) for tuning large language models (LLMs) involves defining a Reward function that guides the model’s learning process toward desired behaviors. This approach falls under Reinforcement Learning from Human Feedback (RLHF) but requires additional structuring when applied to dynamic emotional reasoning (Link: https://huggingface.co/blog/trl-ddpo).

3. Decoding Sampling Combinations as Generation Control

Controlling how a large language model (LLM) generates responses by trialling a range of decoding parameter combinations. This technique leverages linear programming: systematically experimenting with different parameter configurations to optimise response quality, coherence and diversity, and ultimately to match the emotional cues inferred from the main user. This is then combined with Bayesian statistical models (really just Bayes' rule) to iteratively adapt to new observations.

Method 1: Geometric Algebra

This method focuses on modifying or augmenting the encoder block and the generated-text caches to impose structured constraints, such as temporal memory retention and self-supervised attention shifts, using attention blocks or iterated projection sequences. I approached the mathematical transformation in code by trying to mimic a game developer handling quaternions.

Key highlights:

• Implementing a hierarchical control mechanism that dynamically adjusts response generation parameters based on inferred user intent and historical interactions
• Exploring multi-head attention restructuring, where certain heads are fine-tuned to prioritize different inference strategies (e.g., factual recall vs. emotional adaptation)

I favoured this method, so I spent the most time on it, only to realise, yet again, that I had failed myself. Over the past few years, I’ve focused on programming and application, prioritising deadlines and API builds over theoretical depth. In hindsight, that habit makes it easy to abandon whimsical detours. But if one is bored enough to start solving such a problem (or any maths problem), I always like to begin with my favourite mathematical property: the triangle inequality, a recurring concept throughout Euclid’s geometry texts.

While working on this method, the thought of implementing it in code lingered at the back of my mind, leaving me wishing I had attended more university classes for my algebra course. A common trait among mathematicians and statisticians is their patience—the kind a teacher has while guiding a toddler learning to read. My patience, however, extends only as far as reading a package’s documentation. Grief and frustration have taken its place, and maturity ultimately dictates my response: to give up. I realise the only way forward is to dedicate a full weekend to revisiting my linear algebra fundamentals. But the mere thought of it makes me restless, even though that contradicts everything I love.

Overall, this approach seems quite difficult to apply, especially when handling an LLM’s caches in real time, which would probably need some sort of ranking algorithm like Google's PageRank to rank the caches, not only to dispatch responses faster but also to condition them on my preferences (or Tom’s memory).

Method 2: Optimization and Reward function

Reward Function Design: The reward model should capture nuanced decision-making, including:

• Contextual awareness (e.g., when to joke, question, or respond sarcastically)
• Emotional alignment (predicting the user’s emotional state and responding accordingly)
• Self-regulation (adjusting the model’s own “emotions” dynamically)

With reinforcement learning in mind, balancing exploration and exploitation in response generation can be viewed as the model choosing between the base model's text and that of its duplicate, which has been adapted to the bot’s observations or memories. In previous posts, I mentioned building the latter as my own clone, like a parrot. Progress here stalled after I attempted to fine-tune Llama with LoRA adapters. I believe it deserved to stall, because my doubts were correct: never touch a deep learning network with minimal data.

For the second method, sculpting a reward model, I’d approach it as a recursive regression state model where parameters (including training parameters) readjust at fixed time intervals. From my understanding, reinforcement learning mechanisms should be applied in real time. Yet existing TRL-PPO demos focus on fine-tuning LLMs on small offline datasets, fully trained rather than partially fitted over data batches.

Additionally, deriving a policy function in reinforcement learning is grounded in the Bellman equation, which, like most optimisation equations, extends Newton’s descent method to different kinds of incoming data streams. Beyond weight clipping (which keeps the model close to its pre-trained state), my views don’t quite align with the work behind trl or researchers’ current approach. The reason is that in practical applications, you always end up with at least two models, and the long-term effectiveness or stability of the fine-tuned one is never guaranteed.

Personally, I try to avoid fine-tuning deep learning models in real time for now. Even with a data iterator that can approximate and generate synthetic data to fill in missing datasets, real-time fine-tuning can only ever be a temporary measure. My tinkering suggests that to retain user-specific experiences, you ultimately end up in a data analyst’s favourite playground: SQL.

Method 3: Mapping Decoding Sample Combinations to Emotional intensity

Dataset with decoding parameters. The prompt used here: "Hey how are you today! 😃"

Ironically, this method was my first instinct for implementation, particularly for a time-constrained project.

The setup for my experiment involved a missing-data iterator that returns a synthetic dataset approximating the previous text embeddings, conditioned on the mapped emotional intensity. Recall that the common decoding techniques are greedy search, beam search and so on; for the sake of simplicity, this experiment disregards variants such as group beam search and token-penalising methods. Let the decoding methods be x_1, x_2, …, x_n, where n is the number of decoding methods, the parameters of each method be α_1, α_2, …, and the emotional expressiveness or intensity be q ∈ [0, 1]. The prior state model for a decoding strategy, conditioned on the speaker’s prompt, returns Tom’s selected emotional intensity. For beam search, for example, the parameters are temperature, top-k and beam width. Finding the optimal combination for some emotional intensity q > ε then becomes finding the unique solution vector of coefficients w in w_1 * α_temp + w_2 * α_k + w_3 * α_beam_width.

Key highlights:

• To set up Tom's prior states, or initial beliefs, for his incoming observation windows, I tried to reduce the compute cost of rerunning GPT-2 by approximating the distribution of text sequences for a given parameter combination. I'm still deciding whether a similar method should be used in real time to assist incremental learners.
• Across all decoding combinations, I kept some parameters fixed for every experiment, e.g. maximum generation length and sequence normalisation.

Currently, I am still trying different sampling techniques to set up a prior state for inferring Tom's emotional intensity.

Epilogue

The main challenge likely stemmed from my own resilience when using the first method. It holds immense potential, but time was too limited. Still, at least I can offer my younger self one last smile, knowing I truly gave it my best at the time. As for whether a machine can have emotions: from my child-self’s perspective, only if the first method succeeds. From my current viewpoint, yes, it absolutely can.

After careful consideration, I’ve decided to move forward with Method 3. Given the simplicity of the final build, it is only natural for people to question whether the emotions are truly authentic or just the product of time-adapting algorithms and statistics. Yet, before anyone doubts a machine’s emotions, I hope they are also completely certain that they themselves are truly alive and not just merely passengers of time.