Critically Evaluating LLMs: What Data Visualization Can Teach Us

These thoughts are gathered from the before, during, and after of a workshop I led as part of a data visualization conference. Big thanks to the Bar Chart Club Conference, led by Erin Waldron, for hosting the original workshop and helping to make it a success.

Introduction

In March I led a three-hour workshop called “Adding AI to Your Data Visualization Workflow.” A more accurate title might have been “Practical Tips for Thoughtful Engagement with AI and How to Resist the Creation of Meaningless Slop.”

We’re now on year four of large-scale public access to large language models (LLMs). The rosiest corporate-backed shine is definitely starting to wear off of generative AI (RIP tokenmaxxing, for example) as questions about financial cost and ROI become more urgent. While commonsense financial reservations are finally gaining more traction, generative AI is likely here to stay, at least in some capacity. 

Whether LLMs stick around or not, evaluating them through the lens of data visualization has changed the way I interact daily with these and other tech products.

Over the last four years, I’ve worked as a curriculum developer for Codecademy (now owned by Skillsoft), designing online interactive content in data visualization and analysis. Like many people in tech or tech-adjacent roles, I’ve been told multiple times to use AI whenever I can. Looking at AI through this data visualization lens is helpful and fairly comprehensive, because it requires attention to text, numbers, images, and code. Data visualization was my AI testing ground, and forced adoption by my employer kept me at it when on a personal level I would have said no again and again. 

The two major challenges that I ran into repeatedly are these:

• Generative language models will always have the potential to hallucinate. They regularly return untrue statements, and this problem is inherent to how they function.
• The LLMs most of us interact with are controlled by companies. The built-in sycophancy of chatbots to which you are, first and foremost, a customer is antithetical to transparency. We require transparency for data work.

If we choose to (or must) use the technology for data visualization work, how do we mitigate these harms?

There are a lot of things we can do. My solutions focus mainly on the ways that we think and talk about LLMs and how those translate into critical use. The solutions I propose here are questions for critical evaluation at multiple stages of projects (e.g., before prompting or afterward while evaluating a result). They fall into three major categories for thoughtful, effective use of AI:

• Accuracy: Is it true and verified?
• Security: Is my data safe and private?
• Sovereignty: Am I using the tool the way I want to?

While digital sovereignty can refer to laws and (inter)national-level regulations, in this case I’m talking about the choices we make about the tech we engage with. Where can we exercise control and self-determination and use our own judgments and values to guide our actions? While that’s often not part of the conversation because it’s the hardest one to quantify and probably takes the most introspection and critical thought, I think it’s maybe the most important as we consider what it will look like to exist alongside AI tools in the future. They’re part of the future, but they’re not the only part of it. 

So what are the questions?

Accuracy:

• Am I asking the AI to scrape web data and give it back to me in some capacity?
• Am I working within a defined universe (I’ll include the data and an example) or a more open universe? (I’m asking for something, but I’m not really sure what I want.)
• Have I set up boundaries against sycophancy to improve my ability to interpret the result?
• Can I verify the results? If so, did I verify the results?
• Do I know enough about this topic to be confident that the answers make sense? 
• One step further: Do I know enough about this topic to be confident that the answers are smart?

Security:

• Am I working with private data? (Mine or someone else’s.)
• Am I working with unpublished intellectual property? (Mine or someone else’s.)

Sovereignty:

• Am I working on a part of the process I actually love to do?
• In getting these answers via AI, will I lose an opportunity I value to find the answers on my own?
• Is my question or idea worth the resources I’ll be using to explore it this way? (This question deserves its own article. Environmental degradation in service of AI tools is reason enough on its own to be a conscientious objector.)
• Will I be comfortable disclosing that I used AI for this part?
• Does it add value to my project? (Especially with text.)
• Is it up to my standards?
• Am I erasing my own voice or opinions by using AI for this?

I arrived at these questions through grappling with those two challenges I mentioned earlier: hallucination and lack of transparency. Read on for lots more context.

Part 1 of the problem: Generative language models will always hallucinate

I’ll start with what is likely a familiar exchange, from a current Claude model in March 2026. I asked for compiled data from a Wikipedia table. This is a task I do fairly often for simple, public datasets that are regularly scrutinized for accuracy, so I wanted to see if Claude could do it instead. It worked for a bit and then returned an impressively well-formatted artifact, a spreadsheet with color coding and helpful filters applied.

I noticed that longitude and latitude had been stripped from the output, so I asked why they had been dropped. Claude replied that the web fetch had likely not rendered the data correctly, so it dropped the affected columns and didn’t flag the omission. Okay, not a huge deal. 

I dug a little deeper into the table and realized that the data was completely wrong. Names of power stations had been changed slightly, but most importantly, the key metric I wanted (power in megawatts) was incorrect more often than it was right. I asked Claude to give me some insight into what had happened.

It had failed to fetch my data and made up the results from its training data, then presented the table as a finished artifact rather than flagging that there was any issue. It also literally said “the web fetch gave me enough info” before making up the data.

