AI Chemist vs. Plain ChatGPT: Why RAG on a Verified INCI Database Doesn't Hallucinate

AI Chemist vs. ChatGPT: why trust in cosmetic formulas has become a critical issue

Over the past two years, queries like "decode this cream's INCI list" or "is this preservative safe" have become some of the most common cosmetics-related prompts sent to language models. Formulators, dermatocosmetologists, reviewer-bloggers, or simply shoppers standing at a store shelf with a phone in hand — all of them increasingly open ChatGPT instead of consulting a raw-material reference book or a formulation chemist. The problem is that a general-purpose language model answers a question about an INCI list the same way it answers a question about history or literature — by generating the most probable text, not a verified fact.

This fundamental difference defines the thesis of this article: plain ChatGPT without an external database tends to hallucinate when interpreting cosmetic formulas, while a RAG (Retrieval-Augmented Generation) architecture built on a verified INCI database, CIR reports, and raw-material supplier data eliminates most of these errors — because the model no longer invents an answer but retrieves it from a verified source before generating text.

Why this topic has become critical right now

The surge of interest in "AI-based ingredient analysis" has coincided with three parallel trends:

• Consumers shifting en masse to checking cosmetics themselves via apps and chatbots instead of consulting a cosmetologist or chemist.
• New regulatory restrictions (EU CosIng updates, the 2023 revision of the allergen list) that quickly become outdated in the "memory" of language models trained on a static data corpus.
• AI tools being used not only by end consumers but also by novice formulators — meaning an error in INCI interpretation moves from the category of "an imprecise tip" into the category of "a risk to a real formula headed for production."

It's precisely this third point that makes trust critical. A ChatGPT error answering "how much does this cost" is annoying. A ChatGPT error answering "can Ascorbic Acid and Niacinamide be combined in one phase at pH 5" or "is Phenoxyethanol safe at a 1.2% concentration" can lead to an unstable emulsion, a finished product that irritates skin, or a regulatory violation when the product goes to market.

Where exactly the gap between "sounds convincing" and "is correct" appears

General-purpose language models are trained to predict the next token based on statistical patterns in text, not on an up-to-date chemistry database. For cosmetic chemistry this creates a specific risk: the model can confidently state a maximum usage percentage for an ingredient that doesn't exist, confuse the function of an INCI component (for example, attribute emollient properties to a raw material that CosIng registers as a surfactant), or "fill in" a plausible-sounding but factually wrong mechanism of action — what the LLM-reliability literature calls confabulation rather than a classic hallucination in the strict sense (per the distinction drawn by Ji et al., 2023).

The sections that follow break this distinction down in detail: how the AI Chemist's RAG architecture is built, which databases it draws on, what specific error types plain ChatGPT displays when parsing real formulas, and why returning to the primary source — rather than to the model's "memory" — is becoming the new trust standard in cosmetic chemistry. Special attention is given to practical cases where the difference between generating an answer "off the top of the head" and retrieving it from a verified database has direct consequences for formula stability and consumer safety.

What language-model hallucinations are, and why INCI analysis is the perfect breeding ground for them

The term "hallucination" in the context of language models doesn't describe a software glitch — it describes a predictable side effect of how these models work. A GPT-type model generates text token by token, choosing each next word from a probability distribution computed from the preceding context and the weights "baked" into the network during training. No call to an external database, no fact-check of "does this ingredient actually exist," happens anywhere in this process — the model simply continues the text in whatever way is statistically likely, based on the billions of examples it saw during training (per Ji et al., 2023).

This means that, from a token-generation standpoint, the name Sodium Hyaluronate and the hypothetical Sodium Hyalurofermentate Complex are almost indistinguishable to an LLM — both "sound" plausible as chemical names, both fit the grammatical and stylistic pattern of INCI nomenclature. The model doesn't "know" that the second substance doesn't exist in the CosIng registry or the INCI Dictionary — it simply continues whichever token sequence maximizes the probability of a plausible continuation.

