How LLMs Like ChatGPT or Gemini Turn Customer Feedback into Business Recommendations

Large language models like ChatGPT or Gemini do not learn from your customer feedback on their own. Feedback reaches a model in one of three ways: pasted or attached into the prompt, retrieved from a feedback store when someone asks a question (retrieval-augmented generation, or RAG), or, rarely, used to fine-tune a model.

Systems that turn customer feedback into business recommendations you can act on are pipelines, not chats. The model labels each piece of feedback into a fixed schema, ordinary code counts the labels, retrieval pulls representative quotes, the model drafts recommendations that cite them, and a person decides. The worst failures come from letting the model do another part's job, usually the counting.

I wrote a short piece on LLMs and customer reviews in 2023. This is the longer answer, and it starts with a common assumption: that a model learns from your reviews over time.

Do ChatGPT or Gemini learn from your customer feedback?

Not in the way people usually mean. A model's weights do not change while you use it: it reads the reviews you paste in, or whatever a retrieval step returns, for that request. Fine-tuning changes the weights, but I think it is a poor fit here: it teaches a task or a style, it cannot show which review supports a claim, and next month's feedback makes it stale.

Can your feedback end up in a vendor's training data?

That depends on the product, not the model. As of September 2026:

Product	Eligible to improve models by default?
ChatGPT Free, Plus and Pro	Yes, unless you opt out in Data controls
ChatGPT Business, Enterprise and Edu, and the OpenAI API	No; the API has an opt-in
Gemini app, personal account	Yes while Keep Activity is on, and human reviewers read some chats
Gemini API, unpaid tier	Yes, and human reviewers may read it; the paid terms apply in the EEA, Switzerland and the UK
Gemini API, paid tier	No
Gemini in Google Workspace	No, not outside your domain without permission

Source: the OpenAI and Google policy pages listed below.

Feedback full of names, phone numbers and order details does not belong in a personal account. Google's terms for its unpaid API tier say "Do not submit sensitive, confidential, or personal information to the Unpaid Services." Not training is not the same as not storing: OpenAI keeps API abuse-monitoring logs for up to 30 days by default, and Google logs paid-tier prompts for a limited period to detect misuse. Even where a vendor trains on chats, as I read these terms, that feeds a future general model, not one that remembers your reviews.

How LLMs turn customer feedback into business recommendations

The design that holds up gives each job to whatever does it best.

Step	Done by	Output
1. Clean	Code	Duplicates, spam and personal data removed
2. Label	Model, one item at a time, into a fixed schema	Topic, sentiment, product area, and the verbatim words behind each label
3. Count	Code, such as SQL	Counts by topic, week, product and channel
4. Retrieve	Search over the labelled store	A few quotes per topic, with their IDs
5. Draft	Model, given only the counts and quotes	Recommendations that cite count and quote IDs
6. Decide	A person	Accept, reject, or ask for more evidence

The model never counts, and it never sees all the feedback at once. Ask a chat for the top five themes in 20,000 reviews and you have asked for five, whether or not the data has five.

The pipeline also answers questions. Asked why delivery complaints rose last month, it filters the labelled store by topic and date, counts with code, and hands the model the counts and sampled quotes. That is RAG over feedback, with the labels doing most of the work.

Step 4 hides a trap. Semantic search returns the reviews most similar to the question, and a reranker sorts by relevance; neither measures how typical a review is. For quotes that stand for a theme, sample at random within the labelled group. Use similarity to find evidence, never to measure frequency.

What Amazon and Apple published about review summaries

Amazon announced AI-generated review highlights on August 14, 2023: a short paragraph on the product page summarising the features and sentiment mentioned most often in written reviews, first for a subset of US mobile shoppers. It draws only on reviews from verified purchases, so filtering comes first. A shopper can also tap an attribute such as ease of use to see the reviews that mention it, which ties each theme to evidence.

Apple's April 2025 write-up of App Store review summaries (iOS 18.4) describes the whole pipeline. Spam, profanity and fraud are filtered out first. A fine-tuned model splits each review into single statements, each with one topic and one sentiment. A second model names topics without a fixed list, and embeddings merge near-duplicates. Topics are picked mainly by popularity and checked against the app's overall rating, then a third model writes a summary of 100 to 300 characters. Human raters scored thousands of samples for safety, groundedness, composition and helpfulness. Apple publishes no scores.

