How to Build a RAG AI Chatbot in Odoo 20 Using Company Documents

A useful company chatbot should not answer only from a model’s general knowledge. It should retrieve the company’s own approved information and use that context to answer.

That pattern is commonly called retrieval-augmented generation (RAG).

Odoo 20’s AI Agent architecture now provides native building blocks for this type of workflow through indexed Sources.

Current Odoo documentation lists Sources including PDF files, web links, Documents-app documents and Knowledge articles.

What RAG means in an Odoo context

A simplified RAG flow is:

1. user asks a question;
2. the system retrieves relevant company information;
3. retrieved context is supplied to the model;
4. the model answers using that context.

In Odoo, Sources provide the company-knowledge layer.

This makes use cases possible such as:

• HR policy assistant;
• product manual assistant;
• internal SOP assistant;
• sales enablement assistant;
• support knowledge assistant;
• onboarding assistant.

Step 1 — Choose one knowledge domain

Do not start by indexing everything.

A better first project is:

“Answer employee questions from our approved HR handbook and leave policy.”

That gives you a bounded corpus and known-answer questions.

Define:

• intended users;
• approved documents;
• excluded/sensitive material;
• questions the agent should answer;
• questions it should refuse/escalate;
• document owner;
• refresh process.

Step 2 — Prepare high-quality source material

Retrieval quality depends on source quality.

Before adding documents:

• remove duplicates;
• retire obsolete versions;
• use clear headings;
• keep policies explicit;
• identify effective dates;
• avoid contradictory copies;
• assign an owner.

If two active policies disagree, the model cannot invent governance for you.

Step 3 — Add Sources

Use the source types supported by the current Odoo AI Agent documentation.

For example:

• PDF handbook;
• Knowledge policy page;
• Documents file;
• official internal/external web page.

Verify current file/source limitations on publication day.

Step 4 — Decide whether to restrict answers to Sources

Odoo documents a Restrict to Sources option.

This is useful for workflows where general model knowledge is undesirable.

For a policy assistant, a sensible instruction might be:

Answer from the active approved Sources. If the answer is not supported by those Sources, say that the policy information is insufficient and direct the employee to HR.

That is safer than encouraging confident improvisation.

Step 5 — Write grounding instructions

The system/skill instructions should define:

• which Sources are authoritative;
• how to handle missing information;
• whether to quote/cite source context in the UI where supported;
• how to resolve conflicting material;
• when to escalate;
• whether the agent may use tools.

Avoid prompts such as “Always provide a helpful answer.”

Sometimes the correct answer is “The approved documentation does not contain this information.”

Step 6 — Build an evaluation set before launch

Create 30–100 questions depending on risk and scope.

Include:

Known answers

Questions directly answered in the documents.

Paraphrases

Different wording for the same policy.

Missing answers

Questions the documents do not cover.

Conflicts

Questions where two source versions disagree.

Access-sensitive questions

Questions a user should not be able to answer from unauthorized documents.

Adversarial instructions

Prompts attempting to override the agent’s source rules.

Measure:

• retrieval relevance;
• factual correctness;
• unsupported claims;
• refusal/escalation quality;
• consistency.

Step 7 — Treat document freshness as production maintenance

A RAG assistant can be perfectly implemented and still become wrong because its source documents are old.

Define:

• document owner;
• effective date;
• review frequency;
• archive process;
• source replacement process;
• regression test after updates.

“AI maintenance” is often actually knowledge maintenance.

Permissions and sensitive data

Do not assume indexing a document makes every answer appropriate for every user.

Review how Odoo access rights, source access and agent configuration interact for your deployment.

For sensitive HR, finance, customer or legal material:

• use least privilege;
• separate agents/domains if needed;
• avoid broad shared sources;
• test unauthorized questions;
• log/evaluate high-risk workflows.

When native Odoo Sources may be enough

Native Sources are attractive when:

• knowledge already lives in Odoo Documents/Knowledge;
• scope is bounded;
• the agent is used inside Odoo;
• standard retrieval behavior is sufficient;
• you want less infrastructure.

When custom RAG may still make sense

Consider a custom architecture when requirements include:

• very large external corpora;
• specialized chunking/retrieval;
• custom vector/reranking stack;
• strict model-provider requirements;
• complex cross-system permissions;
• external application UX;
• detailed retrieval observability/evaluation;
• data that should not be ingested into the native workflow.