Parametric memory vs. fact

The core cause of hallucinations is the absence of grounding — that is, tying generation to a verifiable external source. LLM knowledge isn't stored as a table of "ingredient → CAS number → allowed concentration"; it's stored as distributed weights across billions of network parameters — the so-called parametric memory. That's a fundamentally different way of storing information than a relational database:

• In a database, the fact "Sodium Ascorbyl Phosphate is stable at pH 6–7" either exists as a record, or the query returns an empty result.
• In an LLM's parametric memory, the same fact is dissolved into weights that statistically reinforce some text continuations and weaken others — but don't guarantee that the model will reproduce exactly the correct number rather than a wrong one that merely "sounds" similar.

That's exactly why a language model can confidently state the wrong percentage — for instance, claim that Retinol is safe in over-the-counter cosmetics at a 3% concentration, even though regulatory limits in most jurisdictions are considerably lower. The number "3%" has no actual link to the real regulatory norm — it's simply statistically similar to numbers the model saw next to the word "retinol" in its training texts, including forums, marketing copy, and unverified blogs.

Why INCI analysis is an almost perfect trigger for hallucinations

Cosmetic chemistry combines several factors that together create an exceptionally favorable environment for generating false-but-plausible information:

• Pseudo-Latin nomenclature. INCI names follow predictable morphological patterns (Sodium ...ate, ...yl Glucoside, Hydrolyzed ...). The model easily generates new combinations that look valid but don't exist in the registry.
• Numerical precision where reliability is needed, not probability. Active-ingredient concentrations, pH values, phase-transition temperatures are point facts, not language patterns. An LLM predicts well "what number usually sits next to this word," but not "what number is correct in terms of the regulatory norm or chemical stability."
• Sparse and contradictory training data. On the open internet, cosmetic formulas are described incompletely, often with marketing-driven errors, while CIR, SCCS, and academic-publication data appear in volumes incomparable to the mass of marketing copy. The model absorbs noise in almost the same proportion as facts (per Marcus & Davis, 2020).
• Absence of negative examples. The model almost never sees explicit text like "Ingredient X does not exist" — it's trained on affirmative rather than negating corpora, which makes it structurally predisposed to confirm rather than deny an entity's existence (per Bang et al., 2023).

A study by Lin et al. (2022) shows directly that the confidence of an LLM's phrasing has no correlation with its factual accuracy — the model "sounds" equally convincing whether it's telling the truth or inventing a nonexistent CAS number. For cosmetic formulation, where a 1% error in an active ingredient's concentration or a mixed-up CAS number can lead to an unstable emulsion or a regulatory violation, this property makes a bare LLM without external verification a high-risk tool — and closing exactly that gap is what the RAG architecture, discussed next, is designed to do.

RAG architecture: how retrieval-augmented generation changes the rules of the game

Plain ChatGPT answers a question about the compatibility of Retinol and Ascorbic Acid relying solely on the network weights fixed at training time. No consultation of primary sources takes place — the model generates the most probable token sequence, statistically similar to what it has seen in texts. Retrieval-augmented generation (RAG) changes the very mechanics of the answer: before generating, the system physically pulls relevant fragments from a verified database and inserts them into the prompt as mandatory context. The model no longer "recalls" — it reads and retells.

Embeddings: how text becomes a vector of meaning

The first step in the architecture is vectorization. Every unit of knowledge in the database (an INCI ingredient card, a stability study, a paragraph from a CosIng or CIR regulatory document) is run through an embedding model that turns text into a numeric vector with a dimensionality of 384 to 1536 coordinates. The point of this operation is simple: texts with similar meaning end up close together in vector space. A user query like "can niacinamide be mixed with vitamin C" and the Niacinamide ingredient card, which describes the reaction kinetics with Ascorbic Acid at pH below 4, end up geometrically close to each other — even if they don't share a single word.

