Comparing NLP APIs for Entity and Sentiment Analysis (vs Generative AI)

Comparing NLP APIs versus generative AI for entity and sentiment analysis

“Just use ChatGPT for it.” I hear this constantly about entity analysis, and I understand why, it is accessible and easy. But entity analysis sits at the centre of so many SEO projects, understanding your content at scale, the queries you rank for, the reviews customers leave, that getting it right genuinely matters. And as I am going to show you with a hands-on experiment, generative AI is quietly the wrong tool for the job. By the end of this post you will know which API to reach for, why, and how to defend that choice to a client or a sceptical colleague.

The contenders

On one side, pre-trained, task-specific NLP APIs from the tech giants: Google Cloud Natural Language API, Amazon Comprehend and IBM Watson NLU (you could add Microsoft Azure to this group too). On the other, the generative AI camp: ChatGPT, Google Gemini, DeepSeek R1 and Alibaba Qwen.

The important thing to understand first is that these NLP APIs are not single-trick tools. Each bundles a suite of modules for different natural-language tasks, and they overlap in useful and slightly different ways.

Which NLP modules Google Cloud, Amazon Comprehend and IBM Watson NLU each offer

Google Cloud Natural Language API gives you entity identification, entity sentiment, document sentiment, and, uniquely among the three, content moderation, plus text classification and syntax analysis. Amazon Comprehend covers entities, entity sentiment and document sentiment, and adds key-phrase (keyword) extraction, language detection, and PII detection; you can use it with no code straight from the AWS console demo, and the free tier gives you around 100 to 200 dollars of credits to test with. IBM Watson NLU is the most feature-rich for our purposes: on top of entities, entity sentiment and document sentiment, it does entity-relationship mapping (the “relations” module), emotion detection (joy, anger, sadness and so on), key phrases, concepts, classification, metadata and semantic roles. Learn all three and you can automate a huge chunk of your text-processing work.

Whichever you pick, a purpose-built API hands you far more than a list of entities. For each entity you get its type (person, organisation, product), its salience (how important it is in the document), a sentiment score and magnitude, the number of mentions and the different phrasings used, and metadata like a Wikipedia URL or a Google Knowledge Graph ID. That structured richness is what makes real downstream analysis possible, and it is exactly what a chatbot cannot give you.

The experiment: same text, same prompt

Talk is cheap, so I ran the same piece of text through every option, and the same prompt through every chatbot, to keep it fair. The results are stark.

Experiment results: entities recognised by each NLP API and generative model

Google Cloud’s NLP API identified 71 entities, 59 of them unique, across 7 types, the clear winner. Amazon Comprehend returned 22 (16 unique) and IBM Watson 17 (16 unique). Those look lower, but there is an important nuance: Amazon and IBM classify things Google calls “other” entities, concepts like “big data”, “machine learning” or “marketing”, as key phrases instead. Run Amazon’s key-phrases model on the same text and you add 50-plus phrases, which completely changes the picture. So the gap is partly a labelling difference, not a capability gap, which is exactly why you should test the same text across APIs before choosing.

On the generative side, DeepSeek R1 did surprisingly well with 38 unique entities across 9 types, Qwen returned 25, ChatGPT 15, and Gemini, remarkably, returned zero across every model I tried, Pro, deep research and experimental. So if you are absolutely set on using generative AI, DeepSeek is the pick. But I still would not recommend it, and here is why.

Why generative AI falls short

Why purpose-built NLP APIs beat generative AI for entity analysis

Scalability. An NLP API processes your whole site, keyword universe or internal-link audit with a single line of code. A chatbot does one-off analysis, one text at a time. Richer data. Only a purpose-built model returns entity type, salience, mention counts, metadata and relationships; a chatbot gives you a bare list. Repeatability. An NLP API returns the same result every run, so anyone can reproduce your analysis; generative output varies each time, which quietly erodes trust the moment a client re-runs it and gets different numbers.

On top of that, generative models will hallucinate entities that are not in the text (especially through the API rather than the chat), return unstructured output that resists further data analysis, and mis-attribute categories. The root cause is simple: there is no database of entities inside a GPT that it matches your text against. There is one inside Google Cloud, Amazon and IBM. Generative models are trained to generate plausible text, not to reliably extract and classify structured facts, and it shows.

What about sentiment analysis?

A quick but instructive detour, because sentiment is the other half of semantic analysis. In an experiment comparing Google, Amazon and IBM against a manually labelled dataset, Amazon and Google did well on positive and negative samples with good precision and recall, while IBM was more precise on neutral ones. Amazon and Google also agreed with each other most often; IBM diverged more. But here is the humbling headline: all three matched the human label only about 43% of the time.

The lesson is not that these APIs are bad, they are excellent at scale. It is that you still need a human review layer before you present or act on the results, and you should test a few APIs on your own data before committing, because performance varies by dataset. Generative AI for sentiment, meanwhile, is impractical and chaotic out of the box; you can nudge it with heavy prompting and a low temperature setting, but the results stay questionable, and for an introductory workflow it simply is not worth it.

Free versus paid

You do not have to use a paid cloud API. Open-source options like spaCy, NLTK, Stanford NLP and Hugging Face transformers (including BERT and DistilBERT) support entity recognition too, though spaCy and NLTK are more often used for the text-processing steps around it.

Cloud NLP APIs versus open-source local solutions

Cloud solutions win on instant plug-and-play usage, a broad suite of advanced features, automatic scaling, and easy integration, especially if your data already lives in BigQuery, where Google’s API drops in neatly. Open-source and local solutions shine when you need full data control for regulated projects (healthcare, finance), when cost at very high volume is a concern, or when you want to deeply customise and fine-tune for a specialised domain. One tip I always give: run a cost test on a cloud API before ruling it out, the price for large volumes is often surprisingly small, and the time you save is real. Ultimately the choice comes down to budget, scale, data-privacy needs, the features you want, and how quickly your team can pick it up.

Free resource

Grab the free Entity & Sentiment Analysis APIs: Comparative Review for the full breakdown of every module across Google, Amazon and IBM, so you can pick the right one for your data.

Where this goes next

This post makes the case for purpose-built NLP APIs. To put one to work, start with the free Entity Extraction with Google’s Natural Language API guide, and read what entity extraction is and where it fits in SEO for the concepts. Then see it all applied in the semantic analysis of customer reviews walkthrough, which uses Google Cloud and IBM Watson together. The full Entity Extraction and Analysis module inside Introduction to Machine Learning for SEO takes each API hands-on.