Pages

Showing posts with label big data. Show all posts
Showing posts with label big data. Show all posts

Thursday, 9 October 2025

AI is nether the danger or the solution many think


The biggest danger of AI is not that it will become Skynet and destroy us all. It is that it will make us too lazy to exercise critical thinking when doing research.





There are huge expectations that AIs of various forms will transform business and drive big  improvements in productivity. The stock market is currently rewarding firms like Microsoft and Meta (Facebook’s parent) not for huge success in deploying AI but for huge investments in the tech needed to run it. There is a good reason why Nvidia (the firm that makes the key hardware needed to build AI tools) is the most valuable firm on the planet right now (by market capitalisation). It is the company that makes spades that makes the money in the early stages of a gold rush.


Much of the faith in AI is driven by the apparent huge achievements in three things: beating human players at Chess and Go; solving the protein folding problem; providing convincing text in searches driven by chat engines like ChatGPT or DeepSeek. 


But these apparent successes are not as convincing as they appear. 


Take DeepMind’s success at building tools playing games like chess or Go. The extrapolation many want to make from this success is that, once set up, the computers seemed to learn how to play the games at an exponential rate. Therefore, the claim goes, if we set up a suitable AI it will rapidly outpace its creators and learn to solve any problem at a similar rate. But, given that we know how the learning algorithm works, this is a false extrapolation. 


To cut a long story short, DeepMind’s AI is a pattern recognition engine. Given a suitable training dataset it was able to see patterns of play that people found hard to see. It found clever and unintuitive ways to play Chess and Go that people had not learned. It learned rapidly and far faster than any human could. But what made the learning so rapid was not magical. The key was that in discrete finite games with simple fixed rules, the computer could generate a reliable training set of a huge number of complete games, a number far exceeding all the games that humans have ever played against each other. That large dataset provided a solid and reliable set of training data from which a pattern recognition engine could detect the interesting patterns leading to success or failure. The key is how quickly reliable training data can be generated. Since the boards of either game are finite and the rules of play completely unambiguous, a computer can create a huge set of possible games extremely rapidly and know for certain which patterns led to success or failure. Few real world problems are like that. 


The success of AlphaFold in predicting protein structures from amino-acid sequences looks like a counterargument. Alphafold has done a better job than several decades of alternative algorithms for predicting protein structures. I don’t question that. AlphaFold’s success is significant enough to deserve a Nobel prize. But it has not, as is often claimed, solved the protein structure problem. It has clearly found common patterns in the training dataset of known protein structures (we have several hundred thousand known structures and sequences from 5 decades of hard chemical effort since the first x-ray structures of proteins were seen) that evaded previous analysis. But that training set relies on the slow and difficult task of isolating proteins with known sequences, crystallising them and determining their structures using x-ray crystallography (with some help from sophisticated forms of NMR). For proteins similar to known structures, AlphaFold does a good job, but it often stumbles badly if the new protein is too different (it sometimes fails to predict the new structure when the protein sequence is slightlymutated and it often gives bad predictions when the new protein is very dissimilar to the known structures in the training dataset). The computer can’t do exponential learning as it can’t expand the training data without the slow hard work of real world biological chemists finding new structures. 


And extrapolating the success to claim that this will revolutionise drug development–as DeepMind founder Demis Hassabis has recently been doing, is jumping the shark. His claim that we might cure all disease or develop new drugs in months–not years–is ludicrous. There is a particularly good takedown of his claim by Science Columnist Derek Lowe (who actually works in drug development and rapidly saw through the factual absurdity of the Hassabis claims). The limiting factors for AlphaFold is generating the set of known structures for its training data and that is slow. The limiting factor for drug development is not knowing the structures of target proteins. Many factors matter including identifying which targets matter; designing and synthesising actual drugs that affect the target; testing those drugs in real animals to identify efficacy and side effects; testing their actual efficacy in people. All of that takes time that is unaffected by knowing the correct structure of a known protein target.


But, what about the manifest success of AI chat engines at generating computer code or research results far faster than people? Chat GPT is amazing! 