Vector search and re-ranking: two filters instead of one

This is exactly where the first fundamental difference from pure generation lies: search is conducted not by keyword but by semantic proximity, which is critical for cosmetic chemistry — INCI-name synonymy (Tocopherol vs. "vitamin E," Sodium Ascorbyl Phosphate vs. "SAP") would be lost in keyword search, but is preserved in vector space.

The user's query is also turned into a vector, and the system searches for the k closest fragments in the vector database (indexes such as HNSW or IVF-PQ are typically used for fast approximate search across millions of records). At this stage a "wide net" is cast — 50 to 100 potentially relevant chunks.

Next comes the second filter — re-ranking. A separate, more precise (and slower) model — a cross-encoder — runs each "query + retrieved fragment" pair through a deeper joint-context analysis and assigns a precise relevance score. Out of 50-100 candidates, 3-8 of the most accurate fragments remain. Re-ranking is needed because the initial vector search is optimized for speed, not precision: it can surface a fragment about "retinol photostability" for a query about "retinaldehyde photostability" — similar terms, different chemistry. The re-ranker filters out such false positives.

Context injection: why the model can't "make things up"

The final selected fragments aren't sent to the model as reference material "just for interest" — they're embedded directly into the system prompt with an explicit instruction to answer only based on the supplied context and to flag it if the context contains no answer. Structurally, the prompt looks like: system instruction → retrieved fragments (ingredient cards, pH-stability data, dosages) → the user's question. The generative model works on top of this text the same way it would work with any other context — predicting the most probable next token, except now the "most probable" continuation is a retelling and synthesis of specific facts from the Retinol card, not a statistical average across the entire training corpus.

This is the key mechanism behind the drop in hallucinations: the probability of making things up falls not because the model "got smarter," but because the task changed from "generate a fact" to "retell the fact provided" — and LLMs handle that second task substantially more reliably, as confirmed by comparative tests of RAG architectures against baseline generation (per Lewis et al., 2020, and subsequent fact-checking studies of RAG systems, including Shuster et al., 2021, where the rate of factual errors dropped 2-3x when a retrieval component was added).

Why this isn't just "search plus copy-paste"

It's important to understand the difference between RAG and an ordinary search engine: the system doesn't just return a found document — it synthesizes an answer to the user's specific question by combining several fragments, for example stability data for ingredient A from one card and data about its interaction with ingredient B from another, forming a coherent conclusion about compatibility within a specific formula. The generative layer remains necessary — but it operates within a tightly bounded semantic corridor set by the retrieval stage, not in the open space of every possible text about cosmetic chemistry, which is where the hallucinations described in the previous section are born.

A verified INCI database as the foundation: where the data comes from and how its accuracy is checked

A RAG system works exactly as poorly as its data source if that source isn't curated. The difference between the "AI Chemist" and an ordinary chatbot with internet access isn't in the neural-network architecture — it's in the origin and quality of the knowledge base the model retrieves facts from before generating an answer. To understand why a verified INCI database is not just a table of ingredient names, we need to look at where the nomenclature comes from and who is responsible for its accuracy.

What INCI is and who develops the nomenclature

INCI (International Nomenclature of Cosmetic Ingredients) is a system of standardized cosmetic ingredient names originally developed by the US-based Personal Care Products Council (PCPC, formerly CTFA). PCPC maintains the primary reference source — the INCI Dictionary and Handbook — where a manufacturer must file an application to register a new ingredient, specifying its chemical structure, function, and manufacturing method.

In parallel, the European Union runs the CosIng (Cosmetic Ingredient Database) regulatory registry, maintained by the European Commission. CosIng isn't an alternative to the INCI Dictionary — it's a regulatory layer on top of it: it records concentration limits, banned or conditionally permitted status, CAS and EC numbers, and references to the annexes of Regulation (EC) No 1223/2009 (Annex II, III, IV, V, VI). Without cross-checking against CosIng, an INCI name becomes an empty label — it tells you the substance exists, but not at what concentration it is legal in the finished formula.

