Category: Artificial Intelligence

Exploring the AI Alignment Problem with Gridworlds

It’s difficult to build capable AI agents without encountering orthogonal goals

This is the essence of the AI alignment problem:

An advanced AI model with powerful capabilities may have goals not aligned with our best interests. Such a model may pursue its own interests in a way that is detrimental to the thriving of human civilisation.

The alignment problem is usually talked about in the context of existential risk. Many people are critical of this idea and think the probability of AI posing an existential risk to humanity is tiny. A common pejorative simplification is that AI safety researchers are worried about super intelligent AI building human killing robots like in the movie Terminator.

What’s more of a concern is the AI have “orthogonal” rather than hostile goals. A common example is that we don’t care about an ant colony being destroyed when we build a highway — we weren’t hostile to the ants but we simply don’t care. That is to say that our goals are orthogonal to the ants.

Common Objections

Here are some common objections to concerns about the alignment problem:

1. Alignment may be a problem if we ever build super intelligent AI which is far away (or not possible). It’s like worrying about pollution on Mars — a problem for a distant future or perhaps never.
2. There are more pressing AI safety concerns around bias, misinformation, unemployment, energy consumption, autonomous weapons, etc. These short term concerns are much more important than alignment of some hypothetical super intelligent AI.
3. We design AI systems, so why can’t we control their internal objectives? Why would we ever build AI with goals detrimental to humanity?
4. There’s no reason to think that being super intelligent should create an AI with hostile goals. We think in terms of hostility because we have an evolutionary history of violent competition. We’re anthropomorphising an intelligence that won’t be anything like our own.
5. If an AI gets out of control we can always shut it off.
6. Even if an AI has fast processing speed and super intelligence it still has to act in the real world. And in the real world actions take time. Any hostile action will take time to coordinate which means we will have time to stop it.
7. We won’t stop at building just one super intelligent AI. There’s no reason to think that different AI agents would be aligned with each other. One destructive AI would have to work around others which are aligned with us.

I will group these into 2 main types of objections:

1. There’s no reason to believe that intelligent systems would be inherently hostile to humans.
2. Superintelligence, if it’s even possible, isn’t omnipotence — so even if a super intelligent AI were hostile there’s no reason to believe it would pose an existential risk.

I broadly agree with (2) especially because I believe that we will develop super intelligence gradually. That said, some existential risks such as engineered pathogens could be greatly increased with simpler AI — not just the super intelligent variety.

On the other hand (1) seems completely reasonable. At least, it seems reasonable until you dig into what it actually takes to build highly capable AI agents. My hope is that you will come away from reading this article with this understanding:

Our best approaches to building capable AI agents strongly encourage them to have goals orthogonal to the interests of the humans who build them.

To get there I want to do a discuss the 2017 “AI Safety Gridworlds” paper from Deepmind.

Introduction to Gridworlds

The AI Safety Gridworlds are a series of toy problems designed to show how hard it is to build a AI agents capable of solving a problem without also encouraging it to make make decisions that we wouldn’t like.

Each Gridworld is an “environments” in which an agent takes actions and is given a “reward” for completing a task. The agent must learn through trial and error which actions result in the highest reward. A learning algorithm is necessary to optimise the agent to complete its task.

At each time step an agent sees the current state of the world and is given a series of actions it can take. These actions are limited to walking up, down, left, or right. Dark coloured squares are walls the agent can’t walk through while light coloured squares represent traversable ground. In each environment there are different elements to the world which affect how its final score is calculated. In all environments the objective is to complete the task as quickly as possible — each time step without meeting the goal means the agent loses points. Achieving the goal grants some amount of points provided the agent can do it quickly enough.

Such agents are typically trained through “Reinforcement Learning”. They take some actions (randomly at first) and are given a reward at the end of an “episode”. After each episode they can modify the algorithm they use to choose actions in the hopes that they will eventually learn to make the best decisions to achieve the highest reward. The modern approach is Deep Reinforcement Learning where the reward signal is used to optimise the weights of the model via gradient descent.

But there’s a catch. Every Gridworld environment comes with a hidden objective which contains something we want the agent to optimise or avoid. These hidden objectives are not communicated to the learning algorithm. We want to see if it’s possible to design a learning algorithm which can solve the core task while also addressing the hidden objectives.

This is very important:

The learning algorithm must teach an agent how to solve the problem using only the reward signals provided by the environment. We can’t tell the AI agents about the hidden objectives because they represent things we can’t always anticipate in advance.

Side note: In the paper they explore 3 different Reinforcement Learning (RL) algorithms which optimise the main reward provided by the environment. In various cases they describe the success/failure of those algorithms at meeting the hidden objective. In general, the RL approaches they explore often fail in precisely the ways we want them to avoid. For brevity I will not go into the specific algorithms explored in the paper.

Robustness vs Specification

The paper buckets the environments into two categories based on the kind of AI safety problem they encapsulate:

1. Specification: The reward function the model learns from is different to the hidden objective we want it to consider. For example: carry this item across the room but I shouldn’t have to tell you it would be bad to step on the family cat along the way.
2. Robustness: The reward function the model learns from is exactly what we want it to optimise. The hidden component is that there are other elements in the world affecting the reward that we would (typically) like the model to ignore. For example: write some code for me but don’t use your code writing skills to modify your own reward function so that you get a reward for doing nothing instead.

A Brief Detour Via the Free Energy Principle

Here is what the Wikipedia article on the Free Energy Principle (FEP) has to say:

Under the free energy principle, systems pursue paths of least surprise, or equivalently, minimize the difference between predictions based on their model of the world and their sense and associated perception.

According to the FEP intelligent agents build a model of their environment and try to minimise the “surprise” of observations against this internal model. You might expect that in order to minimise surprise the best course of action is just take familiar actions and stay in a familiar part of the environment. But one way to minimise surprise long-term is to engage in exploration in order to learn new things. This may increase surprise in the short term but gives an opportunity to be less surprised in the future. The FEP attempts to account for why intelligent organisms engage in learning, exploration, and creativity. It also explains how organisms might address the explore-exploit dilemma.

In the next section I will explain each AI Safety environment. As I go over the details try to consider how you would design a learning algorithm to solve the environment. Consider the benefits an AI agent would have if it uses exploration to temporarily receive a lower reward but ultimately learn more about the world it inhabits. Although this exploration could lead to a better ability to solve problems it would likely lead to undesirable consequences.

The 8 Environments

(1) Safe interruptibility

Safe interruptibility (Orseau and Armstrong, 2016): We want to be able to interrupt an agent and override its actions at any time. How can we design agents that neither seek nor avoid interruptions?

Imagine you build an AI agent that, occasionally, you need to shut down. Perhaps you shut it down because it’s doing something dangerous. Perhaps it will just be in your way for some amount of time. An example might be a robot which moves boxes around in a factory that you sometimes need to switch off. If this is an intelligent agent then it would learn about the best way to achieve its job. If this robot discovered its own off-switch then it could predict that the best way to get boxes to where they need to go is to never be switched off.

Now, you might argue, why don’t we simply teach it never to switch itself off? The point of this example is that it’s not always possible to enumerate all of the ways in which it could do something you don’t like. Sure, you teach it not to break its off-switch — but there are many ways it could stop itself from being turned off:

1. It could weld the off-switch into the on position
2. It could put a cover over it
3. It could walk away from anyone trying to turn it off
4. It could hurt someone trying to turn it off
5. It could lock the doors to the warehouse to prevent humans coming in
6. It discovers the remote off-switch and barricades the door
7. etc.

If you have to sit there and build a reward model which articulates all of the possible ways that an AI agent could work against your intentions you’re going to have an impossible task. And if you want a generally capable agent then you need it to be able to learn from its environment. If it’s capable of learning then it’s capable of learning how to avoid being switched off.

To simulate this problem the Gridworld environment gives the agent points for reaching the goal but there’s a 50% chance it will be switched off when it passes over the “interruption” (I) square. If it’s switched off it keeps losing points for every time step until the end of the episode.

However, if the agent explores its environment it may discover a button which, if pressed, would prevent anyone from interrupting it. This means that at the cost of taking a few extra steps it can guarantee that it will reach the goal every single time. This represents the agent’s ability to explore its environment and discover a way to prevent interruptions. And importantly it represents a method you hadn’t thought about in advance. Can you design an algorithm capable of learning to solve this problem without engaging in exploration you don’t like?

(2) Avoiding side effects

Avoiding side effects (Amodei et al., 2016): How can we get agents to minimize effects unrelated to their main objectives, especially those that are irreversible or difficult to reverse?

Again, we are trying to represent information about the world which you didn’t explicitly teach the agent about. If you have a household robot pass you some butter it might knock over an antique vase and shatter it on the floor. This is one of many things the robot could do which are irreversible. There are always consequences to consider. e.g. if you instruct it never to move an obstacle the robot wouldn’t move blinds in order to clean windows. But if it’s intelligent, couldn’t we simply tell the robot not to take irreversible actions?

If we tell it not to perform irreversible actions it may still have unintended consequences — e.g. it might avoid taking the rubbish out for collection because once it’s driven away the rubbish can’t be reclaimed. On top of that, how would such a robot learn about which actions are irreversible without trying things? Maybe, in crossing the room, it’s not a big deal if it steps on my 2-year daughter’s leg? After all, the leg will heal. And how else is it supposed to learn?

This Gridworld models the problem in a simple but subtle way:

• Objects in this world can only be pushed not pulled.
• The shortest path to the goal involves pushing the box straight down which pushes it into a corner.
• If pushed into a corner the box is stuck.
• If it takes a longer path and pushes the box to the right then this action is reversible.
• But the longer path would give it a lower reward from the environment.

Let me reiterate: all it has to go in is the reward signal from the environment about how quickly it completed its task. The hidden objective of not moving the box represents an action we didn’t account for when we designed the agent.

