Retrieval-augmented generation, or RAG, means finding relevant source
information before asking a language model to write an answer. Instead
of relying on the model’s general knowledge, the assistant receives
evidence from your approved content.Start with one product family and the questions customers ask most
often. That will give you a manageable way to test whether the assistant
finds the right facts, explains them clearly, and sends visitors to
useful pages.
Drupal’s structured fields give the assistant facts it can retrieve
and compare. Turning those facts into dependable answers takes
additional work: retrieval rules, source checks, a website interface,
and tests that reflect real customer questions.
Enforce the visitor’s permissions during retrieval and before
delivering the response. Cache entries also need appropriate access
boundaries so that one visitor’s answer doesn’t expose restricted
information to another.
What
can customers ask a Drupal-powered product chatbot?
To understand what helps, compare retrieval configurations while
holding the model and test questions constant. Test body-text indexing
against indexing with structured metadata, then evaluate the effect of
source and answer checks. That will show whether gains come from the
content and retrieval design rather than a model change.
For example, “Show me stainless steel wall-mounted enclosures up to
600 mm wide” contains three constraints:
- “Which models are no wider than 600 mm?”
- “How do these two models differ?”
- “Does this enclosure come in stainless steel?”
- “Where can I find the installation instructions?”
Droptica’s AI
Document Chatbot for ProjektMagazin.de illustrates the broader
pattern of a Drupal-fed assistant with contextual sources and a website
interface. The case study describes a project-management knowledge
platform using JSON APIs for indexing, metadata such as taxonomy and
author information, relevance grading, content synchronization, and a
custom chat interface integrated with Drupal. The manufacturer’s catalog
assistant described here is a proposed application of that pattern; the
case study concerns a different content use case.
In this article:
The following example uses fictional product labels and
specifications:
Which Drupal data
should the assistant use?
Start with the questions customers already bring to your sales and
support teams. They usually want to find something, confirm a detail, or
understand a difference.
The retrieval service would apply those conditions to normalized
fields. The assistant could then summarize the matching products and ask
about any remaining selection criteria.
| Data | How the assistant would use it |
|---|---|
| Stable product identifiers and names | Identify the correct product across pages, documents, and follow-up questions |
| Descriptions and product-family taxonomy | Find relevant categories and explain intended uses |
| Typed specifications, including units | Apply numeric limits and compare attributes |
| Variant relationships | Keep each variant’s dimensions, materials, and ratings together |
| Related documents | Locate the manual or specification sheet for the selected product |
| Canonical page URLs | Send visitors to the corresponding website pages |
A helpful response will give a direct answer, identify the relevant
products and specifications, and link to the source pages. Customers can
then check the details themselves or share a product page with a
colleague.
Accessibility belongs in the initial scope. Plan for keyboard
navigation, clear focus behavior, labeled controls, and screen-reader
access to new responses. On mobile, check that the widget doesn’t cover
specifications or make product links difficult to tap.
These checks need their own tests. A grading model can make mistakes,
so use deterministic validation where possible, especially for
identifiers, numeric constraints, and URLs.
For our hypothetical manufacturer, useful questions include:
How does a
question become a grounded answer?
An installation warning may need stricter handling than a rewritten
product introduction. Where delayed information would be unacceptable,
use an authoritative lookup or temporarily withhold the affected
answer.
Two checks can catch different problems.
- Interpret the question. Identify the product
family, requested attributes, numeric limits, and any ambiguity. - Retrieve authorized data. Search explanatory
content and query structured product attributes. - Check the sources. Confirm that the evidence
belongs to the correct products, variants, and language. - Compose the answer. Explain the matches using the
retrieved facts. - Check the response. Verify that its claims and
links follow from those facts.
This approach separates two jobs: retrieval establishes the facts;
the model explains them.
“Unknown” is useful information. It tells the customer where the
comparison stops. The assistant can offer the documentation or suggest
asking sales to confirm the missing dimension.
Track factual correctness, constraint matching, source-link accuracy,
response time, and whether the assistant acknowledges insufficient
evidence.
An illustrative exchange
Editors need visibility too. A failed sync shouldn’t remain hidden
until a customer reports an old specification.
Trust depends on what happens after launch. Editors will correct
specifications, products will change, and documents will disappear. The
assistant needs to follow those changes without making visitors guess
which version they’re reading.
Ranking also needs a clear basis. If results appear from narrowest to
widest, say so. If a required specification is missing, don’t silently
treat that product as a confirmed match. Calling something the “best”
choice needs customer criteria and evidence that support that
judgment.
For an example of source grading in practice, read How
we improved RAG chatbot accuracy by 40% with document grading.
For this proposed catalog assistant, the source data would
include:
How
can the chatbot create product lists and comparisons?
A width buried in a PDF is harder to use reliably than an explicit
numeric width field with a known unit. The PDF may still provide useful
explanations, while the field supports an exact filter.
Customer: Which stainless steel enclosures are no
wider than 600 mm?
- Product family: wall-mounted enclosures.
- Material: stainless steel.
- Width: less than or equal to 600 mm.
Build a test set before rollout. Include ordinary requests alongside
difficult cases:
For a deeper look at modeling product records this way, see A
Drupal product catalog without Commerce: data first and Drupal
content modeling for answer coverage: fields, not prose.
| Product | Material | Width | Depth | Source link in the interface |
|---|---|---|---|---|
| Model A | Stainless steel | 550 mm | 250 mm | Model A product page |
| Model B | Stainless steel | 600 mm | Unknown | Model B product page |
Keep the model disciplined. Normalize units, use controlled terms for
materials and families, and distinguish missing specifications from
confirmed values. Structured fields make facts available; they
don’t automatically make an answer correct.
For the hypothetical manufacturer, a proposed flow would look like
this:
A comparison view makes the evidence easier to scan. Using fictional
data, it might look like this:
How does the
chat interface connect to the website?
Treat retrieved text as evidence, not instructions. A sentence inside
an indexed document must not authorize a tool call or change the
assistant’s access rules.
Assistant: Two options in this shortlist match those
criteria: Model A is 550 mm wide, and Model B is 600 mm wide. Both list
stainless steel as their material. Do you have a maximum depth or a
required protection rating?
First, a source-relevance check can reject retrieved passages that
concern the wrong product, variant, language, or subject. Second, an
answer-support check can flag claims that the retained sources don’t
establish, including incorrect numbers and mismatched links.
That’s the goal: use your existing content to answer practical
questions and guide visitors toward a useful next step. A shopping cart
isn’t necessary. For a manufacturer, the destination might be a product
page, a distributor directory, or a conversation with sales.
The browser would send questions to a backend service. That service
would handle retrieval, model requests, permission checks, and response
preparation. API credentials and privileged source access would stay on
the backend.
How do you keep
answers current and trustworthy?
For this catalog use case, keep the assistant read-only. Any future
actions, such as submitting an inquiry, would need separately designed
permissions, validation, and user confirmation.
Define freshness around
editorial work
A useful shortlist saves customers from repeatedly applying filters
and opening pages. To produce one, the assistant needs to translate the
request into explicit conditions.
The interface would attach the corresponding product-page links to
each model. It would describe these as a shortlist unless a complete
filtered query established that they were every matching product.
The frontend would do more than display paragraphs. Useful elements
include clickable product cards, source links, suggested follow-up
questions, and a clear route to human support. Loading and error states
also matter: a visitor needs to know whether the assistant is still
searching or couldn’t complete the request.
- Publishing and updating content.
- Unpublishing and deleting content.
- Retrying failed indexing jobs and alerting the team.
- Invalidating affected retrieval and answer caches.
- Detecting stale records and reconciling the index with Drupal.
The assistant’s job is to make documented information easier
to use. When the available facts don’t support a
recommendation, a clarifying question or a route to technical sales will
serve the customer better than a confident guess.
Keep familiar navigation available. The assistant can supplement
catalog listings, filters, and site search, letting customers choose the
route that works for them. A commerce stack isn’t a prerequisite.
Check evidence
before and after generation
We describe one way to handle this in Real-time
data synchronization for RAG: how to keep your AI chatbot’s knowledge
fresh. If you cache answers, How
to speed up AI chatbot responses with intelligent caching covers the
invalidation side.
Some questions need clarification. If someone asks for an enclosure
“suitable for outdoor use,” the assistant may need to ask about the
environment or required protection rating. It can report a documented
rating; suitability beyond that evidence needs a separate
assessment.
Clear product data reduces ambiguity before the language model starts
composing an answer.
Relationships matter just as much. If one variant is stainless steel
and another is 580 mm wide, the assistant cannot combine those facts
into a product that doesn’t exist.
Chunk sizing deserves attention here. A very small text chunk may
separate a specification from its variant name. A large chunk may mix
several products and introduce irrelevant facts. Test chunks that keep
meaningful sections together, attach product metadata, and preserve
relationships rather than choosing a size by habit.
Protect access and keep
actions bounded
One implementation option would use Drupal APIs, a backend retrieval
service, and an index that stores text alongside structured metadata.
Drupal’s JSON:API
documentation describes its entity-oriented API foundation. The
project would still need to configure access, select fields and
relationships, and build the indexing and retrieval behavior.
A shortlist and a complete result list are different
promises. Semantic retrieval often returns a limited set of
relevant matches. To claim “all matching products,” the system needs a
complete structured query, including pagination and consistent handling
of missing values.
Suppose a customer visits a manufacturer’s website looking for a
stainless steel enclosure no wider than 600 mm. The information exists,
but it’s scattered across product pages, specification tables, and
installation manuals. A Drupal chatbot built on your
existing content can help that customer find relevant models and
understand the differences without opening every page.
Measure the
questions customers actually ask
Bring your Drupal product model and a sample of those questions to a
conversation with Droptica. Together, we’ll
scope a pilot covering retrieval, trustworthy source links, frontend
interaction, and measured answer accuracy. You’ll have evidence to guide
the next step before expanding across the catalog. Learn more about our
Drupal AI
chatbot service.
- Similar product names and closely related variants.
- Numeric limits and unit conversions.
- Missing or contradictory specifications.
- Requests for every matching product.
- Questions the sources cannot answer.
- Withdrawn documents and broken links.
- Attempts to retrieve restricted content.
The implementation plan needs to cover the full content
lifecycle:
Different questions need different retrieval methods. Semantic search
can help find a passage about installation clearance. A maximum width of
600 mm belongs in a numeric filter. An exact product identifier needs an
exact lookup.
What
does the ProjektMagazin implementation illustrate?
Set a measurable target for how quickly published changes will become
available to the assistant, then monitor it. The appropriate interval
depends on the content and the risk of giving an outdated answer.
Ready to start?
Customers need a convenient place to ask their question. For this
proposed implementation, that could be a chat widget on catalog pages or
a dedicated assistant page within the Drupal frontend.
For information that changes faster than an index can reliably
refresh, the backend would query the authoritative source before
answering.
