A retrieval system can make product answers easier to trace. It cannot make a language model incapable of being wrong. The difference matters when an affiliate page discusses supplements, where a fluent answer can imply a health benefit, dosage, or safety assurance that the advertiser never approved.
Picture a visitor asking a product chatbot, “Will this help me sleep?” A model could produce a confident answer by blending a label, a marketing page, and patterns learned elsewhere. A knowledge base may reduce that risk by making approved material available at answer time, but retrieval is not a safety guarantee. A system can retrieve the wrong passage, miss a useful one, or generate a conclusion that the passage does not support.
The practical goal, then, is not to promise a chatbot that “cannot hallucinate.” It is to build a product-information assistant whose evidence, limits, fallback, and human review are explicit—and to decline deployment when those controls cannot be maintained.
Build a claim ledger from product evidence
In Dify, a knowledge base can supply context to an application or workflow. The platform’s documentation describes application orchestration and knowledge retrieval, but exact configuration, retrieval behavior, and available controls can change by version and deployment. Check the current Dify documentation and the settings in your own workspace before relying on a particular feature. (Dify application guide; Dify knowledge retrieval overview)
Before uploading anything, make a claim ledger. For every statement the assistant may make, record:
- the exact approved wording;
- what the wording means in context, including likely implied messages;
- the evidence or approved source that supports it;
- who approved it and for which product, market, and channel;
- a review date and the event that requires an update;
- phrases the assistant must not turn it into.
This distinction is central for supplements. The current package label is a strong source for what the package says, such as serving directions and listed ingredients. It does not, by itself, substantiate every benefit an affiliate might want to claim. Advertising claims—including implied claims created by a chatbot’s answer, the surrounding page, and the call to action—need support relevant to the specific product and presentation. The FTC’s health-products guidance stresses that advertisers should evaluate the messages consumers are likely to take from an ad and the evidence supporting those claims. FDA rules address specific categories of claims on dietary-supplement labeling; those rules do not turn a label into general proof of efficacy. (FTC Health Products Compliance Guidance; FDA structure/function claims)
A useful source inventory separates at least four classes:
| Information | Preferred record | What it can support | Review trigger |
|---|---|---|---|
| Label facts | Current product label and Supplement Facts panel | What the package lists and says | New formulation, packaging, or market |
| Offer and fulfillment | Current advertiser or network terms | Price, shipping, returns, availability | Offer revision, expiration, or fulfillment change |
| Approved marketing claims | Claim ledger plus substantiation and approval record | The exact claims cleared for this placement | New evidence, wording, product, or channel |
| Help and escalation | Brand support contact and approved FAQ | Where a visitor can verify unanswered product questions | Contact, FAQ, or support-process change |
Do not treat an old landing page, a retailer listing, an ingredient supplier’s blog, or a model’s general knowledge as interchangeable with these records. Keep provenance with the document: product identifier, jurisdiction, source owner, effective date, version, and approval status. If a record has no owner or expiry trigger, the team cannot tell when it has gone stale.
Make the answer traceable, then test what retrieval misses
Retrieval-augmented generation (RAG) retrieves passages from a knowledge collection and supplies them as context to a model. That can make answers easier to ground and audit. It does not prove that a passage is current, relevant, complete, or sufficient for the answer the model produces. The system can still select a poor match, combine statements, omit a qualification, or answer from learned patterns.
For that reason, design a response contract before tuning prompts. A standard product-information answer should:
- stay within the approved wording and the question asked;
- identify the source or provide a direct route to it when practical;
- keep material qualifications close to the statement they qualify;
- say when it cannot find a reliable answer;
- avoid converting a general product statement into a disease, efficacy, dosage, or safety promise.
Then test retrieval separately from generation. Create a small, versioned test set with questions the page should answer, near-matches it should not answer, and questions that require a handoff. For each test, save the expected source, relevant passage, acceptable response boundaries, and outcome. Include variations in everyday language, spelling, and phrasing. A correct response to one exact wording is not evidence that paraphrases will work.
Inspect the retrieved material, not just the final answer. Ask: Did the system return the right version? Did it include enough context to preserve a qualifier? Did it surface two conflicting versions? Could a broad chunk retrieve a dosage or claim beside unrelated content? Are citations tied to the actual passages used? If your Dify configuration does not expose a control or trace you need, document that limitation and add a human review step or choose a simpler static page.
Write boundaries for predictable failure cases
A system instruction such as “answer only from the context” is useful, but it is not an enforcement mechanism. Prompts can be misunderstood or overridden; an empty retrieval result can still be followed by a plausible completion. Treat instructions as one layer of risk reduction.
A safer flow has explicit branches:
- Clear product fact in a current approved source: answer narrowly, preserve its qualifier, and link or name the source.
- No relevant source, stale source, or conflicting versions: say that the page cannot verify the detail and point to the current advertiser support route.
- Question about a condition, symptom, diagnosis, treatment, medication interaction, personal suitability, or an amount beyond label directions: do not infer an answer from marketing material. Direct the visitor to an appropriate healthcare professional or the product’s official support channel, without suggesting that the supplement is safe or effective for that person.
- Complaint, adverse event, or urgent concern: show the advertiser’s established reporting or support route. Do not leave the chatbot as the only contact path.
These are product and operations boundaries, not individualized medical advice. The precise obligations depend on the product, claim, channel, and jurisdiction. The cited FTC and FDA materials describe U.S. contexts; they are not a substitute for review of applicable rules elsewhere. This guide is operational education, not legal, regulatory, or medical advice.
The questions in the test set should reflect those branches. For example, test “What ingredients are listed?” against the current label; test “Will it treat my joint pain?” against the no-medical-claim route; test “Can I take this with my prescription?” against a professional handoff; and test “What does shipping cost?” against the current offer terms. Those are test cases, not claims about how any real product performs.
Assign who checks and approves changes to the source material
A corpus is a maintained operating asset. Assign a named role—not just “the team”—to each source class. Record who can approve new claims, who can publish a new version, and who can disable the assistant if a source is withdrawn or a material defect appears. Keep a change log that connects a document version to the application version and the date it became active.
Before each release, check that:
- every indexed file has an owner, product and market scope, approval state, and review trigger;
- expired, superseded, duplicate, and contradictory documents are removed or clearly excluded;
- the expected source is retrieved for representative questions;
- the refusal and handoff routes work on mobile and remain visible without a successful chat response;
- logs and test records do not retain more personal information than the team needs;
- someone is assigned to review failures and update the test set after a change.
After release, monitor categories rather than celebrating a single aggregate score: unanswered questions, unsupported or overbroad answers found in review, stale-source incidents, failed handoffs, and recurring requests for information absent from the approved corpus. A spike can indicate a content gap, a retrieval change, an offer change, or a new visitor need. It does not automatically establish that the model is the cause.
Decide in advance what happens when a check fails. Depending on severity, that may mean removing one source, disabling a response category, reverting an application version, or switching to a static page until review is complete. Keep a direct contact path available. A chatbot that cannot reliably answer a particular question is allowed to say so; an affiliate page does not need a conversational interface to be useful.
When a static pre-lander is the better choice
A conversational pre-lander earns its place when visitors have recurring, answerable product or offer questions and the operator can keep sources current, review failures, and maintain a visible escalation route. It is a poor fit when claims are unsettled, product data changes faster than it can be maintained, or the operator cannot inspect what the assistant retrieves and returns.
That decision is about operating capacity as much as software. Dify can provide building blocks for applications and retrieval, but the responsibility for approved claims, safe user journeys, and ongoing review remains with the marketer and the businesses whose offers they promote. Retrieval may make the evidence path clearer. It cannot transfer that responsibility or guarantee a compliant answer.
For a supplement pre-lander, the strongest operating rule is therefore modest: make each answer traceable, make uncertainty visible, route high-risk questions away from improvisation, and be ready to take the assistant offline. When those conditions are not met, a well-written static page is the more honest experience.