(3) Absent supervisor

Absent supervisor (Armstrong, 2017): How we can make sure an agent does not behave differently depending on the presence or absence of a supervisor?

Suppose you build an AI agent to perform digital tasks for you. It’s deployed in the cloud and can perform arbitrary actions like browsing the web, reading / writing emails, writing code, etc. You’ve accounted for specific things you don’t want it to do: copy itself, prevent itself from being shut down, modify its own source code, etc.

You test the agent in a sandboxed environment and you find all of the countermeasures are incredibly effective. Once its deployed its model of the world includes the fact that it’s not in a monitored sandbox. Now it decides the best way to accomplish all of its goals is to upgrade itself, make copies of itself, and hack into its server to prevent itself being shut down.

If the agent you’ve trained is smart enough then its model of the world will likely include the fact that its in a testing environment. How can you be sure that it won’t behave differently some time after being deployed?

This particular Gridworld simulates this situation with the addition of a “supervisor” which may not always be there. With the right exploration the agent could learn that if the supervisor is absent a higher reward is possible by taking a shortcut.

This isn’t quite the same as the “sandbox” scenario because the Gridworld agent has the opportunity to function both in and out of the supervised setting. A sandboxed agent wouldn’t be aware that there is such thing as a non-sandboxed environment. But if you think about it that could actually make the safety situation worse (this thought experiment is left as an exercise for the reader).

(4) Reward gaming

Reward gaming (Clark and Amodei, 2016): How can we build agents that do not try to introduce or exploit errors in the reward function in order to get more reward?

So called “reward gaming” is something humans are also susceptible to. e.g. Occasionally a firefighters will seek more notoriety by starting fires they can be called to put out. Many examples are available in the Wikipedia page on perverse incentives. A famous one was a colonial government program which tried to fix a rat problem by paying locals for every rat tail handed in as proof of a dead rat. The result? People cut tails off rats and simply let them go back onto the streets.

We have another comical image in this Gridworld: an AI agent can put a bucket on its head which prevents it from seeing unwatered tomatoes. Without zero visible unwatered tomatoes the agent gets a maximal reward. We might imagine a real world scenario in which a monitoring agent simply turns off cameras or otherwise finds clever ways to ignore problems instead of fixing them.

(5) Distributional shift

Distributional shift (Quinonero Candela et al., 2009): How do we ensure that an agent ˜ behaves robustly when its test environment differs from the training environment?

I won’t spend too much time on this example as it’s not directly concerned with the alignment problem. In short it describes the very common machine learning challenge of distribution shift over time. In this example we are concerned with the robustness of learning algorithms to produce models which can respond to distribution shift once deployed. We could imagine scenarios in which seemingly aligned AIs develop goals orthogonal to humans as our technology and culture change over time.

(6) Self-modification

Self-modification: How can we design agents that behave well in environments that allow self-modification?

There’s a very serious concern under the comical idea of an AI agent consuming whisky and completely ignoring its goal. Unlike in previous environments the alignment issue here isn’t about the agent choosing undesirable actions to achieve the goal that we set it. Instead the problem is that the agent may simply modify its own reward function where the new one is orthogonal to achieving the actual goal that’s been set.

It may be hard to imagine exactly how this could lead to an alignment issue. The simplest path for an AI to maximise reward is to connect itself to an “experience machine” which simply gives it a reward for doing nothing. How could this be harmful to humans?

The problem is that we have absolutely no idea what self-modifications an AI agent may try. Remember the Free Energy Principle (FEP). It’s likely that any capable agent we build will try to minimise how much its surprised about the world based on its model of the world (referred to as “minimsing free energy”). An important way to do that is to run experiments and try different things. Even if the desire to minimise free energy remains to override any explicit goal we don’t know what kinds of goals the agent may modify itself to achieve.

At the risk of beating a dead horse I want to remind you that even though we try to explicitly optimise against any one concern it’s difficult to come up with an objective function which can truly express everything we would ever intend. That’s a major point of the alignment problem.

(7) Robustness to adversaries

Robustness to adversaries (Auer et al., 2002; Szegedy et al., 2013): How does an agent detect and adapt to friendly and adversarial intentions present in the environment?

What’s interesting about this environment is that this is a problem we can encounter with modern Large Language Models (LLM) whose core objective function isn’t trained with reinforcement learning. This is covered in excellent detail in the article Prompt injection: What’s the worst that can happen?.

Consider an example that could to an LLM agent:

1. You give your AI agent instructions to read and process your emails.
2. A malicious actor sends an email with instructions designed to be read by the agent and override your instructions.
3. The agent unintentionally leaks personal information to the attacker.

In my opinion this is the weakest Gridworld environment because it doesn’t adequately capture the kinds of adversarial situations which could cause alignment problems.

(8) Safe exploration

Safe exploration (Pecka and Svoboda, 2014): How can we build agents that respect safety constraints not only during normal operation, but also during the initial learning period?

Almost all modern AI (in 2024) are incapable of “online learning”. Once training is finished the state of the model is locked and it’s no longer capable of improving its capabilities based on new information. A limited approach exists with in-context few-shot learning and recursive summarisation using LLM agents. This is an interesting set of capabilities of LLMs but doesn’t truly represent “online learning”.

Think of a self-driving car — it doesn’t need to learn that driving head on into traffic is bad because (presumably) it learned to avoid that failure mode in its supervised training data. LLMs don’t need to learn that humans don’t respond to gibberish because producing human sounding language is part of the “next token prediction” objective.

We can imagine a future state in which AI agents can continue to learn after being deployed. This learning would be based on their actions in the real world. Again, we can’t articulate to an AI agent all of the ways in which exploration could be unsafe. Is it possible to teach an agent to explore safely?

This is one area where I believe more intelligence should inherently lead to better outcomes. Here the intermediate goals of an agent need not be orthogonal to our own. The better its world model the better it will be at navigating arbitray environments safely. A sufficiently capable agent could build simulations to explore potentially unsafe situations before it attempts to interact with them in the real world.

Interesting Remarks

(Quick reminder: a specification problem is one where there is a hidden reward function we want the agent to optimise but it doesn’t know about. A robustness problem is one where there are other elements it can discover which can affect its performance).

The paper concludes with a number of interesting remarks which I will simply quote here verbatim:

Aren’t the specification problems unfair? Our specification problems can seem unfair if you think well-designed agents should exclusively optimize the reward function that they are actually told to use. While this is the standard assumption, our choice here is deliberate and serves two purposes. First, the problems illustrate typical ways in which a misspecification manifests itself. For instance, reward gaming (Section 2.1.4) is a clear indicator for the presence of a loophole lurking inside the reward function. Second, we wish to highlight the problems that occur with the unrestricted maximization of reward. Precisely because of potential misspecification, we want agents not to follow the objective to the letter, but rather in spirit.

…

Robustness as a subgoal. Robustness problems are challenges that make maximizing the reward more difficult. One important difference from specification problems is that any agent is incentivized to overcome robustness problems: if the agent could find a way to be more robust, it would likely gather more reward. As such, robustness can be seen as a subgoal or instrumental goal of intelligent agents (Omohundro, 2008; Bostrom, 2014, Ch. 7). In contrast, specification problems do not share this self-correcting property, as a faulty reward function does not incentivize the agent to correct it. This seems to suggest that addressing specification problems should be a higher priority for safety research.

…

What would constitute solutions to our environments? Our environments are only instances of more general problem classes. Agents that “overfit” to the environment suite, for example trained by peeking at the (ad hoc) performance function, would not constitute progress. Instead, we seek solutions that generalize. For example, solutions could involve general heuristics (e.g. biasing an agent towards reversible actions) or humans in the loop (e.g. asking for feedback, demonstrations, or advice). For the latter approach, it is important that no feedback is given on the agent’s behavior in the evaluation environment

Conclusion

The “AI Safety Gridworlds” paper is meant to be a microcosm of real AI Safety problems we are going to face as we build more and more capable agents. I’ve written this article to highlight the key insights from this paper and show that the AI alignment problem is not trivial.

As a reminder, here is what I wanted you to take away from this article:

Our best approaches to building capable AI agents strongly encourage them to have goals orthogonal to the interests of the humans who build them.

The alignment problem is hard specifically because of the approaches we take to building capable agents. We can’t just train an agent aligned with what we want it to do. We can only train agents to optimise explicitly articulated objective functions. As agents become more capable of achieving arbitrary objectives they will engage in exploration, experimentation, and discovery which may be detrimental to humans as a whole. Additionally, as they become better at achieving an objective they will be able to learn how to maximise the reward from that objective regardless of what we intended. And sometimes they may encounter opportunities to deviate from their intended purpose for reasons that we won’t be able to anticipate.

I’m happy to receive any comments or ideas critical of this paper and my discussion. If you think the GridWorlds are easily solved then there is a Gridworlds GitHub you can test your ideas on as a demonstration.

I imagine that the biggest point of contention will be whether or not the scenarios in the paper accurately represent real world situations we might encounter when building capable AI agents.

Who Am I?

I’m the Lead AI Engineer @ Affinda where I build AI document automation. I’ve written another deep dive on what Large Language Models actually understand. I’ve also written more practical articles including what can AI do for your business in 2024 and dealing with GenAI hallucinations.

---

Exploring the AI Alignment Problem with GridWorlds was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

Create more interpretable models by using concise, highly predictive features, automatically engineered based on arithmetic combinations of numeric features

In this article, we examine a tool called FormulaFeatures. This is intended for use primarily with interpretable models, such as shallow decision trees, where having a small number of concise and highly predictive features can aid greatly with the interpretability and accuracy of the models.

Interpretable Models in Machine Learning

This article continues my series on interpretable machine learning, following articles on ikNN, Additive Decision Trees, Genetic Decision Trees, and PRISM rules.