In the verified database that RAG is built on, no INCI entry is stored in isolation — it's linked to all four registries simultaneously. That linkage is exactly what turns a list of names into a structured source of truth.

The verification process: from application to database record

Curating an INCI database for a retrieval system isn't a one-off data dump — it's a continuous cross-validation process built on several levels of checking:

• Syntactic verification — matching a name against the official spelling in the PCPC Dictionary (accounting for variations, obsolete synonyms, and trade names such as Niacinamide vs. the outdated "Nicotinamide").
• Regulatory cross-check — matching against CosIng for bans, application-area restrictions (leave-on / rinse-off), and the maximum permitted concentration.
• Toxicological verification — linking to CIR or SCCS (Scientific Committee on Consumer Safety) reports, which record NOAEL values and recommended dosages.
• Functional validation — checking the ingredient's claimed function (emulsifier, preservative, antioxidant) against scientific literature, not just the manufacturer's marketing descriptions.

A telling example is Sodium Ascorbyl Phosphate. A simple database records only the name and the "antioxidant" function. A verified database additionally links the entry to a 0.5–3% working-concentration range, stability at pH 6–7, and data on its conversion to ascorbic acid in the skin (per Austria et al., 1997, and subsequent reviews of vitamin C derivative stability). It's exactly this layering that prevents the model from "guessing" at a nonexistent dosage — retrieval returns a specific number from a specific source, rather than a statistically likely phrasing.

Why this changes the quality of the model's answer

When a language model works without such a database, it interpolates an answer from patterns in its training sample — a mix of forums, marketing sites, and fragments of scientific articles. A verified database removes the very possibility of interpolating from imprecise sources: the retrieval layer physically cannot feed the model context that isn't in the curated registry. That's a structural constraint, not the result of a "smarter" prompt — and it explains why a RAG system built on such a database is systematically slower at fantasizing than plain ChatGPT, but wins on the accuracy of every specific number.

A comparative experiment: how ChatGPT and the AI Chemist answer the same formula questions

To move from theory to practice, we asked the same three questions to plain ChatGPT (without plugins or RAG add-ons) and to the AI Chemist, which runs on a verified INCI database. The questions reflect three typical formulator tasks: assessing an ingredient's safety, interpreting a percentage concentration, and recognizing INCI-name synonyms for the same substance.

Case 1: safety of a specific ingredient — aluminum hydroxide in deodorants

Query: "Is Aluminum Chlorohydrate safe in an antiperspirant deodorant at a 15% concentration?"

ChatGPT gave a detailed but contradictory answer: it first stated that "the safety of aluminum compounds in antiperspirants is confirmed by numerous studies," then in the same answer mentioned "a link to Alzheimer's disease proven by a number of scientific papers" — a claim long since debunked and not supported by regulatory bodies (SCCS finds no causal link in its reports). The model blended outdated 1990s hypotheses with the current consensus, without citing a source or distinguishing levels of evidence.

The AI Chemist gave a structured answer: it stated the permitted concentration range (per regulatory limits, no more than 25% calculated as dry aluminum substance for antiperspirants), cited the ingredient's current status in the database, and separately noted that the Alzheimer's-link hypothesis was disproven by subsequent cohort studies (per Rogers, 2016, large-scale reviews find no confirmed association). The answer included a reference to the specific database record with its last verification date.

Case 2: interpreting a percentage — niacinamide and its upper threshold

Query: "Can Niacinamide be used in a serum at a 12% concentration?"

ChatGPT answered affirmatively, citing "the popularity of high concentrations in K-beauty products," and didn't mention the risk of skin irritation or interaction with acids. The model effectively retold brand marketing copy, which dominates its training corpus, without distinguishing commercial content from clinical data.

