Doge Does Research #3 - Dangers of DIY Datasets

A few weeks ago, we re-ran our comprehensiveness check, asking four frontline models to list every unicorn company in India, as of date. Find all things of a kind. And the results were underwhelming: even with web search enabled, each of the models missed loads of unicorns. The conclusion was simple - if you need a complete list, give the model the data. Don't let it go looking.

But that experiment raised a second question: even when the model has the data, how well and consistently can it classify things of a kind? For directories or structured datasets, taxonomies and classifications are the underlying governance layer and a missing or even a poor classification will severely curtail the usefulness of that dataset.

In this age of powerful web-based AI agents like Manus or native web search plus research capabilities of LLMs, there is an oft-repeated claim that frontline models or agents can now search, collate and organize small datasets with a high degree of consistency. We already know that searches that require comprehensiveness aren't quite working out yet. So, what of the second half of the claim around organizing data with consistency?

So we designed our follow-up test to check out the classification consistency of frontline models. We gave two models - Anthropic's Sonnet 5 and Manus 1.6 - the same task and three runs each. The task was - given a list of 10 well-known Indian startups and their websites (to avoid any ambiguity) the model is to classify each of them into a multi-level sector path. The models were allowed to search the web, look up the websites of these companies and then using the model's own training and expertise, come up with the classification for each company (sector > subsector > subsubsector type format).

This was the exact prompt:

And just like in the comprehensiveness tests earlier, the results this time too were problematic, but not surprising given what we know of LLMs. LLMs are not deterministic and even with long context or memory (in the case of Sonnet 5) the classification results don't converge. In each run, the model will redo the classifications even when it might have access to the results of an earlier run.

The Experiment

We asked each model to produce a sector classification for 10 companies:

• Acko
• BrowserStack
• Cardekho
• DarwinBox
• ElasticRun
• Fractal Analytics
• GlobalBees
• Icertis
• Juspay
• LeadSquared

Each model ran the same prompt three times - identical inputs, identical conditions. We then compared the outputs across runs to measure consistency.

What we found wasn't about accuracy. It was about reliability.

The Results

Sonnet 5:

Key findings:

• Perfect consistency (all 3 identical): None of the 10 companies received the exact same classification across all three runs. Not a single one.
• Two runs identical: Icertis and Juspay showed agreement between Runs 1 & 2, but Run 3 diverged. For everyone else, every run produced a different classification.
• Every run different: 8 of 10 companies had three distinct classifications across three runs.

Here's what that looked like in practice. Take BrowserStack. Run 1 called it "Technology > Enterprise Software > Developer Tools > Cloud-Based Testing & QA Platforms". Run 2 said "Technology > Enterprise Software > DevOps & Developer Tools > Software Testing & QA (Cross-Browser/App Testing)". Run 3 described it as "Technology > Enterprise Software > Developer Tools > Cross-Browser & App Testing Platform".

Same company. Same model. Same prompt. Three different answers.

The core concept was consistent - "developer tools for testing" - but the taxonomy shifted at every level. The model couldn't decide whether this belonged under DevOps, Developer Tools, or Enterprise Software. It couldn't agree on whether the category was QA, testing, or cross-browser platforms.

This isn't pedantry. If you're building a dataset that relies on these classifications - say, a market map, an investment thesis, or a competitive analysis tool - these differences matter. A company categorized as "DevOps" ends up in a different peer group than one categorized as "Developer Tools." The aggregation changes. The insights shift.

Manus 1.6:

Take Acko. Run 1: "Financials > Insurance > InsurTech". Run 2: "Financial Services > Insurance > InsurTech". Run 3: "Financial Services > Insurance > InsurTech > Direct-to-Consumer (D2C) Insurance".

The first two were similar, but Run 3 added a fourth level of granularity that fundamentally changes how the company would be grouped. Is Acko an "InsurTech" or a "D2C Insurance" company? Both are true, but they imply different competitive sets, different market dynamics, different analysis frameworks.