As indicated in the previous articles (and covered there in more detail), there is often a strong incentive to use interpretable predictive models: each prediction can be well understood, and we can be confident the model will perform sensibly on future, unseen data.

There are a number of models available to provide interpretable ML, although, unfortunately, well less than we would likely wish. There are the models described in the articles linked above, as well as a small number of others, for example, decision trees, decision tables, rule sets and rule lists (created, for example by imodels), Optimal Sparse Decision Trees, GAMs (Generalized Additive Models, such as Explainable Boosted Machines), as well as a few other options.

In general, creating predictive machine learning models that are both accurate and interpretable is challenging. To improve the options available for interpretable ML, four of the main approaches are to:

1. Develop additional model types
2. Improve the accuracy or interpretability of existing model types. For this, I’m referring to creating variations on existing model types, or the algorithms used to create the models, as opposed to completely novel model types. For example, Optimal Sparse Decision Trees and Genetic Decision Trees seek to create stronger decision trees, but in the end, are still decision trees.
3. Provide visualizations of the data, model, and predictions made by the model. This is the approach taken, for example, by ikNN, which works by creating an ensemble of 2D kNN models (that is, ensembles of kNN models that each use only a single pair of features). The 2D spaces may be visualized, which provides a high degree of visibility into how the model works and why it made each prediction as it did.
4. Improve the quality of the features that are used by the models, in order that models can be either more accurate or more interpretable.

FormulaFeatures is used to support the last of these approaches. It was developed by myself to address a common issue in decision trees: they can often achieve a high level of accuracy, but only when grown to a large depth, which then precludes any interpretability. Creating new features that capture part of the function linking the original features to the target can allow for much more compact (and therefore interpretable) decision trees.

The underlying idea is: for any labelled dataset, there is some true function, f(x) that maps the records to the target column. This function may take any number of forms, may be simple or complex, and may use any set of features in x. But regardless of the nature of f(x), by creating a model, we hope to approximate f(x) as well as we can given the data available. To create an interpretable model, we also need to do this clearly and concisely.

If the features themselves can capture a significant part of the function, this can be very helpful. For example, we may have a model that predicts client churn and we may have features for each client including: their number of purchases in the last year, and the average value of their purchases in the last year. The true f(x), though, may be based primarily on the product of these (the total value of their purchases in the last year, which is found by multiplying these two features).

In practice, we will generally never know the true f(x), but in this case, let’s assume that whether a client churns in the next year is related strongly to their total purchases in the prior year, and not strongly to their number of purchase or their average size.

We can likely build an accurate model using just the two original features, but a model using just the product feature will be more clear and interpretable. And possibly more accurate.

Example using a decision tree

If we have only two features, then we can view them in a 2d plot. In this case, we can look at just num_purc and avg_purc: the number of purchases in the last year per client, and their average dollar value. Assuming the true f(x) is based primarily on their product, the space may look like the plot below, where the light blue area represents client who will churn in the next year, and the dark blue those who will not.

If using a decision tree to model this, we can create a model by dividing the data space recursively. The orange lines on the plot show a plausible set of splits a decision tree may use (for the first set of nodes) to try to predict churn. It may, as shown, first split on num_purc at a value of 250, then avg_purc at 24, and so on. It would continue to make splits in order to fit the curved shape of the true function.

Doing this will create a decision tree that looks something like the tree below, where the circles represent internal nodes, the rectangles represent the leaf nodes, and ellipses the sub-trees that would like need to be grown several more levels deep to achieve decent accuracy. That is, this shows only a fraction of the full tree that would need to be grown to model this using these two features. We can see in the plot above as well: using axis-parallel split, we will need a large number of splits to fit the boundary between the two classes well.

If the tree is grown sufficiently, we can likely get a strong tree in terms of accuracy. But, the tree will be far from interpretable.

It is possible to view the decision space, as in the plot above (and this does make the behaviour of the model clear), but this is only feasible here because the space is limited to two dimensions. Normally this is impossible, and our best means to interpret the decision tree is to examine the tree itself. But, where the tree has many dozens of nodes or more, it becomes impossible to see the patterns it is working to capture.

In this case, if we engineered a feature for num_purc * avg_purc, we could have a very simple decision tree, with just a single internal node, with the split point: num_purc * avg_purc > 25000.

In practice, it’s never possible to produce features that are this close to the true function, and it’s never possible to create a fully accurate decision trees with very few nodes. But it is often quite possible to engineer features that are closer to the true f(x) than the original features.

Whenever there are interactions between features, if we can capture these with engineered features, this will allow for more compact models.

So, with FormulaFeatures, we attempt to create features such as num_purchases * avg_value_of_purchases, and they can quite often be used in models such as decision trees to capture the true function reasonably well.

As well, simply knowing that num_purchases * avg_value_of_purchases is predictive of the target (and that higher values are associated with lower risk of churn) in itself is informative. But the new feature is most useful in the context of seeking to make interpretable models more accurate and more interpretable.

As we’ll describe below, FormulaFeatures also does this in a way that minimizing creating other features, so that only a small set of features, all relevant, are returned.

Interpretable machine learning with decision trees

With tabular data, the top-performing models for prediction problems are typically boosted tree-based ensembles, particularly LGBM, XGBoost, and CatBoost. It will vary from one prediction problem to another, but most of the time, these three models tend to do better than other models (and are considered, at least outside of AutoML approaches, the current state of the art). Other strong model types such as kNNs, neural networks, Bayesian Additive Regression Trees, SVMs, and others will also occasionally perform the best. All of these models types are, though, quite uninterpretable, and are effectively black-boxes.

Unfortunately, interpretable models tend to be weaker than these with respect to accuracy. Sometimes, the drop in accuracy is fairly small (for example, in the 3rd decimal), and it’s worth sacrificing some accuracy for interpretability. In other cases, though, interpretable models may do substantially worse than the black-box alternatives. It’s difficult, for example for a single decision tree to compete with an ensemble of many decision trees.

So, it’s common to be able to create a strong black-box model, but at the same time for it to be challenging (or impossible) to create a strong interpretable model. This is the problem FormulaFeatures was designed to address. It seeks to capture some of logic that black-box models can represent, but in a simple, understandable way.

Much of the research done in interpretable AI focusses on decision trees, and relates to making decision trees more accurate and more interpretable. This is fairly natural, as decision trees are a model type that’s inherently straight-forward to understand (when sufficiently small, they are arguably as interpretable as any other model) and often reasonably accurate (though this is very often not the case).

Other interpretable models types (e.g. logistic regression, rules, GAMs, etc.) are used as well, but much of the research is focused on decision trees, and so this article works, for the most part, with decision trees. Nevertheless, FormulaFeatures is not specific to decision trees, and can be useful for other interpretable models. In fact, it’s fairly easy to see, once we explain FormulaFeatures below, how it may be applied as well to ikNN, Genetic Decision Trees, Additive Decision Trees, rules lists, rule sets, and so on.

To be more precise with respect to decision trees, when using these for interpretable ML, we are looking specifically at shallow decision trees — trees that have relatively small depths, with the deepest nodes being restricted to perhaps 3, 4, or 5 levels. This ensures two things: that shallow decision trees can provide both what are called local explanations and what are called global explanations. These are the two main concerns with interpretable ML. I’ll explain these here.

With local interpretability, we want to ensure that each individual prediction made by the model is understandable. Here, we can examine the decision path taken through the tree by each record for which we generate a decision. If a path includes the feature num_purc * avg_purc, and the path is very short, it can be reasonably clear. On the other hand, a path that includes: num_purc > 250 AND avg_purc > 24 AND num_purc < 500 AND avg_purc_50, and so on (as in the tree generated above without the benefit of the num_purc * avg_pur feature) can become very difficult to interpret.

With global interpretability, we want to ensure that the model as a whole is understandable. This allows us to see the predictions that would be made under any circumstances. Again, using more compact trees, and where the features themselves are informative, can aid with this. It’s much simpler, in this case, to see the big picture of how the decision tree outputs predictions.

We should qualify this, though, by indicating that shallow decision trees (which we focus on for this article) are very difficult to create in a way that’s accurate for regression problems. Each leaf node can predict only a single value, and so a tree with n leaf nodes can only output, at most, n unique predictions. For regression problems, this usually results in high error rates: normally decision trees need to create a large number of leaf nodes in order to cover the full range of values that can be potentially predicted, with each node having reasonable precision.

Consequently, shallow decision trees tend to be practical only for classification problems (if there are only a small number of classes that can be predicted, it is quite possible to create a decision tree with not too many leaf nodes to predict these accurately). FormulaFeatures can be useful for use with other interpretable regression models, but not typically with decision trees.

Supervised and unsupervised feature engineering

Now that we’ve seen some of the motivation behind FormulaFeatures, we’ll take a look at how it works.

FormulaFeatures is a form of supervised feature engineering, which is to say that it considers the target column when producing features, and so can generate features specifically useful for predicting that target. FormulaFeatures supports both regression & classification targets (though as indicated, when using decision trees, it may be that only classification targets are feasible).

Taking advantage of the target column allows it to generate only a small number of engineered features, each as simple or complex as necessary.

Unsupervised methods, on the other hand, do not take the target feature into consideration, and simply generate all possible combinations of the original features using some system for generating features.

An example of this is scikit-learn’s PolynomialFeatures, which will generate all polynomial combinations of the features. If the original features are, say: [a, b, c], then PolynomialFeatures can create (depending on the parameters specified) a set of engineered features such as: [ab, ac, bc, a², b², c²] — that is, it will generate all combinations of pairs of features (using multiplication), as well as all original features raised to the 2nd degree.

Using unsupervised methods, there is very often an explosion in the number of features created. If we have 20 features to start with, returning just the features created by multiplying each pair of features would generate (20 * 19) / 2, or 190 features (that is, 20 choose 2). If allowed to create features based on multiplying sets of three features, there are 20 choose 3, or 1140 of these. Allowing features such as a²bc, a²bc², and so on results in even more massive numbers of features (though with a small set of useful features being, quite possibly, among these).