This is where claims that such tools will rapidly transform or replace many jobs is most worrying. I’m sure there are many jobs which could be replaced by AI. Many UK local newspapers are now owned by Reach plc. Their content is dominated by clickbait headlines designed to attract attention to an overwhelming flood of equally clickbait adverts. The entire operation could probably be managed by AI without using journalists at all with no diminution of the already abysmal quality. But only because the news and factual content has largely already hit rock bottom and the only performance metric that matters is how many clicks the headlines generate. That many are wrong, inaccurate, factually misleading, full of exaggeration or simply made up is pretty irrelevant. The journalistic ethos has already abandoned any commitment to truth or moral purpose or public good. So replacing journalists with AI that can’t have any useful purpose, focus on truth or moral stance would not make things any worse. By all means replace those journalists. 


Sure, many coders now use chat engines to generate code snippets. And this can often generate code much faster than they could write it. This is not unexpected given how AIs work. There is a huge volume of code out there to learn from and AIs can summarise or extract patterns from that huge training set. But is the code always good code? Since one of the major limitations of the design of most AIs is that they are poor at judgement, this is unclear. Some evaluations have actually suggested that, in aggregate, AIs lower the productivity of programmers (speed of writing code is not the primary metric that matters, speed of writing code that works for its intended use is what matters). 


A great deal of the time taken to develop software well is taken debugging; more is taken redesigning when users point out it doesn’t quite do what they expected; more is taken eliminating evils such as major security leaks A disturbing amount of AI code replicates major security problems after all the training set they have learned from is full of leaks and bad practice and no AI has the built in judgement to evaluate such things. AIs cannot reliably interpret intent; they are not designed to do so. Though, perhaps, this is also a criticism that can be levelled at many programmers who design their products to meet narrow technical descriptions but ignore the real people who need to use their software. For example, Hospital EPRs are notorious for being hugely hostile to the doctors and nurses who are their primary users.  No AI will fix that.


My own narrow experiments in solving simple problems in code often yielded useful rapid results. But my hit rate of code that worked was only about 50%.


And when it comes to using AI to search for useful results I have found what typical tools generate useful but also very unreliable. Chat engines like Chat GPT or Deepseek are in many ways a better search tool than a simple Google search. But the results, in my experience, almost always contain hallucinations. When writing a column recommending some key books for healthcare managers, I asked a question something like “tell me the top 10 books on health economics” In the list of ten, two were entirely fabricated (with plausible authors, titles and cover art). More recently, when I asked for academic references that had evaluated the lives saved by the London Major Trauma system (which I was involved in developing and had kept an eye on over the years) the top two references (both presented alongside hyperlinks supposedly linking directly to the publications) were both entirely fake (the hyperlinks were to real but unrelated papers). Google searches for the dates, authors or journals did not yield relevant papers. In this case using AI cost me more time in checking the results that I would have spent had I not used AI in the first place.


The ability of AIs to generate plausible text looks magical. But that text is untethered to any judgement about the quality or truth of the content. ChatGPT and Deepseek and others have been trained to be bullshit generators (in the sense used by philosopher Harry Frankfurt: bullshit is content entirely indifferent to the distinction between truth and falsehood). The ability to generate plausible pictures also seems magical. But many of those pictures are now polluting the internet with fake images (some historians are very worried about the proliferation of fake history backed by actual plausible-looking images that turn out to be AI generated). There is huge risk that this is a doom loop for reliable facts.


Given the way AI is currently built there is simply no way it can reliably solve difficult real-world problems. It simply doesn’t have a reliable training dataset it can learn from. The upside of this is that there is simply no possibility of AI turning into SkyNet and destroying us all. Creating an apocalypse requires reliable knowledge of how the world works which AIs are ill equipped to have. 


The real problem is entirely different. And it is a problem shared with many previous complex computer systems. People tend to believe the results the computer generates even when the results are wrong. The UK prosecuted many of the managers of local post offices for financial fraud on the basis of a big accounting system that contained many huge flaws. It took 20 years to start to fix this huge problem, described by the PM at the time as one of the biggest miscarriages of justice in the history of the UK. Trusting what the computer said despite evidence it was wrong was a major contributor to this catastrophe. But the system was not so opaque that the flaws could not, eventually, be uncovered. Had the system been an AI this might never have been possible as one of the characteristics of most AIs is a fundamental lack of transparency about how they derive their specific outputs. And AIs are very good at generating plausible outputs even when they are provably wrong.