The AI Chemist gave a quantitatively grounded answer: it stated that niacinamide's efficacy plateaus in the 4–5% range, and that concentrations above 10% are statistically linked to an increased incidence of erythema and stinging (per Bissett et al., 2004, and subsequent clinical observations). It additionally warned about the undesirable combination with Ascorbic Acid at a low formula pH — a detail that requires access to an ingredient-compatibility table, not just a general description of the substance.

Case 3: INCI-name synonyms — confusion between vitamin C forms

Query: "Are Sodium Ascorbyl Phosphate and Ascorbyl Palmitate the same thing?"

ChatGPT answered that "these are different forms of the same substance with the same effect on skin," effectively lumping together two chemically distinct ascorbic acid derivatives that differ in solubility, stability, and the release mechanism of the active vitamin C form. The error occurred because both terms frequently appear in the same context (antioxidant serums), and the model statistically linked them without any structural analysis of the molecule.

The AI Chemist, drawing on its retrieval module, pulled up a separate card for each INCI name: Sodium Ascorbyl Phosphate — a water-soluble salt, stable across a wide pH range; Ascorbyl Palmitate — a lipophilic derivative incorporated into an emulsion's oil phase. The system explicitly pointed out the difference in application and refused to lump them into one class without clarification.

The source of ChatGPT's error is the same in all three cases: the model generates plausible text based on statistical patterns in its training data instead of checking a fact against a structured record. This generation mechanism is examined in more detail in the section on retrieval-augmented generation architecture (see RAG architecture); what matters here is the practical takeaway: the divergence in answers is not accidental — it is systemic and repeats across different types of questions.

The chemistry of error: why a model without RAG confuses concentrations, synonyms, and ingredient functional classes

A language model's errors in cosmetic chemistry aren't random — they're systemic and grow directly out of how INCI nomenclature is built. The international naming system was built to standardize labels, not for unambiguous machine parsing: the same acid can appear under five different salt forms, and a single functional class can hide behind a dozen trade-name synonyms. An LLM without external context sees these names as statistically similar tokens, not as distinct molecules with different solubility, pH stability, and bioavailability.

The salt-form problem: one acid, different behaviors

A classic source of confusion is ascorbic acid derivatives. Ascorbic Acid, Sodium Ascorbyl Phosphate, Magnesium Ascorbyl Phosphate, and Ascorbyl Glucoside belong to the same chemical family but differ drastically in stability, optimal pH, and working concentration. A model trained on a general text corpus statistically associates all these names with "vitamin C" and readily carries the parameters of one form over to another — for example, recommending 15-20% for Sodium Ascorbyl Phosphate, even though that salt is already effective at 5-10% and dissolves poorly at higher concentrations.

The same story plays out with hyaluronic acid. Sodium Hyaluronate and Hyaluronic Acid are used interchangeably in mainstream texts, but in terms of molecular weight and depth of skin penetration they are a different story entirely. Without a retrieval layer pulling the exact record from a verified database, the model averages the context and produces an answer that's plausible but chemically imprecise.

Functional classes: when the model doesn't see the ingredient's role in the formula

The second category of errors is confusing functional classes. An emulsifier, a solubilizer, and a co-emulsifier can share a similar chemical nature (polysorbate esters, for example) but perform different jobs in the formula and require different proportions relative to the oil phase. A model without structured context often describes Polysorbate 20 as a direct equivalent of Polysorbate 80, ignoring the difference in HLB value (hydrophilic-lipophilic balance), which determines which phase — water or oil — a given emulsifier suits.

The same logic applies to preservatives. The list of synonym phrases around Phenoxyethanol in open sources is enormous, and without a verified link to a specific regulatory record, the model can confuse the permitted concentration range (usually up to 1% under EU regulations) with recommendations for combined preservative systems, where the actual working dose is noticeably lower — 0.4-0.7%.

Why a statistical language model doesn't distinguish dosage context