BrowserStack was even more revealing. Run 1: "Information Technology > Software > Software Testing & Quality Assurance". Run 2: "Technology > Software Development Tools > Cloud Testing & QA". Run 3: "Technology > Software > Software Development Tools > Testing & Quality Assurance (QA) > Cloud Testing Platform".

The taxonomy diverged at multiple levels. "Information Technology" became "Technology." "Software" became "Software Development Tools" then became "Software > Software Development Tools." The specificity of "Cloud Testing Platform" in Run 3 is far more precise than "Software Testing & Quality Assurance" in Run 1 - but that precision wasn't stable.

What This Tells Us About LLMs and Data Generation

There are three patterns here worth unpacking.

Pattern 1: The Taxonomy Shuffle

Both models consistently failed to anchor on a single taxonomy. They shifted between industry standard hierarchies, their own internal categories, and ad-hoc descriptive phrases.

Why this matters: If you're using LLMs to build datasets at scale - say, classifying 1,000 companies across sectors - this instability compounds. A company classified as "Fintech > Payments" in one run and "Financial Services > Payments Infrastructure" in another might end up in different analysis buckets. Your downstream insights become noise.

Pattern 2: The Granularity Glitch

The models oscillated between broad and narrow categories without apparent logic. Manus's Acko classification jumped from a two-level taxonomy to a four-level taxonomy across runs. Sonnet's Icertis went from full taxonomy in Run 1 to simply "Legal Tech > Contract Lifecycle Management (CLM) SaaS" in Run 3 - a qualitative shift in how the company is positioned.

Why this matters: Granularity isn't neutral. A broad classification groups a company with more peers; a narrow one isolates it. If you're using these classifications for competitive analysis, market sizing, or portfolio construction, the level of granularity determines what comparisons you can draw. And if that granularity changes from run to run, your analysis framework changes with it.

Pattern 3: The False Consensus Trap

If you had run just one classification per model, you'd have ended up with a complete-looking dataset. All 10 companies neatly categorized. No errors. No warnings. The model would have produced a tidy table that looked perfectly suitable for analysis.

But because we ran three runs, we know the truth: these classifications are anything but stable. The model is effectively sampling from a distribution of possible answers - and the distribution is wide.

Why this matters: This is the most dangerous pattern of all. LLMs produce confident-looking outputs even when they're uncertain. A single run gives you a false sense of precision. The risk isn't that the model gets it "wrong" in an obvious way - it's that it gets it "differently" every time, and you never know which version you got.

What This Means for You

If you're relying on AI to organize and classify your data, here's the practical takeaway:

1. More runs don't mean better classifications or convergence

Run your prompts multiple times. If the outputs vary frequently, you've discovered a classification problem, not a data quality problem. The model doesn't have one definitive answer and therefore this is not something that can be herded into convergence over N-runs or a mixture of experts.

2. Establish a master taxonomy

If you need consistent sector classifications, define your taxonomy upfront. Give the model clear categories and ask it to map companies to those categories rather than generating its own. This reduces the degrees of freedom and improves consistency. This can be quite taxing, but worth the effort.

3. Validate with humans

At least for a sample. If the model can't agree with itself across runs, it's unlikely to agree with a human expert either. Use AI for scale, but don't confuse scale with accuracy.

4. Use reliable datasets built for your specific task

And possibly the best solution is to use a high-quality organized dataset. It saves you from spending time and effort and not to mention the rework involved in trying to build these datasets by yourself.

The Way Ahead

There is a sobering conclusion for anyone building on LLM-generated datasets: the models' outputs can be accurate, in a run. But when repetitions are required, even the best of models will go astray. There is no getting around this consistency challenge except to use self-made or third-party organized datasets.

We encountered these challenges repeatedly when building our directory of funds and companies. When we tried to look up taxonomies that we could adopt or datasets that we could readily use, we only found low-quality options - free or paid. So we did things the hard but right way - we defined our own proprietary taxonomy for classifying companies and funds and built our directory ground up based on our taxonomy. And it is this very taxonomy that helps our users to search funds and companies with precision. And it does not stop at that, the same taxonomy is what underpins our deal generation.

Taxonomy > Organized data > Discovery > Deals - that's the path we followed and built on.
And you can use it too