Claude is also capable of doing this task correctly, which makes the failures much harder to catch. I’m not sure why the web fetch failed in this case, but I asked Claude to repeat the same task in the exact same language (in a different chat in the same account and on a different account) and it was able to give me a table with correct data. 

The issue of inconsistency means the tool is impossible to use efficiently. It appears to fail randomly, meaning it can never be 100% trusted. If we have to check every single output for something as basic as whether the data we already had is still correct when it comes back to us, then we’re wasting energy and time on mental babysitting instead of using that power for other tasks, including generating the artifact ourselves. (I’ll return to this idea later, in a discussion of prototyping.)

Despite nonstop hype over the last few years, despite C-suite missives to shoehorn AI in wherever it can fit, and despite AI models’ abilities to complete increasingly complex tasks, even current LLMs continue to fail at basic tasks, whether we notice or not.

What causes hallucinations? (LLM history and technology in five minutes)

To critically evaluate LLMs, we should have a basic understanding of how they work. And some history about chatbots is helpful as well. Standing on the shoulders of giants—that is, paraphrasing the work of my colleague Dr. Nitya Mandyam—I’ll tell you about ELIZA, the first chatbot, developed at MIT in the mid-1960s by Dr. Joseph Weizenbaum. 

ELIZA was a rudimentary chatbot built on simple pattern-matching rules, but even so, its conversation partners sometimes experienced an unexpectedly strong emotional connection to the bot. From “ELIZA”[will hyperlink ELIZA] on Wikipedia:

Weizenbaum first implemented ELIZA in his own SLIP list-processing language, where, depending upon the initial entries by the user, the illusion of human intelligence could appear, or be dispelled through several interchanges. Some of ELIZA’s responses were so convincing that Weizenbaum and several others have anecdotes of users becoming emotionally attached to the program, occasionally forgetting that they were conversing with a computer. Weizenbaum’s own secretary reportedly asked Weizenbaum to leave the room so that she and ELIZA could have a real conversation. Weizenbaum was surprised by this, later writing: “I had not realized… that extremely short exposures to a relatively simple computer program could induce powerful delusional thinking in quite normal people.”

The key idea that ELIZA demonstrates is that humans are naturally drawn to language-based robots. It’s very easy for us to humanize them, even when they are rudimentary. 

Today’s chatbots have evolved from rule-based systems like ELIZA to count-based models, and then to semantic ones. The foundation of these language models is natural language processing (NLP), which allows us to quantify language into usefully sized bits of information and then do math with those bits. 

One of the breakthroughs in the math of semantic, and later contextual, models is that they use vectors in abstract space, which allows us to map semantic meaning to words. To a count-based language model, “lead” is a token that can co-occur with “pipe” or “president,” among other words. To a contextual model, “lead” as in “pipe” is a completely different vector from “lead” as in “president,” because the words are quantified based on their contexts, not their characters. 

A key aspect of this difference is that it moves us from deterministic models, where outputs can only be sequences that already existed in the training data (anything else has a probability of zero), to probabilistic models, where outputs that are absent from the training data can occur because they have a nonzero probability. 

We can generate text that wasn’t in the training data. This is why it’s called “generative AI.” While this breakthrough in semantic language modeling is extremely powerful, it’s also the Achilles’ heel of the model. We always have the potential to generate text that is not in the training data, which might also mean that it’s untrue or impossible. 

This helps to explain both how the models are so powerful and can write such durable, readable text outputs, and how they are so unreliable and continue to hallucinate. There’s way more to the technical side, but the core idea here is that an LLM’s generative capability is the inexorable partner of its hallucination problem.

Part 2 of the problem: lack of transparency

Remember that Claude example? The issue of how Claude presented its work is another core problem. It shows us that the perception of a completed task is a more important output than an accurately completed task. 

LLMs are not just technologies. They are also products. LLM products such as ChatGPT or Claude are owned by companies—OpenAI and Anthropic, respectively. Their first goal is to keep you using their platform and convert you to a paid customer. Any other stated goal will always be secondary.

We know, from studying ELIZA, that humans are naturally drawn to become attached and form emotional connections with language-based robots. We find them to be really compelling, and we are very willing to believe them, identify with them, and trust them. This, in addition to their actual use cases, makes them a very sellable product. 

And the companies need to sell it. AI spending has far outpaced AI revenue in four successive years, and the gap between the two is growing. I asked Claude to make this graph comparing AI spending vs. revenue for OpenAI and Anthropic from 2022 to 2025, and felt just a bit of schadenfreude:

The companies are highly incentivized to sell and push their product. They need to capture market share and convert users to paid customers during this period of growth and relative investor confidence. This matters because the models are designed to create a feeling of convenience. Admitting that they have failed or cannot accomplish a task is not good for their bottom line and runs counter to their pie-in-the-sky marketing, so they don’t do it. 

LLMs are made by companies that value your perception of task completion more highly than they value the accuracy of task completion. The number-one goal is “task appears to be completed,” not “task is completed correctly.” This is why Claude uses the exact same cheerful tone when it returns garbage as when it returns something actually super useful.