In short it is the plausibility of AI output that is the big danger. When AIs have no ability to test the truth or falsehood of their outputs, plausibility is a huge danger. But that is as much a people problem as an AI problem. If AIs erode our sense of the difference between truth and falsehood or diminish our skepticism then we are in trouble. 



 

Monday, 6 June 2016

Ad hoc analysis of big data sources is easy if you use the right tools: an example using English prescribing data

A recent newspaper story highlighted large price increases for some generic drugs prescribed by the NHS. I was able to replicate the information in the story and explore other issues with drug pricing in a single afternoon. Here I describe how I did it. There are valuable lessons here for anyone who needs to get rapid analysis from large datasets.

Two stories in The Times (the original story, the follow up) claimed that the NHS was losing £260m a year due to extortionate pricing of some generic drugs, some of which had seen price increases of > 1,000% as their licence holders exploited a loophole in the pricing rules. I wanted to check their facts and investigate price changes in all the drugs prescribed by the NHS.

This blog is (mostly) about how I did that and I'm telling it because the lessons about how get rapid answers from large datasets are very useful in healthcare. But the NHS tends to use its vast repositories of data badly and is slow to adopt technologies to make the task of searching for insights faster and easier. What I did to validate the stories from The Times shows that, if you use the right technology for storing and querying the data, you can get almost instant insight whenever a new question arises.

The data source

The reason the question can be answered is that the HSCIC NHS Digital has been releasing the data about all prescriptions issued in England every month since August 2010 (you can find the latest month here). This data describes every prescription (not just the drug but the specific formulation) dispensed in primary care, which GP practice or clinic prescribed it and how much the NHS paid for it.

It is a large data source. Each month the raw data has about 10m rows of data in a single CSV file of about 1.5 GB. The full dataset is about 700m rows of data and takes nearly 100 GB of space to store. This summarises about 5 billion individual prescriptions. Even a single month is too large for convenient analysis by spreadsheet and the full dataset is too large to fit easily on a laptop hard drive unless you have a very powerful laptop and don't want to do much else with it. In my case it was prescribing data or several editions of Football Manager: no contest.

But the raw data isn't enough for useful analysis. Individual items (which can be drugs or a range of devices or equipment) are coded using only a 15 character BNF Code which describes the item uniquely but doesn't give much information about what it is (for example what the key active ingredient is). Prescribers are coded by a unique code that doesn't tell who they are or where they are. Some of this information is released alongside the data: a mapping of prescribers to their address is provided as is a mapping of the BNF Codes to the key ingredient.

But for convenient analysis we need to group the items together in a hierarchical way. The BNF (the British National Formulary) does this by assigning each item to a chapter, a section and paragraph/subparagraph which groups things together into meaningful categories. For example, the Cardiovascular System constitutes a chapter, Diuretic drugs a section and different types of diuretics are grouped together in paragraphs (with similar groupings for other cardiovascular drugs).

Unfortunately, the HSCIC doesn't provide an up to date list of the BNF categories. The Business Services Agency, which collects this data as a side effect of the process for paying pharmacists to dispense the drugs, does but it is in an obscure place (see instructions here) and it isn't kept rigorously up to date (so every month you need to do some manual editing when new drugs are launched and, when the BNF reorganises the hierarchy, even more work is required to tweak the mappings between old codes and the new structure). Luckily, I've been keeping my data up to date.

Storing and managing large data sources

I've been keeping an up-to-date copy of the prescribing data since I was involved in developing a tool to help medicne managers exploit it several years ago. While building that tool I explored several ways to help store and manage the data and several tools to make it easy to analyse. The combination I ended up with is Google's BigQuery and Tableau. BigQuery is a cloud data warehouse optimised for fast queries on large datasets. Tableau is a desktop visual analytics tool that works well alongside BigQuery (or most other databases).

What is particularly fantastic about BigQuery is that it allows superb analytics query speed for no upfront investment. To achieve similar speeds on in-house systems you would have to spend tens of thousands on hardware and software: BigQuery give you almost interactive analytics performance as soon as you have loaded the data. And you only pay for storage and the volume of data returned by queries, neither of which are expensive. No database tweaking or maintenance are required. And, if you drive you analytics from Tableau, you don't even have to write any SQL to get results: it is all driven by visual actions inside Tableau.