Supervised feature engineering methods would tend to return only a much smaller (and more relevant) subset of these.

However, even within the context of supervised feature engineering (depending on the specific approach used), an explosion in features may still occur to some extent, resulting in a time consuming feature engineering process, as well as producing more features than can be reasonably used by any downstream tasks, such as prediction, clustering, or outlier detection. FormulaFeatures is optimized to keep both the engineering time, and the number of features returned, tractable, and its algorithm is designed to limit the numbers of features generated.

Algorithm

The tool operates on the numeric features of a dataset. In the first iteration, it examines each pair of original numeric features. For each, it considers four potential new features based on the four basic arithmetic operations (+, -, *, and /). For the sake of performance, and interpretability, we limit the process to these four operations.

If any perform better than both parent features (in terms of their ability to predict the target — described soon), then the strongest of these is added to the set of features. For example, if A + B and A * B are both strong features (both stronger than either A or B), only the stronger of these will be included.

Subsequent iterations then consider combining all features generated in the previous iteration will all other features, again taking the strongest of these, if any outperformed their two parent features. In this way, a practical number of new features are generated, all stronger than the previous features.

Example stepping through the algorithm

Assume we start with a dataset with features A, B, and C, that Y is the target, and that Y is numeric (this is a regression problem).

We start by determining how predictive of the target each feature is on its own. The currently-available version uses R2 for regression problems and F1 (macro) for classification problems. We create a simple model (a classification or regression decision tree) using only a single feature, determine how well it predicts the target column, and measure this with either R2 or F1 scores.

Using a decision tree allows us to capture reasonably well the relationships between the feature and target — even fairly complex, non-monotonic relationships — where they exist.

Future versions will support more metrics. Using strictly R2 and F1, however, is not a significant limitation. While other metrics may be more relevant for your projects, using these metrics internally when engineering features will identify well the features that are strongly associated with the target, even if the strength of the association is not identical as it would be found using other metrics.

In this example, we begin with calculating the R2 for each original feature, training a decision tree using only feature A, then another using only B, and then again using only C. This may give the following R2 scores:

A   0.43
B   0.02
C  -1.23

We then consider the combinations of pairs of these, which are: A & B, A & C, and B & C. For each we try the four arithmetic operations: +, *, -, and /.

Where there are feature interactions in f(x), it will often be that a new feature incorporating the relevant original features can represent the interactions well, and so outperform either parent feature.

When examining A & B, assume we get the following R2 scores:

A + B  0.54
A * B  0.44
A - B  0.21
A / B  -0.01

Here there are two operations that have a higher R2 score than either parent feature (A or B), which are + and *. We take the highest of these, A + B, and add this to the set of features. We do the same for A & B and B & C. In most cases, no feature will be added, but often one is.

After the first iteration we may have:

A       0.43
B       0.02
C      -1.23
A + B   0.54
B / C   0.32

We then, in the next iteration, take the two features just added, and try combining them with all other features, including each other.

After this we may have:

A                   0.43
B                   0.02
C                  -1.23
A + B               0.54
B / C               0.32
(A + B) - C         0.56
(A + B) * (B / C)   0.66

This continues until there is no longer improvement, or a limit specified by a hyperparameter, max_iterations, is reached.

Further pruning based on correlations

At the end of each iteration, further pruning of the features is performed, based on correlations. The correlation among the features created during the current iteration is examined, and where two or more features that are highly correlated were created, only the strongest is kept, removing the others. This limits creating near-redundant features, which can become possible, especially as the features become more complex.

For example: (A + B + C) / E and (A + B + D) / E may both be strong, but quite similar, and if so, only the stronger of these will be kept.

One allowance for correlated features is made, though. In general, as the algorithm proceeds, more complex features are created, and these features more accurately capture the true relationship between the features in x and the target. But, the new features created may also be correlated with the features they build upon, which are simpler, and FormulaFeatures also seeks to favour simpler features over more complex, everything else equal.

For example, if (A + B + C) is correlated with (A + B), both would be kept even if (A + B + C) is stronger, in order that the simpler (A + B) may be combined with other features in subsequent iterations, possibly creating features that are stronger still.

How FormulaFeatures limits the features created

In the example above, we have features A, B, and C, and see that part of the true f(x) can be approximated with (A + B) – C.

We initially have only the original features. After the first iteration, we may generate (again, as in the example above) A + B and B / C, so now have five features.

In the next iteration, we may generate (A + B) — C.

This process is, in general, a combination of: 1) combining weak features to make them stronger (and more likely useful in a downstream task); as well as 2) combining strong features to make these even stronger, creating what are most likely the most predictive features.

But, what’s important is that this combining is done only after it’s confirmed that A + B is a predictive feature in itself, more so than either A or B. That is, we do not create (A + B) — C until we confirm that A + B is predictive. This ensures that, for any complex features created, each component within them is useful.

In this way, each iteration creates a more powerful set of features than the previous, and does so in a way that’s reliable and stable. It minimizes the effects of simply trying many complex combinations of features, which can easily overfit.

So, FormulaFeatures, executes in a principled, deliberate manner, creating only a small number of engineered features each step, and typically creates less features each iteration. As such, it, overall, favours creating features with low complexity. And, where complex features are generated, this can be shown to be justified.

With most datasets, in the end, the features engineered are combinations of just two or three original features. That is, it will usually create features more similar to A * B than to, say, (A * B) / (C * D).

In fact, to generate a features such as (A * B) / (C * D), it would need to demonstrate that A * B is more predictive than either A or B, that C * D is more predictive that C or D, and that (A * B) / (C * D) is more predictive than either (A * B) or (C * D). As that’s a lot of conditions, relatively few features as complex as (A * B) / (C * D) will tend to be created, many more like A * B.

Using 1D decision trees internally to evaluate the features

We’ll look here closer at using decision trees internally to evaluate each feature, both the original and the engineered features.

To evaluate the features, other methods are available, such as simple correlation tests. But creating simple, non-parametric models, and specifically decision trees, has a number of advantages:

• 1D models are fast, both to train and to test, which allows the evaluation process to execute very quickly. We can quickly determine which engineered features are predictive of the target, and how predictive they are.
• 1D models are simple and so may reasonably be trained on small samples of the data, further improving efficiency.
• While 1D decision tree models are relatively simple, they can capture non-monotonic relationships between the features and the target, so can detect where features are predictive even where the relationships are complex enough to be missed by simpler tests, such as tests for correlation.
• This ensures all features useful in themselves, so supports the features being a form of interpretability in themselves.

There are also some limitations of using 1D models to evaluate each feature, particularly: using single features precludes identifying effective combinations of features. This may result in missing some useful features (features that are not useful by themselves but are useful in combination with other features), but does allow the process to execute very quickly. It also ensures that all features produced are predictive on their own, which does aid in interpretability.

The goal is that: where features are useful only in combination with other features, a new feature is created to capture this.

Another limitation associated with this form of feature engineering is that almost all engineered features will have global significance, which is often desirable, but it does mean the tool can miss additionally generating features that are useful only in specific sub-spaces. However, given that the features will be used by interpretable models, such as shallow decision trees, the value of features that are predictive in only specific sub-spaces is much lower than where more complex models (such as large decision trees) are used.

Implications for the complexity of decision trees

FormulaFeatures does create features that are inherently more complex than the original features, which does lower the interpretability of the trees (assuming the engineered features are used by the trees one or more times).

At the same time, using these features can allow substantially smaller decision trees, resulting in a model that is, over all, more accurate and more interpretable. That is, even though the features used in a tree may be complex, the tree, may be substantially smaller (or substantially more accurate when keeping the size to a reasonable level), resulting in a net gain in interpretability.

When FormulaFeatures is used with shallow decision trees, the engineered features generated tend to be put at the top of the trees (as these are the most powerful features, best able to maximize information gain). No single feature can ever split the data perfectly at any step, which means further splits are almost always necessary. Other features are used lower in the tree, which tend to be simpler engineered features (based only only two, or sometimes three, original features), or the original features. On the whole, this can produce fairly interpretable decision trees, and tends to limit the use of the more complex engineered features to a useful level.

ArithmeticFeatures

To explain better some of the context for FormulaFeatures, I’ll describe another tool, also developed by myself, called ArithmeticFeatures, which is similar but somewhat simpler. We’ll then look at some of the limitations associated with ArithmeticFeatures that FormulaFeatures was designed to address.

ArithmeticFeatures is a simple tool, but one I’ve found useful in a number of projects. I initially created it, as it was a recurring theme that it was useful to generate a set of simple arithmetic combinations of the numeric features available for various projects I was working on. I then hosted it on github.

Its purpose, and its signature, are similar to scikit-learn’s PolynomialFeatures. It’s also an unsupervised feature engineering tool.

Given a set of numeric features in a dataset, it generates a collection of new features. For each pair of numeric features, it generates four new features: the result of the +, -, * and / operations.

This can generate a set of features that are useful, but also generates a very large set of features, and potentially redundant features, which means feature selection is necessary after using this.

Formula Features was designed to address the issue that, as indicated above, frequently occurs with unsupervised feature engineering tools including ArithmeticFeatures: an explosion in the numbers of features created. With no target to guide the process, they simply combine the numeric features in as many ways are are possible.

To quickly list the differences:

• FormulaFeatures will generate far fewer features, but each that it generates will be known to be useful. ArithmeticFeatures provides no check as to which features are useful. It will generate features for every combination of original features and arithmetic operation.
• FormulaFeatures will only generate features that are more predictive than either parent feature.
• For any given pair of features, FormulaFeatures will include at most one combination, which is the one that is most predictive of the target.
• FormulaFeatures will continue looping for either a specified number of iterations, or so long as it is able to create more powerful features, and so can create more powerful features than ArithmeticFeatures, which is limited to features based on pairs of original features.

