A Brief History of Data Science

Figure 2.1: A flowchart of the scientific method.

The invention of the modern computer from technology designed to wage war in the mid-20th century changed many aspects of society. It also drastically changed how we do science. Rather than being limited to observations we could record and analyze in notebooks, we now had the capability to analyze vast amounts of data more quickly than possible by a human, pending other technologies to observe and record the data (e.g. telescopes, DNA sequencing, etc.).

Figure 2.2: Computers allow analysis of more data, but require expertise to use effectively.

However, computers are themselves instruments that require some level of expertise to operate, and even more expertise to be able to use scientifically. In other words, while computing made the scale of science more powerful, it also required scientists to learn technical skills, such as programming, to be able to use computers to analyze data.

The advancement of large language models (LLMs) as a form of natural language programming in the past few years has largely obviated these technical roadblocks.

Figure 2.3: LLMs can remove the technical roadblocks of using computers for data analysis.
What is a large language model (LLM)?

A large language model (LLM) is a machine learning algorithm that has been trained on a large corpus of human written text to predict coherent strings of words. In this way, interacting with an LLM is similar to having a conversation.

While that definition is ultimately and technically true, it does undersell both the concerns and the capabilities of LLMs.

What are LLMs good at?

LLMs are extremely good at generating structured text. In other words, computer programming.

What are some concerns when using LLMs?

LLMs are also decent at generating unstructured text, which makes them seem conversational, and makes it tempting to use them for writing purposes. However, in these contexts LLMs can hallucinate facts, and produce subjectively bad writing.

LLMs can also make things so easy that it leads to cognitive surrender, in which the user doesn't critically think about what the LLM is producing. This could eventually lead to the loss of skills and knowledge, and may make one less likely to catch the LLMs errors.

Figure 2.4: While it is easy and tempting to allow LLMs to assist in the creative and critical thinking processes of the scientific method, this could easily lead to cognitive surrender of these skills.

Figure 2.5: A sign in Western Australia demonstrating the perils of cognitive surrender to GPS.

Beyond that, remember that LLMs are trained on human written text. This means that every program, piece of writing, and "novel idea" that they generate is built on the backbone of human creative labor, mostly unattributed and uncompensated.

How to use LLMs

There are several ways to interact with LLMs, with some companies having free tiers with limited usage. I'll mainly cover two ways of using LLMs and the various ways to use them: chatbots and agents.

Chatbots

Chatbots are simple interfaces that look like an instant messaging application. You type in a text box (what you type is called a prompt) and the LLM responds with text. You can then respond to the LLM's response, and so on. Chatbots are commonly used directly from the web or from a program (app) you can download directly on your computer.

Chatbots do not interface with the files on your computer or in your online repositories. They may be limited to just the text you provide in the chat, and may have older training data. However, many newer models have the ability to access the internet during chat to provide more up to date information.

Using chatbots for coding or data analysis requires copy/pasting and manually uploading and downloading files, however there is no way they can accidentally interfere with your scripts or data files.

I have commonly used chatbots for debugging specific errors, quick literature searches, and independent confirmation of code logic or another LLM's analysis plan (see below).

Figure 2.6: A brief interaction with a chatbot.

Figure 2.7: An example of a chatbot diagnosing an error message.

Agents

Agents are more advanced interfaces that can access your files, write code, and run scripts and commands on your computer. Many can also access the internet to search for information. Agents can be accessed through an app, an add-on to a text editor, or through a command line interface. Given a large enough tasks, agents may be able to spawn sub-agents to help. Agents are a powerful tool for data analysis, bringing the idea of "natural language programming" close to reality. But, given enough access and permissions, agents can perform potentially damaging actions, such as deleting files, or accessing a network.

Figure 2.3: An example of an agent interface in VSCode.

Practical tips for using LLMs

Providing guardrails

It is possible to provide guardrails to an LLM agent to limit its actions. Many LLM agent interfaces will have permissions settings that limit how the agent works, for instance by requiring the user to approve specific actions before they are executed (e.g. running a command or deleting a file). The main downside of this is that it requires the user to babysit the agent, clicking approve prompts constantly (perhaps leading to cognitive surrender).

Another way to provide guardrails is to create a file that contains instructions the agent should always follow. These instructions could be for every agent or could be project specific. However, the agent may not always read or retain these instructions within its context window, so it may end up breaking these rules anyway.

Plan and design

For software development or data analysis, the best defense against the LLM agent from doing something you don't want is to manually draw up a detailed plan before starting. This plan can be handed to the LLM. If needed, the LLM can provide feedback on the plan, or it can use it exactly as you specify. If you don't specify something in an analysis, the LLM may make an assumption for you. I have had these "hidden assumptions" trip me up multiple times.

Some LLMs have a "Plan mode", in which, given an outline of a problem, they can draft a plan for you to review before they execute it. This is a great way to get the LLM to give you options, but it is still your responsibility to have a clear idea of your question and analysis to know if the plan actually accomplishes what you want. The ease of this process can contribute to cognitive surrender.

Test and validate

This is mostly true about software development, but the best way to ensure the LLM has produced code that does what you want is to test it. Tests are already a common practice in software development, where one validates their code on data with known outputs. However, it is even more important now that LLMs may be generating the vast majority of your code. LLMs can even help write your tests... though if your LLM practices are poor this could lead to a cognitive surrender and easily become a circular confirmation of bad code.

Why are we still teaching bioinformatics?

Despite the rise of LLMs and other AI tools, we scientists still need to learn about the tools they're using in order to use them effectively for scientific inquiry. As stated above, LLMs remove many of the technical roadblocks to scientific computing and large-scale data analysis. However, in doing so, they also obfuscate the details of any data or analysis. It is your responsibility as a scientist to understand these details.

In essence, without having to learn how to technically handle the data, the focus for a data scientist instead can return to the basics of scientific inquiry. What are the questions we can ask and answer with so much data? What hypotheses can we test and how can we interpret the results honestly? This still requires learning skills and thinking critically.

Look at the data

Prior to LLMs it was a critically important (and yet often ignored) task to simply look at one's data. Knowing your data and data formats in general allowed you to know what tools you could use to process and analyze it. I argue that now it is even more important to look at and be familiar with your data because it again shapes what questions we can ask and how we can interpret the results.

Statistics

In terms of analysis and interpretation of results, it is still up to you as the researcher to be able to cognitavely process and understand how the data answers your questions. With large-scale data analysis, this requires an understanding of statistics. What null can you compare your data to? What statistical tests are appropriate for your data, null, and question?

Intuition

Above all, what an LLM cannot provide is intuition about your data and results. In short, its the ability to stare at a set of plots and question it ("This doesn't make sense.") or know when something is off ("Huh, that looks funny."). While a lot of discoveries start off with one of those thoughts, I can attest from experience that the vast majority of time, noticing those things means something about the data or analysis isn't appropriate for your question. This intuition is a skill that can only develop by learning and using the above practices. A cognitive surrender of these skills to an LLM will result in poor outcomes for both you and your research.

So, we'll get started with Project Organization