Apple did fine-tune, with reference summaries written by human experts, but that taught the job; the reviews are still read as input. Its free-floating topics suit a summary that refreshes. For trends compared month to month, I would freeze the topic list and have a person review an "other" bucket.

How accurate are LLMs at reading customer reviews?

Both peer-reviewed studies I could read in full used GPT-3.5 models from 2022 and 2023, so I read them as a map of where errors cluster, not today's accuracy. I have not rerun either.

Task (dataset)	gpt-3.5-turbo, zero-shot	T5-large, fine-tuned
Positive or negative (Yelp-2, accuracy %)	97.80	96.33
Star rating, five classes (Yelp-5, accuracy %)	52.40	65.60
Aspect and its sentiment (SemEval-2014 restaurants, micro-F1)	54.46	75.31
Ten aspect-based datasets, average micro-F1	34.47	61.06

Source: Zhang et al., Findings of NAACL 2024, Table 1, up to 500 test examples per dataset. The 770M-parameter T5 was trained on each full training set; aspect-based scores need an exact match.

A general model sorted reviews into positive and negative as well as a trained one. It was weaker on star ratings, and much weaker at the aspect-level reading a recommendation depends on: which feature, which opinion, which direction. A fixed schema and a hand-labelled sample have to cover that step.

For summaries, Bhaskar, Fabbri and Durrett (Findings of ACL 2023) ran pipelines built on text-davinci-002 over hotel reviews (SPACE) and Amazon and Yelp reviews (FewSum). The authors rated 50 hotel summaries per pipeline themselves and scored factuality at 2.85 to 2.88 out of 3. The errors were quieter: one reviewer's opinion presented as the view of several, then generalised into a claim other reviews contradicted. Summarising summaries, which they used to fit long inputs, made faithfulness worse.

Where LLM feedback analysis goes wrong

Invented themes. A theme with no labelled items behind it is a story. Every theme in a recommendation should resolve to a count.
Numbers the model wrote. "38% of customers mention delivery", from a model that read a sample, is a guess formatted as a fact.
Vivid beats common. One detailed complaint can outweigh forty short ones, as in the hotel example above.
Who wrote it. Reviews come from people who chose to write; a customer who quietly leaves writes nothing. The counts describe the feedback, not the customer base.
Duplicates and fakes. One complaint posted on three channels, or a burst of fake reviews, inflates a theme. Amazon and Apple both filter before the model reads.
Mixed languages. If feedback arrives in Arabic and English, sometimes in one message, measure accuracy per language. On Auto-RAG, whose MVP I architected and built, every customer brought a different corpus, a different language mix and a different tolerance for a wrong answer. One average would hide that.
Personal data in free text. Redact names, phone numbers and order numbers before the text reaches any model.

I would design out the invented number first, because it is the one that reaches a slide. In the Verifiable AI Analyst, the model never calculates, and a mechanical check we call the digit net rejects any run of digits in the text that the engine did not produce. In a feedback pipeline the engine is step 3: if 38% is not in the aggregation output, the sentence does not ship. A digit check will not see "most customers" or "nearly half", so quantity words need their own rule. The wider design is in building a governed AI analytics system.

How to evaluate a customer feedback pipeline

Hand-label a sample. Two people label a few hundred items with the same schema, without seeing the model's labels.
Measure agreement. Compare the two people first, then the model with each, per field and per language, using Cohen's kappa or another chance-corrected measure. People disagree too: in the summary study above, the authors agreed only slightly on faithfulness for Amazon and Yelp (Fleiss' kappa 0.19).
Check every quote. Each quoted line must exist word for word in the source. One that does not is fabricated, however plausible.
Refuse unexplained numbers. Any number the aggregation step did not produce is rejected, not reviewed.
Plant an answer. For the Verifiable AI Analyst I built Data Invoker, a synthetic-data engine that simulates customers' orders, reviews and complaints from personas, and ships an answer key with the planted segments, cadences and churn points, plus deliberate decoys. For feedback: plant a theme and a decoy, and see which the pipeline reports.

It is the same discipline as evaluating a production RAG system: freeze the test set, score each stage separately, and let the result stop a release.

The model can read forty thousand reviews in an afternoon. It just does not get to say how many there were.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, governed AI analytics, and model evaluation.