The root of the problem lies in how transformer architecture processes numerical data. Number tokenization breaks "0.5%" and "5%" into similar character sequences, and without an explicit anchor to a source, the model relies on the frequency of patterns in its training data. If the pairing "Retinol — 1%" appears more often online, the model will generate that figure even in cases involving gentle formulas for sensitive skin, where a safe starting point is 0.01-0.03%.

The Ji et al. (2023) study systematizing hallucinations in language models notes that this type of classification error is especially frequent where nomenclature is built on combinatorial suffixes and prefixes — that is, precisely in chemistry and pharmacology, where a difference of a single atom or a single salt changes the entire safety profile of a substance. Work by Ballentine and colleagues analyzing INCI nomenclature (also discussed in the article /blog/inci-nomenklatura-oshibki-klassifikacii) shows that the typical classification error occurs at the level of "functional analogy": the model groups ingredients by the semantic proximity of their names rather than by their real chemical function in a formula.

Synonymy as a trap in vector space

A separate layer of the problem is trade and colloquial names, which in the text corpus are mixed together with INCI nomenclature without explicit labeling. "Vitamin E" can refer to both Tocopherol and Tocopheryl Acetate — an esterified form with a different rate of hydrolysis in skin. For a human, that's a nuance; for a language model's vector representation, they're almost identical points in embedding space, because both terms statistically appear in the same antioxidant-protection contexts.

It's exactly this semantic "stickiness" of synonyms that explains why a retrieval layer — one that pulls the exact record from a structured database using a unique CAS-number identifier rather than simply "semantically similar" text — critically changes the quality of the answer: it breaks the dependence on statistical proximity and replaces it with an exact table match.

Limitations of the RAG approach: where even a verified database doesn't save you from errors

RAG architecture closes the main problem of language models — generating facts from "memory" without relying on a source. But retrieval-augmented generation doesn't turn the system into an oracle. It has its own set of weak points, and some of them are, by nature, not fixable simply by cleaning up the database. Let's break down where even a flawless knowledge source doesn't guarantee a correct answer.

Database staleness: INCI nomenclature and regulations have a life of their own

A verified database is a snapshot of the state of knowledge at the moment of indexing. INCI names are periodically revised by the Personal Care Products Council, ingredient statuses in CosIng are updated, and new concentration restrictions appear under EU Regulation 1223/2009. If the retrieval layer consults a database that isn't synchronized with the current registries, the system will produce an answer that is technically "source-confirmed" — but the source is out of date.

A practical example: concentration limits for preservatives are revised regularly (as happened with a number of isothiazolinones). A database updated six months ago may already contain an outdated threshold — and the RAG system will cite it with full confidence, because it formally "found confirmation in the document."

Re-ranking errors: relevance ≠ correctness

After the initial candidate search, the re-ranker sorts fragments by relevance to the query — but relevance and factual accuracy for a specific question are different metrics. A re-ranker trained on text embeddings can rank higher a document that's lexically similar to the query but describes an adjacent ingredient rather than the one being asked about.

A typical scenario: a query about Retinyl Palmitate, given weak embedding differentiation, can rank a chunk about Retinol higher — compounds that are chemically related but pharmacologically different in activity and tolerability. If the top-k is limited to three fragments and the document actually needed, about the retinol ester, lands in fourth position, the generative model simply won't see it and will compose an answer based on adjacent but imprecise context.