That’s not even to mention its baseline complimentary, ingratiating tone. This sycophancy really, truly makes it harder to interpret LLM results correctly. We are not evolutionarily prepared for this type of social interaction, because if a human did this to us consistently, there would be social consequences. You wouldn’t keep going back to a colleague for help if they did the work wrong, cheerfully lied about it, and then gaslit you.

This lack of transparency is antithetical to how we do good data work.

Actual generative intelligence: collective knowledge created in the workshop

I won’t include a lot from the interactive part of the workshop, which was a group ideation session in which we spent about an hour answering questions individually and discussing them together. The goal was for us to reflect on the experiences we had already had with AI, think about aspects of our jobs that we did and did not want automated, ask technical and other questions, and explore the emotions and assumptions that we bring to AI conversations. 

When I opened up a space to be critical or skeptical, there was so much more of this energy than I anticipated. In this room, most of it came from people who had resisted the technology (some continued to; others had recently tried it out), but skepticism or negative feelings also came from people who used the technology daily and relied on it to get through a heavy workload. Some problems were reframed as issues with the workplace (devaluing of labor and expertise, understaffing and underfunding), not inherent issues with how AI technology works.

We recognized that there are successful AI use cases, especially in code-based tasks where the LLM output is code that can be better tested for accuracy and efficiency, and where the developer knows how to think programmatically and evaluate code output. (Although this, too, is rife with problems.) However, the reduction in nuance and idea building is a consistent blocker to implementations that meet our standards for non-AI work in data visualization.

So many new-to-me ideas came up—about the gender pay gap; about wondering if feeling proud of work an AI tool did was “allowed”; about the depths of automation fears from within a group of exceedingly competent business owners, analysts, and consultants. The workshop group happened to be a room full of women, and a feminist thread emerged in the conversation: questioning some of the ways we had seen people on LinkedIn (often but not always men) speak about AI, and talking about which ways did or did not resonate. I mean feminist in the Donna Haraway sense: that seeing everything from nowhere is a f—ed-up god trick, that all knowledge is situated, that disembodied “facts” can lead us further from useful truths (“Situated Knowledges,” 1988).

The common AI stance “get on board or get left behind” sat poorly with the group as a whole. It often lacks nuance and is blind to the skills that create exceptional work in data analysis and visualization. It’s not to say that AI tools can’t be helpful in data visualization. It’s that chasing them from a place of fear and inadequacy feels not only terrible but also incorrect.

We were collectively buoyed by this “AI therapy session,” as one participant called it. Space to openly acknowledge the significant failures of AI tools not only validated lots of experiences in the room, but it also made the genuine use cases for AI tools feel more rewarding to explore.

One more thought on what to do about it

So now we arrive at the challenges—hallucination, intentional lack of transparency—armed with more information. 

If we choose to (or must) use the technology for data visualization work, we can mitigate some of this harm with pointed questions. On accuracy: Is it true and verified? On security: Is my data safe and private? On sovereignty: Am I using the tool the way I want to?

I’ll leave you with one more solution and something else to read. Another solution we talked about in this workshop was the importance of prototyping. I cited Frank Elavsky’s excellent blog post from earlier this year, “On genAI: Was prototyping really a bottleneck?” in which he explores “what if the slow parts about prototyping are actually what make it worth doing?”

The key point here is that prototyping is where we test the intellectual rigor of an idea. I loved this graphic he included about the intellectual refinement and technical refinement of ideas. It makes it clear how incorporating AI early on in the idea stage can make shoddy ideas look sleek while really generating slop, and how the better opportunity for incorporating AI is the “zone of missing skills + resources” for ideas that have already proved themselves in a prototyping stage.

It’s hard to refine ideas with an AI tool. You have to be in the driver’s seat, because the tool is a reflection of what you ask for paired with a repackaged, statistically likely output of what others have already said on the topic. Elavsky puts it so well: “[P]eople tend to assume that the ideas they have in their head are really good, if they aren’t used to rigorously iterating on ideas.”

A partner who is incentivized to keep us on their platform isn’t one who will say “I just don’t like this direction” to a scrappy drawing in a notebook. Or one who will say “Oh wow, I’ve never thought about it this way before, but you’ve hit on something that’s pretty key.” But both of those kinds of feedback are actually helpful. The LLM partner will be whatever we tell it to be, but always in service of its corporate overlords. 

As Elavsky helps us to see, being thoughtful about when in the process we use AI helps us to develop robust ideas that are worthy of robust technical ends. 

And as this article attempts to lay out, questioning how we engage AI helps us introduce it critically into data visualization work, which demands high standards from visual, numeric, textual, and coding perspectives. 

The best data visualizations prove time and time again that good data analysis is human-centered, asks lots of questions, and makes genuine meaning out of numbers by transforming them into something we can see and contextualize. This part might be sped up or expanded by AI, but it cannot be automated. 

And hooray for that! This is the good part! This is the part that has drawn so many creative, critical, analytical thinkers to data visualization in the first place. Let’s use that same rigorous, flexible thinking when we engage with AI tools. Because if and how we choose to engage with AI in our data visualization workflows has implications for the tools themselves and for our outputs, certainly; but more importantly, if and how we engage with AI reflects how we honor our craft, our own brains, and our lives.