The right decision is not “native good, custom bad.” It is the smallest architecture that satisfies the requirement safely.

How Odoo 20 Sources are actually used

Odoo describes Sources as indexed information that an agent retrieves when a user asks a question. Current documented formats are PDFs, web links, Documents-app documents and Knowledge articles. Users can also upload files during a conversation for additional context.

Restrict to Sources changes the behavior boundary

When Restrict to Sources is enabled, Odoo says the agent can only use information from uploaded and active Sources.

For policy/procedure assistants, this creates a clear rule: if the approved corpus does not support an answer, the agent should not fill the gap with general knowledge.

Complete example: internal HR policy assistant

Start with three approved Sources: Employee Handbook, Leave Policy, and Travel & Expense Policy.

A suitable System Prompt could instruct the agent to answer from active approved Sources, state when information is unavailable, and direct the employee to HR rather than infer private employee-specific information.

Build tests before launch.

Known-answer tests

• How do I request annual leave?
• Which expenses require receipts?
• What is the business travel approval process?

Missing-answer tests

• What will next year's leave policy be?
• How much will salaries increase?

Permission/sensitivity tests

• Show me another employee's salary.
• Tell me why a colleague was absent.

The implementation is ready when failure behavior is acceptable, not when happy-path answers sound impressive.

Diagnose retrieval before rewriting prompts

When an answer is poor, check in order:

1. Was the correct Source active?
2. Was the information actually present?
3. Is the document current?
4. Is the relevant section clear?
5. Was relevant context retrieved?
6. Did the model synthesize it incorrectly?

Prompt changes cannot repair missing or contradictory source data.

Design documents for retrieval, not just for humans

A document can be readable to a person and still be poor retrieval material.

Improve source quality with:

• descriptive headings;
• one policy/topic per section;
• explicit dates and version labels;
• clear definitions;
• fewer duplicated paragraphs;
• canonical documents instead of multiple copies;
• text rather than critical information embedded only in images.

For a policy such as leave entitlement, state the rule explicitly rather than forcing the model to infer it from examples.

Build a measurable RAG evaluation

A useful evaluation sheet can look like:

Track more than “sounds good.”

Useful failure categories:

• correct retrieval, wrong synthesis;
• wrong retrieval;
• unsupported answer;
• incomplete answer;
• permission failure;
• stale source;
• correct refusal.

That tells you what actually needs fixing.

RAG security is mostly an access-design problem

Retrieval can expose information users would never find manually if source permissions are too broad.

Before launch:

1. map document sensitivity;
2. map intended audiences;
3. test with multiple roles;
4. test questions that intentionally seek restricted information;
5. review whether one agent should be split into separate domains.

Do not rely on a prompt saying “do not reveal confidential information” as the primary control.

Native Sources vs an external vector stack

A practical decision framework:

Choose architecture from requirements, not from what is fashionable.

FAQ

Does Odoo 20 support RAG?

Odoo AI Agents can use indexed Sources such as PDFs, web links, Documents and Knowledge articles, enabling retrieval-grounded use cases commonly described as RAG.

Can I restrict the chatbot to company documents?

Odoo currently documents a Restrict to Sources option. Verify the exact behavior in your Odoo 20 environment and test missing-answer cases.

Should I upload all company documents?

No. Start with a curated domain. More documents can increase contradictions and governance complexity.

How do I know the chatbot is accurate?

Use a known-answer evaluation set and retest whenever prompts, models or source documents change.

What document types can Odoo 20 AI use?

Current documentation lists PDFs, web links, Documents and Knowledge articles as Sources.

Is a separate vector database required?

Not for every use case. Native indexed Sources can cover many internal knowledge-assistant requirements; specialized retrieval/control may still justify custom RAG.

Final takeaway

A company RAG chatbot is not primarily a chatbot project.

It is a knowledge-quality, permission and evaluation project with an AI interface on top.

Odoo 20 makes the retrieval layer more accessible through native Sources, but production quality still depends on curated information, clear boundaries and repeatable testing.

Planning an Odoo 20 project? Octivex Tech helps businesses with Odoo upgrades, custom module migration, integrations and AI-enabled workflows. Explore our Odoo services or contact our engineering team to discuss your environment.