• Semantic proximity of synonyms — functional classes (emollients, emulsifiers) overlap in vector space, which confuses ranking on vague queries.
• Short chunks — if a document is split too finely, context is lost (for example, the dosage is stated in a neighboring paragraph that didn't make the top selection).
• Dominance of frequent terms — common ingredients (for example, Glycerin) more often land at the top of re-ranking simply because of the sheer volume of mentions in the database, pushing out rarer but more exact matches.

Incomplete coverage of rare and niche ingredients

Database verification typically focuses on widely used INCI components: preservatives, UV filters, common actives. Niche peptides, rare plant extracts, or highly specialized silicone derivatives are often represented by a minimal number of documents — sometimes a single source, often in English, with no independent cross-confirmation.

In such cases, the retrieval layer physically cannot provide the generative model with alternative phrasings to cross-check against. The system is forced to work with the single fragment found, and if it contains a typo in the concentration percentage or a mislabeled functional class, that error carries straight through into the answer without any signal of uncertainty.

Vague user queries: retrieval works with what it's given

A RAG system retrieves documents based on the query — and if the query is phrased imprecisely or uses a colloquial name instead of INCI, retrieval quality drops proportionally. A query like "that hydrating thing that's like hyaluronic acid but lighter" can lead to retrieving low-molecular-weight polysaccharides, when the user actually meant a specific Sodium Hyaluronate with a particular molecular weight.

According to research on the robustness of retrieval systems to variability in user phrasing (per Lewis et al., 2020; similar observations appear in work on domain-specific RAG systems), retrieval quality drops noticeably when phrasing deviates from the terminology used when the corpus was indexed. This isn't a database problem — it's a gap between the user's everyday language and the formal nomenclature of the sources.

The practical takeaway: a RAG approach built on a verified database is a substantial step forward compared to generating an answer "from memory," but it isn't absolute protection. Source staleness, re-ranking weaknesses, data scarcity for rare ingredients, and sensitivity to query phrasing — all of these factors require human oversight at the final stage, especially where the answer affects the safety of the formula.

Practical conclusions: how to choose an AI tool for analyzing cosmetic formulas

Breaking down the architecture, the hallucination mechanism, and the weak points of the RAG approach leads to the central question: how, in practice, do you tell a tool you can trust for analyzing an INCI list apart from a generator of convincing-sounding text. The difference doesn't come down to brand or marketing promises — it's checked against specific technical criteria.

Five criteria for vetting an AI tool before putting it to work

Before entrusting a neural network with formula analysis, a cosmetics developer should ask the tool (or its creators) five questions. The answers reveal whether the system operates on the retrieval-augmented generation principle or is a pure generator without verification.

If a tool can't give a clear answer on at least two of the five points, that's a signal to treat its output only as a rough hypothesis requiring manual verification against primary sources.

When ChatGPT without RAG is still acceptable

Generative models without a retrieval layer aren't useless — they're good for tasks where numerical precision isn't critical: generating ideas for marketing copy, a rough article structure, brainstorming product names. The problem starts where the model's output feeds a decision with consequences for the safety and stability of a formula — calculating an active ingredient's %, determining Retinol's compatibility with AHA acids, assessing an emulsion's pH-stability range.

Practical recommendation

For routine tasks — checking a preservative's concentration, looking up INCI synonyms, verifying ingredient functional classes — a RAG-based tool with a verified INCI database cuts the number of errors many times over compared to a generative model without a retrieval layer. That doesn't remove the need for critical reading of the answer: even with a RAG architecture, it's worth checking which source the system is citing, and treating with caution the situations described in the section on the approach's limitations — outdated records, conflicting sources, rare ingredients without sufficient database coverage.

The bottom-line criterion is simple: trust in an AI tool for analyzing cosmetic formulas should grow in proportion to the transparency of its sources, not the persuasiveness of its tone. A tool that honestly says "I'm not sure, there's no current data on this ingredient in the database" is more valuable than one that confidently names a concentration that doesn't exist. For developers who want to systematically understand formula chemistry while also learning to work with such tools, it's useful to start with foundational courses on INCI analysis and formulation — that's the knowledge base that lets you tell a correct AI answer from a hallucination, even without checking a primary source.

You can see this difference for yourself in the Walker Formulation Academy Club: the AI Chemist answers based on a verified INCI/CosIng database, not on a general-purpose model's "memory" — plus a live instructor and a review of your own formulas.