Product Knowledge in the Quotation Process: When RAG Helps – and When Search Is Enough

In technical sales, teams quickly ask whether product knowledge already requires a RAG system. That question is often premature. First clarify the task: retrieving an exact value from an authoritative system, finding an existing document or drafting an answer from several sources.

This article uses a Trixner Decision Framework. It is an editorial working model, not a universal standard. It classifies three technical approaches according to the required output: structured product data, conventional search and retrieval-augmented generation.

Structured Product Data is stored in defined fields and records, such as item number, variant, dimensions or internal status. When an authoritative value is required, first identify which system is responsible for that value.

Full-Text Search searches indexed text fields and ranks results by relevance. Elastic’s current documentation describes it as lexical search in which documents and queries are analysed for retrieval. The result remains a list of matches linked to the original sources.

Retrieval-Augmented Generation (RAG) combines retrieval with text generation. The original RAG paper describes a retriever that selects text passages and a generator that uses those passages to produce an answer. The result is a drafted response, not the original source itself.

The table does not select a system automatically. It first separates the expectations. Only then can you decide which search or generation component should be evaluated.

For precisely defined values, a generated answer is usually not the first option to assess. What matters is where items, variants and valid statuses are managed. A language model may later help explain or formulate the result, but the origin of the specific value should remain separate.

• Can the enquiry be identified by item number, variant or another unique attribute?
• Is the required value already available in a structured field?
• Which system is considered the authoritative source internally?
• Which values may be used only after technical or commercial review?

If these questions can be answered clearly, first assess reliable access to the underlying data. RAG does not replace the need to define which product record is authoritative.

Search is a good starting point when employees mainly need to find the right original source. This is particularly true when product names, item numbers, standard terms or document titles are known and the retrieved passage will then be read in context.

• Is a list of relevant documents or passages sufficient?
• Are similar terms used in the enquiry and the source?
• Can the question be answered mainly from a single source?
• Should the user continue working in the original document?

Practical Tip: Take a small selection of real search queries from sales and engineering. For each query, note whether a suitable original document was found and whether that document alone is sufficient for the next step. This selection is a working sample, not a universal minimum.

RAG can be considered as an additional layer when the required output goes beyond a result list. The user asks a question in natural language, relevant passages are retrieved and a model drafts a response from them. The sources should remain visible for review.

A focused pilot can examine situations such as the following:

• The answer needs to combine information from several approved documents.
• The enquiry and the source use different terms for the same subject.
• Sales needs a concise working draft rather than only a list of results.
• The answer should refer back to the passages or documents used.
• When the evidence is insufficient, the system should reveal the gap instead of drafting a definitive statement.

These points describe reasons to evaluate RAG, not guaranteed outcomes. Only a test using approved sources, real questions and predefined assessment criteria can show whether RAG is suitable for the company’s content.

RAG itself includes a search step. The main difference is what happens after retrieval: conventional search displays results, while a RAG workflow also passes selected passages to a language model. Retrieval methods can also be combined. Microsoft and Elastic, for example, document technical approaches that use lexical and semantic search together.

A layered architecture can therefore be useful for product knowledge:

1. Structured filters narrow down the product group, variant or validity range.
2. A search component retrieves relevant documents or passages.
3. Only when a drafted response is required does a language model receive the selected context.
4. A person reviews the sources, values and intended use.

This sequence is one design option. It is intended to prevent a generative model from taking on tasks for which a clear record or result list would already be the more appropriate output.

Before selecting a tool or platform, management, sales leadership and engineering can narrow down the use case using these six questions:

1. Output: Is an exact value, an original source or a drafted response required?
2. Data Format: Is the information structured or available only in documents and free text?
3. Source Scope: Is one source sufficient, or must several passages be combined?
4. Currency: How is the approved version identified?
5. Access: Which roles may view the content used?
6. Approval: Who reviews the output before it enters a quotation process?

Practical Tip: Create three columns headed “Value”, “Source” and “Draft”. Initially assign real product questions only according to their expected output. Discuss a technical approach for each group only in the second step.

If RAG remains a candidate after this assessment, define the first test scope narrowly. Specify a product group, a defined set of documents and a responsible user group.

The test plan should include both answerable and deliberately unanswerable questions. Do not assess only the writing style. The sources used, the correct product and variant context, visible uncertainty and the amount of correction required are more important.

The article How to Plan a RAG Pilot.

For exact product values, the first route leads to structured data and clear responsibilities. A well-configured search may be sufficient for finding known sources. RAG becomes relevant when several suitable passages need to be combined into a reviewable working draft.

The three approaches are not mutually exclusive. A robust pilot nevertheless separates them clearly by task, source and approval. To assess this decision using your own product knowledge, see RAG Pilot for the appropriate next step.

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Full-text search
• Retrieval-augmented generation (RAG) in Azure AI Search