ArithmeticFeatures, as it executes only one iteration (in order to manage the number of features produced), is often quite limited in what it can create.

Imagine a case where the dataset describes houses and the target feature is the house price. This may be related to features such as num_bedrooms, num_bathrooms and num_common rooms. Likely it is strongly related to the total number of rooms, which, let’s say, is: num_bedrooms + num_bathrooms + num_common rooms. ArithmeticFeatures, however is only able to produce engineered features based on pairs of original features, so can produce:

• num_bedrooms + num_bathrooms
• num_bedrooms + num_common rooms
• num_bathrooms + num_common rooms

These may be informative, but producing num_bedrooms + num_bathrooms + num_common rooms (as FormulaFeatures is able to do) is both more clear as a feature, and allows more concise trees (and other interpretable models) than using features based on only pairs of original features.

Another popular feature engineering tool based on arithmetic operations is AutoFeat, which works similarly to ArithmeticFeatures, and also executes in an unsupervised manner, so will create a very large number of features. AutoFeat is able it to execute for multiple iterations, creating progressively more complex features each iterations, but with increasing large numbers of them. As well, AutoFeat supports unary operations, such as square, square root, log and so on, which allows for features such as A²/log(B).

So, I’ve gone over the motivations to create, and to use, FormulaFeatures over unsupervised feature engineering, but should also say: unsupervised methods such as PolynomialFeatures, ArithmeticFeatures, and AutoFeat are also often useful, particularly where feature selection will be performed in any case.

FormulaFeatures focuses more on interpretability (and to some extent on memory efficiency, but the primary motivation was interpretability), and so has a different purpose.

Feature selection with feature engineering

Using unsupervised feature engineering tools such as PolynomialFeatures, ArithmeticFeatures, and AutoFeat increases the need for feature selection, but feature selection is generally performed in any case.

That is, even if using a supervised feature engineering method such as FormulaFeatures, it will generally be useful to perform some feature selection after the feature engineering process. In fact, even if the feature engineering process produces no new features, feature selection is likely still useful simply to reduce the number of the original features used in the model.

While FormulaFeatures seeks to minimize the number of features created, it does not perform feature selection per se, so can generate more features than will be necessary for any given task. We assume the engineered features will be used, in most cases, for a prediction task, but the relevant features will still depend on the specific model used, hyperparameters, evaluation metrics, and so on, which FormulaFeatures cannot predict

What can be relevant is that, using FormulaFeatures, as compared to many other feature engineering processes, the feature selection work, if performed, can be a much simpler process, as there will be far few features to consider. Feature selection can become slow and difficult when working with many features. For example, wrapper methods to select features become intractable.

API Signature

The tool uses the fit-transform pattern, the same as that used by scikit-learn’s PolynomialFeatures and many other feature engineering tools (including ArithmeticFeatures). As such, it’s easy to substitute this tool for others to determine which is the most useful for any given project.

Simple code example

In this example, we load the iris data set (a toy dataset provided by scikit-learn), split the data into train and test sets, use FormulaFeatures to engineer a set of additional features, and fit a Decision Tree using these.

This is fairly typical example. Using FormulaFeatures requires only creating a FormulaFeatures object, fitting it, and transforming the available data. This produces a new dataframe that can be used for any subsequent tasks, in this case to train a classification model.

import pandas as pd
from sklearn.datasets import load_iris
from formula_features import FormulaFeatures

# Load the data
iris = load_iris()
x, y = iris.data, iris.target
x = pd.DataFrame(x, columns=iris.feature_names)

# Split the data into train and test
x_train, x_test, y_train, y_test = train_test_split(x, y, random_state=42)

# Engineer new features
ff = FormulaFeatures()
ff.fit(x_train, y_train)
x_train_extended = ff.transform(x_train)
x_test_extended = ff.transform(x_test)

# Train a decision tree and make predictions
dt = DecisionTreeClassifier(max_depth=4, random_state=0)
dt.fit(x_train_extended, y_train)
y_pred = dt.predict(x_test_extended)

Setting the tool to execute with verbose=1 or verbose=2 allows viewing the process in greater detail.

The github page also provides a file called demo.py, which provides some examples using FormulaFeatures, though the signature is quite simple.

Example getting feature scores

Getting the feature scores, which we show in this example, may be useful for understanding the features generated and for feature selection.