In fact the hardest and most time consuming parts of the process of managing the prescribing data is maintaining the metadata which requires sourcing and manipulation of data from a variety of other sources.

Some basics about the dataset using Tableau

My core data and metadata are already stored in BigQuery so all I need to do to analyse it is to connect Tableau to the data sources and define the relationships between the core data table and the metadata tables. Tableau has a neat visual window for defining these relationships. The only other steps required for interactive analysis is to define some additional calculations for convenience. This is as easy as writing formulae in a spreadsheet. In this case I had to convert the dates in the data source (YYYYMM format) into dates Tableau can understand via simple string manipulation and I had to define some new formulae to calculate things like the average cost per prescription.

The hardest part of doing the analysis relevant to drug prices was remembering how to calculate changes in price from a fixed date in Tableau (it is easy: see here for a guide to doing it).

Once Tableau is plugged into BigQuery and those additional calculations are set up, everything else is a matter of a few minutes away. Query results from BigQuery can take ~30s on a bad day and Tableau will return tables or charts straight away which can all be modified or adjusted visually without the user needing to go to SQL or some other query language. The interactive and visual approach used by Tableau allows the user to focus on getting the right question, the right analysis and the right presentation of the data.

The analyses

The table below, for example, took a couple of minutes to generate even though it summarises all of the drugs issued since 2010 in several different ways (part of the process was to summarise everything and then eliminate the devices and dressings categories).

basic drug stats with cost.png

It is easy to create visual analysis as well as tables. This summary of monthly spend and prices took a few more minutes to generate:

monthly totals chapter.png

This is very high level summary analysis, but Tableau makes it easy to drill down to the lowest levels of detail available. For addressing the question posed by the stories in the times I needed to look at the changes in prices of individual drugs (or chemicals) over time.

It is easy to set up the analysis. I just had to create a table showing the volume and average price of all chemicals by date (this is a big table as there are nearly 2,000 unique chemicals though not all the ones in 2016 were also used in 2011). I sorted the table and selected all the examples where the price was more than 400% higher in january 2016 than it was in january 2011 (my threshold is slightly different than the times). Then I grouped the low volume examples together and got this table:

all drugs with >400% increases.png

This gives a good general overview of the places to look for big price hikes.

We can also do specific analysis of individual chemicals. The times mentioned 4 in particular. Their volume and price history is shown in the chart below.

duges mentioned by The Times.png

Again, this took only a few minutes to generate. Note the log scales used to fit the enormous price increases into a scale you can read.

Of course, we can also do ad-hoc analysis of things that the Times Didn't ask, like which drugs have seen the biggest price decreases because of the benefits of generic competition. That table is below:

drugs 4 time cheaper.png

The NHS is saving >£70m every month for this list alone (and if we took rising volume into account the savings would be even bigger).

If you pick the right tools for analysing big data, you can spend time focussing on the questions

It took me an afternoon to replicate the Times analysis and to go much further. Admittedly, I already had the data and platform for analysing it. But this is much faster than can be achieved by any tool provided by the NHS. This is strange because a number of key NHS improvements depend on good analysis of this dataset. The Times highlighted where it is useful in controlling spending by highlighting excessive pricing based monopolistic positions from suppliers. But the same data can highlight who prescribes too many antibiotics, those who don't give their patients the right mix of diabetes medication or where modern alternatives to warfarin are being used.

Making the data easy to work with is an essential part of making it useful. Platforms that allow rapid answers to be derived from the complete dataset are far better than tools that allow only local or partial analysis. Many smart people are currently wasting weeks of their valuable time wrangling parts of this dataset to answer smaller, less useful questions. They should be applying their brains to bigger questions and the NHS should be giving them the tools to make them more productive.

This isn't happening. Ben Goldacre, for example, struggled to get NHS funding for an online tool that allows this sort of analysis to be done by anyone (this now exists in beta form but has mostly be funded by charities not the NHS).

And the NHS has many other large datasets it needs to make use of. Patient level data for outpatient, A&E and inpatient activity all exist but are significantly underused, partially because finding interesting patterns is hard and slow.

But the world of data analytics has changed in the last five years. The tools exist to take the time and the drudgery out of big data analyses. The NHS should be using them.