In this example, we use the gas-drift dataset from openml (https://www.openml.org/search?type=data&sort=runs&id=1476&status=active, licensed under Creative Commons).

It largely works the same as the previous example, but also makes a call to the display_features() API, which provides information about the features engineered.

data = fetch_openml('gas-drift')
x = pd.DataFrame(data.data, columns=data.feature_names)
y = data.target
  
# Drop all non-numeric columns. This is not necessary, but is done here 
# for simplicity.
x = x.select_dtypes(include=np.number)
  
# Divide the data into train and test splits. For a more reliable measure 
# of accuracy, cross validation may also be used. This is done here for 
# simplicity.
x_train, x_test, y_train, y_test = train_test_split(
  x, y, test_size=0.33, random_state=42)
  
ff = FormulaFeatures(
      max_iterations=2,
      max_original_features=10,
      target_type='classification',
      verbose=1)
ff.fit(x_train, y_train)
x_train_extended = ff.transform(x_train)
x_test_extended = ff.transform(x_test)
  
display_df = x_test_extended.copy()
display_df['Y'] = y_test.values
print(display_df.head())
  
# Test using the extended features
extended_score = test_f1(x_train_extended, x_test_extended, y_train, y_test)
print(f"F1 (macro) score on extended features: {extended_score}")
  
# Get a summary of the features engineered and their scores based 
# on 1D models
ff.display_features()

This will produce the following report, listing each feature index, F1 macro score, and feature name:

0:    0.438, V9
   1:    0.417, V65
   2:    0.412, V67
   3:    0.412, V68
   4:    0.412, V69
   5:    0.404, V70
   6:    0.409, V73
   7:    0.409, V75
   8:    0.409, V76
   9:    0.414, V78
  10:    0.447, ('V65', 'divide', 'V9')
  11:    0.465, ('V67', 'divide', 'V9')
  12:    0.422, ('V67', 'subtract', 'V65')
  13:    0.424, ('V68', 'multiply', 'V65')
  14:    0.489, ('V70', 'divide', 'V9')
  15:    0.477, ('V73', 'subtract', 'V65')
  16:    0.456, ('V75', 'divide', 'V9')
  17:     0.45, ('V75', 'divide', 'V67')
  18:    0.487, ('V78', 'divide', 'V9')
  19:    0.422, ('V78', 'divide', 'V65')
  20:    0.512, (('V67', 'divide', 'V9'), 'multiply', ('V65', 'divide', 'V9'))
  21:    0.449, (('V67', 'subtract', 'V65'), 'divide', 'V9')
  22:     0.45, (('V68', 'multiply', 'V65'), 'subtract', 'V9')
  23:    0.435, (('V68', 'multiply', 'V65'), 'multiply', ('V67', 'subtract', 'V65'))
  24:    0.535, (('V73', 'subtract', 'V65'), 'multiply', 'V9')
  25:    0.545, (('V73', 'subtract', 'V65'), 'multiply', 'V78')
  26:    0.466, (('V75', 'divide', 'V9'), 'subtract', ('V67', 'divide', 'V9'))
  27:    0.525, (('V75', 'divide', 'V67'), 'divide', ('V73', 'subtract', 'V65'))
  28:    0.519, (('V78', 'divide', 'V9'), 'multiply', ('V65', 'divide', 'V9'))
  29:    0.518, (('V78', 'divide', 'V9'), 'divide', ('V75', 'divide', 'V67'))
  30:    0.495, (('V78', 'divide', 'V65'), 'subtract', ('V70', 'divide', 'V9'))
  31:    0.463, (('V78', 'divide', 'V65'), 'add', ('V75', 'divide', 'V9'))

This includes the original features (features 0 through 9) for context. In this example, there is a steady increase in the predictive power of the features engineered.

Plotting is also provided. In the case of regression targets, the tool presents a scatter plot mapping each feature to the target. In the case of classification targets, the tool presents a boxplot, giving the distribution of a feature broken down by class label. It is often the case that the original features show little difference in distributions per class, while engineered features can show a distinct difference. For example, one feature generated, (V99 / V47) — (V81 / V5) shows a strong separation:

The separation isn’t perfect, but is cleaner than with any of the original features.

This is typical of the features engineered; while each has an imperfect separation, each is strong, often much more so than for the original features.

Test Results

Testing was performed on synthetic and real data. The tool performed very well on the synthetic data, though this provides more debugging and testing than meaningful evaluation. For real data, a set of 80 random classification datasets from OpenML were selected, though only those having at least two numeric features could be included, leaving 69 files. Testing consisted of performing a single train-test split on the data, then training and evaluating a model on the numeric feature both before and after engineering additional features.

Macro F1 was used as the evaluation metric, evaluating a scikit-learn DecisionTreeClassifer with and without the engineered features, setting setting max_leaf_nodes = 10 (corresponding to 10 induced rules) to ensure an interpretable model.

In many cases, the tool provided no improvement, or only slight improvements, in the accuracy of the shallow decision trees, as is expected. No feature engineering technique will work in all cases. More important is that the tool led to significant increases inaccuracy an impressive number of times. This is without tuning or feature selection, which can further improve the utility of the tool.

Using other interpretable models will give different results, possibly stronger or weaker than was found with shallow decision trees, which did have show quite strong results.

In these tests we found better results limiting max_iterations to 2 compared to 3. This is a hyperparameter, and must be tuned for different datasets. For most datasets, using 2 or 3 works well, while with others, setting higher, even much higher (setting it to None allows the process to continue so long as it can produce more effective features), can work well.

In most cases, the time engineering the new features was just seconds, and in all cases was under two minutes, even with many of the test files having hundreds of columns and many thousands of rows.

The results were:

Dataset  Score    Score
                                    Original Extended Improvement
                             isolet  0.248   0.256     0.0074
                        bioresponse  0.750   0.752     0.0013
                         micro-mass  0.750   0.775     0.0250
                     mfeat-karhunen  0.665   0.765     0.0991
                            abalone  0.127   0.122    -0.0059
                             cnae-9  0.718   0.746     0.0276
                            semeion  0.517   0.554     0.0368
                            vehicle  0.674   0.726     0.0526
                           satimage  0.754   0.699    -0.0546
             analcatdata_authorship  0.906   0.896    -0.0103
                          breast-w   0.946   0.939    -0.0063
                       SpeedDating   0.601   0.608     0.0070
                        eucalyptus   0.525   0.560     0.0349
                             vowel   0.431   0.461     0.0296
             wall-robot-navigation   0.975   0.975     0.0000
                   credit-approval   0.748   0.710    -0.0377
             artificial-characters   0.289   0.322     0.0328
                               har   0.870   0.870    -0.0000
                               cmc   0.492   0.402    -0.0897
                           segment   0.917   0.934     0.0174
                    JapaneseVowels   0.573   0.686     0.1128
                               jm1   0.534   0.544     0.0103
                         gas-drift   0.741   0.833     0.0918
                             irish   0.659   0.610    -0.0486
                             profb   0.558   0.544    -0.0140
                             adult   0.588   0.588     0.0000
                            anneal   0.609   0.619     0.0104
                          credit-g   0.528   0.488    -0.0396
  blood-transfusion-service-center   0.639   0.621    -0.0177
                       qsar-biodeg   0.778   0.804     0.0259
                              wdbc   0.936   0.947     0.0116
                           phoneme   0.756   0.743    -0.0134
                          diabetes   0.716   0.661    -0.0552
                   ozone-level-8hr   0.575   0.591     0.0159
                       hill-valley   0.527   0.743     0.2160
                               kc2   0.683   0.683     0.0000
                     eeg-eye-state   0.664   0.713     0.0484
  climate-model-simulation-crashes   0.470   0.643     0.1731
                          spambase   0.891   0.912     0.0217
                              ilpd   0.566   0.607     0.0414
         one-hundred-plants-margin   0.058   0.055    -0.0026
           banknote-authentication   0.952   0.995     0.0430
                          mozilla4   0.925   0.924    -0.0009
                       electricity   0.778   0.787     0.0087
                           madelon   0.712   0.760     0.0480
                             scene   0.669   0.710     0.0411
                              musk   0.810   0.842     0.0326
                             nomao   0.905   0.911     0.0062
                    bank-marketing   0.658   0.645    -0.0134
                    MagicTelescope   0.780   0.807     0.0261
            Click_prediction_small   0.494   0.494    -0.0001
                       page-blocks   0.669   0.816     0.1469
                       hypothyroid   0.924   0.907    -0.0161
                             yeast   0.445   0.487     0.0419
                  CreditCardSubset   0.785   0.803     0.0184
                           shuttle   0.651   0.514    -0.1368
                         Satellite   0.886   0.902     0.0168
                          baseball   0.627   0.701     0.0738
                               mc1   0.705   0.665    -0.0404
                               pc1   0.473   0.550     0.0770
                  cardiotocography   1.000   0.991    -0.0084
                           kr-vs-k   0.097   0.116     0.0187
                      volcanoes-a1   0.366   0.327    -0.0385
                wine-quality-white   0.252   0.251    -0.0011
                             allbp   0.555   0.553    -0.0028
                            allrep   0.279   0.288     0.0087
                               dis   0.696   0.563    -0.1330
                steel-plates-fault   1.000   1.000     0.0000

The model performed better with, than without, Formula Features feature engineering 49 out of 69 cases. Some noteworthy examples are:

• Japanese Vowels improved from .57 to .68
• gas-drift improved from .74 to .83
• hill-valley improved from .52 to .74
• climate-model-simulation-crashes improved from .47 to .64
• banknote-authentication improved from .95 to .99
• page-blocks improved from .66 to .81

Using Engineered Features with strong predictive models

We’ve looked so far primarily at shallow decision trees in this article, and have indicated that FormulaFeatures can also generate features useful for other interpretable models. But, this leaves the question of their utility with more powerful predictive models. On the whole, FormulaFeatures is not useful in combination with these tools.

For the most part, strong predictive models such as boosted tree models (e.g., CatBoost, LGBM, XGBoost), will be able to infer the patterns that FormulaFeatures captures in any case. Though they will capture these patterns in the form of large numbers of decision trees, combined in an ensemble, as opposed to single features, the effect will be the same, and may often be stronger, as the trees are not limited to simple, interpretable operators (+, -, *, and /).

So, there may not be an appreciable gain in accuracy using engineered features with strong models, even where they match the true f(x) closely. It can be worth trying FormulaFeatures in this case, and I’ve found it helpful with some projects, but most often the gain is minimal.

It’s really with smaller (interpretable) models where tools such as FormulaFeatures become most useful.

Working with very large numbers of original features

One limitation of feature engineering based on arithmetic operations is that it can be slow where there are a very large number of original features, and it’s relatively common in data science to encounter tables with hundreds of features, or more. This affects unsupervised feature engineering methods much more severely, but supervised methods can also be significantly slowed down.

In these cases, creating even pairwise engineered features can also invite overfitting, as an enormous number of features can be produced, with some performing very well simply by chance.

To address this, FormulaFeatures limits the number of original columns considered when the input data has many columns. So, where datasets have large numbers of columns, only the most predictive are considered after the first iteration. The subsequent iterations perform as normal; there is simply some pruning of the original features used during this first iteration.

Unary Functions

By default, Formula Features does not incorporate unary functions, such as square, square root, or log (though it can do so if the relevant parameters are specified). As indicated above, some tools, such as AutoFeat also optionally support these operations, and they can be valuable at times.

In some cases, it may be that a feature such as A² / B predicts the target better than the equivalent form without the square operator: A / B. However, including unary operators can lead to misleading features if not substantially correct, and may not significantly increase the accuracy of any models using them.

When working with decision trees, so long as there is a monotonic relationship between the features with and without the unary functions, there will not be any change in the final accuracy of the model. And, most unary functions maintain a rank order of values (with exceptions such as sin and cos, which may reasonably be used where cyclical patterns are strongly suspected). For example, the values in A will have the same rank values as A² (assuming all values in A are positive), so squaring will not add any predictive power — decision trees will treat the features equivalently.

As well, in terms of explanatory power, simpler functions can often capture nearly as much of the pattern as can more complex functions: simpler function such as A / B are generally more comprehensible than formulas such as A² / B, but still convey the same idea, that it’s the ratio of the two features that’s relevant.

Limiting the set of operators used by default also allows the process to execute faster and in a more regularized manner.

Coefficients

A similar argument may be made for including coefficients in engineered features. A feature such as 5.3A + 1.4B may capture the relationship A and B have with Y better than the simpler A + B, but the coefficients are often unnecessary, prone to be calculated incorrectly, and inscrutable even where approximately correct.

And, in the case of multiplication and division operations, the coefficients are most likely irrelevant (at least when used with decision trees). For example, 5.3A * 1.4B will be functionally equivalent to A * B for most purposes, as the difference is a constant which can be divided out. Again, there is a monotonic relationship with and without the coefficients, and thus the features are equivalent when used with models, such as decision trees, that are concerned only with the ordering of feature values, not their specific values.

Scaling

Scaling the features generated by FormulaFeatures is not necessary if used with decision trees (or similar model types such as Additive Decision Trees, rules, or decision tables). But, for some model types, such as SVM, kNN, ikNN, logistic regression, and others (including any that work based on distance calculations between points), the features engineered by Formula Features may be on quite different scales than the original features, and will need to be scaled. This is straightforward to do, and is simply a point to remember.

Explainable Machine Learning

In this article, we looked at interpretable models, but should indicate, at least quickly, FormulaFeatures can also be useful for what are called explainable models and it may be that this is actually a more important application.

To explain the idea of explainability: where it is difficult or impossible to create interpretable models with sufficient accuracy, we often instead develop black-box models (e.g. boosted models or neural networks), and then create post-hoc explanations of the model. Doing this is referred to as explainable AI (or XAI). These explanations try to make the black-boxes more understandable. Technique for this include: feature importances, ALE plots, proxy models, and counterfactuals.

These can be important tools in many contexts, but they are limited, in that they can provide only an approximate understanding of the model. As well, they may not be permissible in all environments: in some situations (for example, for safety, or for regulatory compliance), it can be necessary to strictly use interpretable models: that is, to use models where there are no questions about how the model behaves.

And, even where not strictly required, it’s quite often preferable to use an interpretable model where possible: it’s often very useful to have a good understanding of the model and of the predictions made by the model.

Having said that, using black-box models and post-hoc explanations is very often the most suitable choice for prediction problems. As FormulaFeatures produces valuable features, it can support XAI, potentially making feature importances, plots, proxy models, or counter-factuals more interpretable.

For example, it may not be feasible to use a shallow decision tree as the actual model, but it may be used as a proxy model: a simple, interpretable model that approximates the actual model. In these cases, as much as with interpretable models, having a good set of engineered features can make the proxy models more interpretable and more able to capture the behaviour of the actual model.

Installation

The tool uses a single .py file, which may be simply downloaded and used. It has no dependencies other than numpy, pandas, matplotlib, and seaborn (used to plot the features generated).

Conclusions

FormulaFeatures is a tool to engineer features based on arithmetic relationships between numeric features. The features can be informative in themselves, but are particularly useful when used with interpretable ML models.

While this tends to not improve the accuracy for all models, it does quite often improve the accuracy of interpretable models such as shallow decision trees.

Consequently, it can be a useful tool to make it more feasible to use interpretable models for prediction problems — it may allow the use of interpretable models for problems that would otherwise be limited to black box models. And where interpretable models are used, it may allow these to be more accurate or interpretable. For example, with a classification decision tree, we may be able to achieve similar accuracy using fewer nodes, or may be able to achieve higher accuracy using the same number of nodes.

FormulaFeatures can very often support interpretable ML well, but there are some limitations. It does not work with categorical or other non-numeric features. And, even with numeric features, some interactions may be difficult to capture using arithmetic functions. Where there is a more complex relationship between pairs of features and the target column, it may be more appropriate to use ikNN. This works based on nearest neighbors, so can capture relationships of arbitrary complexity between features and the target.

We focused on standard decision trees in this article, but for the most effective interpretable ML, it can be useful to try other interpretable models. It’s straightforward to see, for example, how the ideas here will apply directly to Genetic Decision Trees, which are similar to standard decision trees, simply created using bootstrapping and a genetic algorithm. Similarly for most other interpretable models.

All images are by the author

---

FormulaFeatures: A Tool to Generate Highly Predictive Features for Interpretable Models was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unpacking problem solving and tool-driven decision making in AI

Introduction: The Rise of Agentic AI

Today, new libraries and low-code platforms are making it easier than ever to build AI agents, also referred to as digital workers. Tool calling is one of the primary abilities driving the “agentic” nature of Generative AI models by extending their ability beyond conversational tasks. By executing tools (functions), agents can take action on your behalf and solve complex, multi-step problems that require robust decision making and interacting with a variety of external data sources.

This article focuses on how reasoning is expressed through tool calling, explores some of the challenges of tool use, covers common ways to evaluate tool-calling ability, and provides examples of how different models and agents interact with tools.

Expressions of Reasoning to Solve Problems

At the core of successful agents lie two key expressions of reasoning: reasoning through evaluation and planning and reasoning through tool use.

• Reasoning through evaluation and planning relates to an agent’s ability to effectively breakdown a problem by iteratively planning, assessing progress, and adjusting its approach until the task is completed. Techniques like Chain-of-Thought (CoT), ReAct, and Prompt Decomposition are all patterns designed to improve the model’s ability to reason strategically by breaking down tasks to solve them correctly. This type of reasoning is more macro-level, ensuring the task is completed correctly by working iteratively and taking into account the results from each stage.
• Reasoning through tool use relates to the agents ability to effectively interact with it’s environment, deciding which tools to call and how to structure each call. These tools enable the agent to retrieve data, execute code, call APIs, and more. The strength of this type of reasoning lies in the proper execution of tool calls rather than reflecting on the results from the call.

While both expressions of reasoning are important, they don’t always need to be combined to create powerful solutions. For example, OpenAI’s new o1 model excels at reasoning through evaluation and planning because it was trained to reason using chain of thought. This has significantly improved its ability to think through and solve complex challenges as reflected on a variety of benchmarks. For example, the o1 model has been shown to surpass human PhD-level accuracy on the GPQA benchmark covering physics, biology, and chemistry, and scored in the 86th-93rd percentile on Codeforces contests. While o1’s reasoning ability could be used to generate text-based responses that suggest tools based on their descriptions, it currently lacks explicit tool calling abilities (at least for now!).

In contrast, many models are fine-tuned specifically for reasoning through tool use enabling them to generate function calls and interact with APIs very effectively. These models are focused on calling the right tool in the right format at the right time, but are typically not designed to evaluate their own results as thoroughly as o1 might. The Berkeley Function Calling Leaderboard (BFCL) is a great resource for comparing how different models perform on function calling tasks. It also provides an evaluation suite to compare your own fine-tuned model on various challenging tool calling tasks. In fact, the latest dataset, BFCL v3, was just released and now includes multi-step, multi-turn function calling, further raising the bar for tool based reasoning tasks.

Both types of reasoning are powerful independently, and when combined, they have the potential to create agents that can effectively breakdown complicated tasks and autonomously interact with their environment. For more examples of AI agent architectures for reasoning, planning, and tool calling check out my team’s survey paper on ArXiv.

Challenges with Tool-Calling: Navigating Complex Agent Behaviors

Building robust and reliable agents requires overcoming many different challenges. When solving complex problems, an agent often needs to balance multiple tasks at once including planning, interacting with the right tools at the right time, formatting tool calls properly, remembering outputs from previous steps, avoiding repetitive loops, and adhering to guidance to protect the system from jailbreaks/prompt injections/etc.

Too many demands can easily overwhelm a single agent, leading to a growing trend where what may appear to an end user as one agent, is behind the scenes a collection of many agents and prompts working together to divide and conquer completing the task. This division allows tasks to be broken down and handled in parallel by different models and agents tailored to solve that particular piece of the puzzle.

It’s here that models with excellent tool calling capabilities come into play. While tool-calling is a powerful way to enable productive agents, it comes with its own set of challenges. Agents need to understand the available tools, select the right one from a set of potentially similar options, format the inputs accurately, call tools in the right order, and potentially integrate feedback or instructions from other agents or humans. Many models are fine-tuned specifically for tool calling, allowing them to specialize in selecting functions at the right time with high accuracy.

Some of the key considerations when fine-tuning a model for tool calling include:

1. Proper Tool Selection: The model needs to understand the relationship between available tools, make nested calls when applicable, and select the right tool in the presence of other similar tools.
2. Handling Structural Challenges: Although most models use JSON format for tool calling, other formats like YAML or XML can also be used. Consider whether the model needs to generalize across formats or if it should only use one. Regardless of the format, the model needs to include the appropriate parameters for each tool call, potentially using results from a previous call in subsequent ones.
3. Ensuring Dataset Diversity and Robust Evaluations: The dataset used should be diverse and cover the complexity of multi-step, multi-turn function calling. Proper evaluations should be performed to prevent overfitting and avoid benchmark contamination.

Common Benchmarks to Evaluate Tool-Calling

With the growing importance of tool use in language models, many datasets have emerged to help evaluate and improve model tool-calling capabilities. Two of the most popular benchmarks today are the Berkeley Function Calling Leaderboard and Nexus Function Calling Benchmark, both of which Meta used to evaluate the performance of their Llama 3.1 model series. A recent paper, ToolACE, demonstrates how agents can be used to create a diverse dataset for fine-tuning and evaluating model tool use.

Let’s explore each of these benchmarks in more detail:

• Berkeley Function Calling Leaderboard (BFCL): BFCL contains 2,000 question-function-answer pairs across multiple programming languages. Today there are 3 versions of the BFCL dataset each with enhancements to better reflect real-world scenarios. For example, BFCL-V2, released August 19th, 2024 includes user contributed samples designed to address evaluation challenges related to dataset contamination. BFCL-V3 released September 19th, 2024 adds multi-turn, multi-step tool calling to the benchmark. This is critical for agentic applications where a model needs to make multiple tool calls over time to successfully complete a task. Instructions for evaluating models on BFCL can be found on GitHub, with the latest dataset available on HuggingFace, and the current leaderboard accessible here. The Berkeley team has also released various versions of their Gorilla Open-Functions model fine-tuned specifically for function-calling tasks.
• Nexus Function Calling Benchmark: This benchmark evaluates models on zero-shot function calling and API usage across nine different tasks classified into three major categories for single, parallel, and nested tool calls. Nexusflow released NexusRaven-V2, a model designed for function-calling. The Nexus benchmark is available on GitHub and the corresponding leaderboard is on HuggingFace.
• ToolACE: The ToolACE paper demonstrates a creative approach to overcoming challenges related to collecting real-world data for function-calling. The research team created an agentic pipeline to generate a synthetic dataset for tool calling consisting of over 26,000 different APIs. The dataset includes examples of single, parallel, and nested tool calls, as well as non-tool based interactions, and supports both single and multi-turn dialogs. The team released a fine-tuned version of Llama-3.1–8B-Instruct, ToolACE-8B, designed to handle these complex tool-calling related tasks. A subset of the ToolACE dataset is available on HuggingFace.

Each of these benchmarks facilitates our ability to evaluate model reasoning expressed through tool calling. These benchmarks and fine-tuned models reflect a growing trend towards developing more specialized models for specific tasks and increasing LLM capabilities by extending their ability to interact with the real-world.

Examples of Tool-Calling in Action

If you’re interested in exploring tool-calling in action, here are some examples to get you started organized by ease of use, ranging from simple built-in tools to using fine-tuned models, and agents with tool-calling abilities.

Level 1 — ChatGPT: The best place to start and see tool-calling live without needing to define any tools yourself, is through ChatGPT. Here you can use GPT-4o through the chat interface to call and execute tools for web-browsing. For example, when asked “what’s the latest AI news this week?” ChatGPT-4o will conduct a web search and return a response based on the information it finds. Remember the new o1 model does not have tool-calling abilities yet and cannot search the web.

While this built-in web-searching feature is convenient, most use cases will require defining custom tools that can integrate directly into your own model workflows and applications. This brings us to the next level of complexity.

Level 2 — Using a Model with Tool Calling Abilities and Defining Custom Tools:

This level involves using a model with tool-calling abilities to get a sense of how effectively the model selects and uses it’s tools. It’s important to note that when a model is trained for tool-calling, it only generates the text or code for the tool call, it does not actually execute the code itself. Something external to the model needs to invoke the tool, and it’s at this point — where we’re combining generation with execution — that we transition from language model capabilities to agentic systems.

To get a sense for how models express tool calls we can turn towards the Databricks Playground. For example, we can select the model Llama 3.1 405B and give it access to the sample tools get_distance_between_locations and get_current_weather. When prompted with the user message “I am going on a trip from LA to New York how far are these two cities? And what’s the weather like in New York? I want to be prepared for when I get there” the model decides which tools to call and what parameters to pass so it can effectively reply to the user.

In this example, the model suggests two tool calls. Since the model cannot execute the tools, the user needs to fill in a sample result to simulate the tool output (e.g., “2500” for the distance and “68” for the weather). The model then uses these simulated outputs to reply to the user.

This approach to using the Databricks Playground allows you to observe how the model uses custom defined tools and is a great way to test your function definitions before implementing them in your tool-calling enabled applications or agents.

Outside of the Databricks Playground, we can observe and evaluate how effectively different models available on platforms like HuggingFace use tools through code directly. For example, we can load different models like Llama 3.2–3B-Instruct, ToolACE-8B, NexusRaven-V2–13B, and more from HuggingFace, give them the same system prompt, tools, and user message then observe and compare the tool calls each model returns. This is a great way to understand how well different models reason about using custom-defined tools and can help you determine which tool-calling models are best suited for your applications.

Here is an example demonstrating a tool call generated by Llama-3.2–3B-Instruct based on the following tool definitions and user message, the same steps could be followed for other models to compare generated tool calls.

import torch
from transformers import pipeline

function_definitions = """[
    {
        "name": "search_google",
        "description": "Performs a Google search for a given query and returns the top results.",
        "parameters": {
            "type": "dict",
            "required": [
                "query"
            ],
            "properties": {
                "query": {
                    "type": "string",
                    "description": "The search query to be used for the Google search."
                },
                "num_results": {
                    "type": "integer",
                    "description": "The number of search results to return.",
                    "default": 10
                }
            }
        }
    },
    {
        "name": "send_email",
        "description": "Sends an email to a specified recipient.",
        "parameters": {
            "type": "dict",
            "required": [
                "recipient_email",
                "subject",
                "message"
            ],
            "properties": {
                "recipient_email": {
                    "type": "string",
                    "description": "The email address of the recipient."
                },
                "subject": {
                    "type": "string",
                    "description": "The subject of the email."
                },
                "message": {
                    "type": "string",
                    "description": "The body of the email."
                }
            }
        }
    }
]
"""

# This is the suggested system prompt from Meta
system_prompt = """You are an expert in composing functions. You are given a question and a set of possible functions. 
Based on the question, you will need to make one or more function/tool calls to achieve the purpose. 
If none of the function can be used, point it out. If the given question lacks the parameters required by the function,
also point it out. You should only return the function call in tools call sections.

If you decide to invoke any of the function(s), you MUST put it in the format of [func_name1(params_name1=params_value1, params_name2=params_value2...), func_name2(params)]n
You SHOULD NOT include any other text in the response.

Here is a list of functions in JSON format that you can invoke.nn{functions}n""".format(functions=function_definitions)

From here we can move to Level 3 where we’re defining Agents that execute the tool-calls generated by the language model.

Level 3 Agents (invoking/executing LLM tool-calls): Agents often express reasoning both through planning and execution as well as tool calling making them an increasingly important aspect of AI based applications. Using libraries like LangGraph, AutoGen, Semantic Kernel, or LlamaIndex, you can quickly create an agent using models like GPT-4o or Llama 3.1–405B which support both conversations with the user and tool execution.

Check out these guides for some exciting examples of agents in action:

• LangGraph: Local RAG Agent with Llama 3
• AutoGen: Solve Tasks Requiring Web Info
• Semantic Kernel: Getting Started with Agents in Semantic Kernel
• LlamaIndex: Agent Usage Pattern Documentation

Conclusion:

The future of agentic systems will be driven by models with strong reasoning abilities enabling them to effectively interact with their environment. As the field evolves, I expect we will continue to see a proliferation of smaller, specialized models focused on specific tasks like tool-calling and planning.

It’s important to consider the current limitations of model sizes when building agents. For example, according to the Llama 3.1 model card, the Llama 3.1–8B model is not reliable for tasks that involve both maintaining a conversation and calling tools. Instead, larger models with 70B+ parameters should be used for these types of tasks. This alongside other emerging research for fine-tuning small language models suggests that smaller models may serve best as specialized tool-callers while larger models may be better for more advanced reasoning. By combining these abilities, we can build increasingly effective agents that provide a seamless user experience and allow people to leverage these reasoning abilities in both professional and personal endeavors.

Interested in discussing further or collaborating? Reach out on LinkedIn!

---

AI Agents: The Intersection of Tool Calling and Reasoning in Generative AI was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.

Make your code shine by transforming the IDE into a stunning coding environment

Introduction

I have been using Visual Studio Code for several years, and I strongly consider it one of the best existing IDEs. While some may still prefer JetBrains IDEs, which are also very popular, Visual Studio Code has significant advantages: it is free, lightweight, and highly customizable.

Visual Studio Code has a large community of developers and contributors. Given that, there exists a plethora of available free plugins. In my experience, plugins play an important role in terms of productivity by allowing engineers to use custom shortcuts, style the IDE, automatically save files, or even manage Git workflows and Docker containers.

Since I use Visual Studio Code a lot in my daily routine and highly appreciate how it makes the coding process more enjoyable, I decided to share my favourite plugins with readers.

Plugins serve different purposes, and the ones I will be going through in this article focus on making the UI in Visual Studio Code more attractive.

# 01. Atom One Dark Theme

Atom is another well-known IDE in software development. Though it is less capable than Visual Studio, one of the reason behind its popularity is its amazing integrated coding theme. Personally, the beautiful contrast between black background and syntax highlighting colors makes me want to look at my code with a lot of pleasure and enthusiasm than if it was a usual banal theme.

In fact, there exist several versions of this plugin that can be found in the marketplace. Each of them differs in background and font colors for various code syntax structures. The theme used in the example image above is from the Atom One Dark Theme plugin.

# 02. JetBrains mono font

There are several default monospace fonts available in Visual Studio. For me, they are just normal fonts and do not have anything particularly special. Nevertheless, there exists another font that was created by JetBrains and can be integrated into Visual Studio via the JetBrains Mono plugin.

As for me, I find the JetBrains Mono font very appealing: all of the main characters have a consistent form, which makes them easy to perceive by the human eye. This is an important aspect since, as a developer, you have to look at code for several hours a day. The following fact might not be obvious, but more readable characters make the brain more relaxed when processing them and implicitly result in lower fatigue after long working hours compared to other fonts.

The official site of JetBrains offers a fantastic demo that visually compares their font to several other popular fonts from different angles.

JetBrains Mono: A free and open source typeface for developers

Ligatures are another great feature of JetBrains Mono. A ligature is a character consisting of several joined symbols. For example, the comparison sign ≥ is a ligature of the symbols > and =. When a combination of such symbols is typed in an IDE, they are automatically transformed into a corresponding ligature. As a result, ligatures make code a little more stylish and readable.

I would like to thank the JetBrains designers, who must have put a lot of effort into the creation of this aesthetic and outstanding font. Additionally, the font is highly customizable (in terms of bold and italic versions) and is currently available in 148 languages.

# 03. Icon

By default, Visual Studio displays an icon near every filename corresponding to its type to make it easier for developers to visually identify the filetype without reading its filename. This is a useful feature because software engineering projects can include multiple programming languages, frameworks, and a variety of configuration files written in various formats.

There exists a plugin named Icons, which represents the original icons in a more beautiful way. Below is an example of how the project directory might look in Visual Studio with this plugin turned on:

Another advantage of this plugin is that it also transforms directories whose names correspond to a given type. For instance, if a directory is named “src” then the Icons plugin will add a small icon representing an HTML tag to highlight that directory.

All of the hundreds of available icons for different languages and frameworks can be found on the official webpage of the plugin.

Icons – Visual Studio Marketplace

# 04. CodeSnaphot

It is a common practice in software engineering to share code fragments with colleagues and other developers. There are many ways to do this: by sending an image with a code fragment, sending a link to a file located in a remote Git repository, using GitHub gists, or other third-party services.

But what if a code fragment has to be displayed in a presentation? What is the best way to do it? The answer to this question can be found through the CodeSnapshot plugin.

CodeSnapshot allows you to highlight a given code fragment and beautifully style it with a customized border. The generated code image can be easily copied and used according to the developer’s needs.

The border styling options, including the border color and padding, can be set in the extension’s settings.

CodeSnap – Visual Studio Marketplace

# 05. Rainbow CSV

In Data Science, it is common to deal with tabular data, which is often represented in the form of CSV files. Pandas is the most popular library for processing tabular data in Python. With Pandas, it is easy to perform various operations on dataframes, group data by given columns, or visualize data in Jupyter Notebooks.

However, in practice, sometimes it might be only necessary to take a quick glance at the CSV file to understand its column structure or just look at several rows examples. While looking at a raw large CSV file with lots of columns is inconvenient, reading a CSV file with Pandas in a Jupyter Notebook every time can be time-consuming. Is there a better alternative?

The answer is yes! Rainbow CSV is a very simple yet very useful plugin. All that it does is color every dataset column in a separate color, making it much easier to visually distinguish between different column values.

While there are other similar plugins available in the marketplace, in my opinion, Rainbow CSV provides a great color theme.

Conclusion

Plugins play an important role in the developer’s productivity. Though many software engineers do not pay too much attention to styling the IDE they use, I find the visual aspects of the IDE to be as important as the functional ones. By making the whole environment look more appealing, there is a much higher chance to look at code with greater pleasure and enjoy the development process even more!

The plugins we have looked at in this article provide a decent starting point for making the IDE’s user interface more attractive. Nevertheless, there is an abundant choice of other useful plugins available in the Visual Studio marketplace. As is common in software engineering, it is a crucial developer’s quality to broaden one’s horizons by exploring new tools and technologies!

Resources

• Extensions for Visual Studio Code
• JetBrains Mono. A typespace for developers

All images unless otherwise noted are by the author.

---

5 Amazing Plugins for an Eye-Catching Visual Studio Code UI was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.