The Problem Our enterprise clients were running Odoo ERP with 15+ modules — Sales, Inventory, MRP, Accounting, CRM, HR, Payroll, POS, E-commerce, Helpdesk, and more. The data was all there, but:

Sales reps had to navigate 4-5 screens just to check a customer's credit status Warehouse managers needed to run reports to see stock availability Executives wanted quick KPIs without waiting for BI dashboards to load Field service agents needed hands-free access while on-site

The question was simple: Can users just ask the ERP what they need and get an answer?

The Architecture Here's the high-level architecture I designed: User Query (text/voice/image) │ ▼ ┌─────────────────────┐ │ Multimodal Input │ ← Speech-to-text, OCR, text input │ Processing Layer │ └────────┬────────────┘ │ ▼ ┌─────────────────────┐ │ Query Router │ ← Classifies intent and complexity └────────┬────────────┘ │ ┌────┴────┐ │ │ ▼ ▼ ┌────────┐ ┌──────────────┐ │ Direct │ │ RAG Pipeline │ │ ORM │ │ (LangChain + │ │ Query │ │ pgvector) │ └───┬────┘ └──────┬───────┘ │ │ ▼ ▼ ┌─────────────────────┐ │ Response Generator │ ← Fine-tuned LLM │ (QLoRA Model) │ └────────┬────────────┘ │ ▼ ┌─────────────────────┐ │ Odoo ERP Frontend │ ← OWL widget in Odoo UI └─────────────────────┘ The system has four main components:

1. Multimodal Input Processing Users can interact through text, voice, or image:

Text: Direct chat input in the Odoo interface Voice: Speech-to-text using Whisper, enabling hands-free operation for warehouse and field workers Image: OCR processing for documents — snap a photo of a purchase order and the system extracts data

pythonclass MultimodalProcessor: def init(self): self.whisper_model = whisper.load_model("base") self.ocr_engine = PaddleOCR(use_angle_cls=True, lang='en')

def process_input(self, input_data, input_type="text"):
    if input_type == "voice":
        result = self.whisper_model.transcribe(input_data)
        return result["text"]
    elif input_type == "image":
        result = self.ocr_engine.ocr(input_data, cls=True)
        extracted = " ".join([line[1][0] for line in result[0]])
        return extracted
    return input_data

1. RAG Pipeline with LangChain and pgvector This is the core of the system. Instead of feeding the entire database to the LLM (impossible and expensive), I built a Retrieval-Augmented Generation pipeline: Step 1: Document Indexing I created embeddings for Odoo's business data — product descriptions, customer notes, helpdesk tickets, sales policies, HR policies, and module documentation: pythonfrom langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import PGVector

Using a lightweight embedding model for speed

embeddings = HuggingFaceEmbeddings( model_name="sentence-transformers/all-MiniLM-L6-v2" )

Store embeddings in PostgreSQL using pgvector

vector_store = PGVector( connection_string=DATABASE_URL, embedding_function=embeddings, collection_name="odoo_knowledge_base" ) Why pgvector instead of ChromaDB or Pinecone? Since Odoo already runs on PostgreSQL, using pgvector meant:

No additional infrastructure to manage Embeddings live alongside the business data Transactions are ACID-compliant One backup strategy covers everything

Step 2: Smart Retrieval Not every query needs RAG. "What's the stock of Product X?" can be answered directly from the ORM. But "What's our return policy for international orders?" needs the RAG pipeline. I built a query router that classifies intent: pythonclass QueryRouter: """Routes queries to the appropriate handler."""

DIRECT_ORM_PATTERNS = [
    "stock", "quantity", "price", "total", 
    "count", "balance", "status"
]

def route(self, query: str) -> str:
    query_lower = query.lower()
    
    # Check if this can be answered via direct ORM query
    if any(pattern in query_lower for pattern in self.DIRECT_ORM_PATTERNS):
        return "orm_direct"
    
    # Check if this needs document retrieval
    return "rag_pipeline"

Step 3: Context-Aware Retrieval The retrieval step doesn't just do a simple similarity search. It considers the user's context — their role, department, and the Odoo module they're currently in: pythondef retrieve_context(self, query, user_context): """Retrieve relevant documents with user context awareness."""

# Build metadata filter based on user's access rights
metadata_filter = {
    "department": user_context.get("department"),
    "module": user_context.get("active_module"),
}

# Retrieve top-k relevant documents
docs = self.vector_store.similarity_search(
    query,
    k=5,
    filter=metadata_filter
)

# Also fetch live data from Odoo ORM if needed
orm_context = self._fetch_orm_data(query, user_context)

return docs, orm_context

1. Fine-Tuned LLM with QLoRA The base model didn't understand Odoo-specific terminology or our clients' business logic. So I fine-tuned it using QLoRA (Quantized Low-Rank Adaptation): Why QLoRA?

Full fine-tuning of a 7B parameter model needs 28+ GB VRAM QLoRA reduces this to under 8 GB by quantizing to 4-bit and training only low-rank adapters We could run this on a single GPU server

pythonfrom peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from transformers import AutoModelForCausalLM, BitsAndBytesConfig

4-bit quantization config

bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.float16, bnb_4bit_use_double_quant=True )

Load base model with quantization

model = AutoModelForCausalLM.from_pretrained( "mistralai/Mistral-7B-Instruct-v0.2", quantization_config=bnb_config, device_map="auto" )

LoRA configuration

lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" )

model = prepare_model_for_kbit_training(model) model = get_peft_model(model, lora_config) Training Data I curated a dataset of 5,000+ examples from:

Real Odoo support tickets and their resolutions ERP operation workflows (how to create a PO, how to check stock, etc.) Business-specific Q&A pairs from our clients Odoo documentation rewritten as conversational Q&A

1. Integration with Odoo The assistant lives inside Odoo as an OWL (Odoo Web Library) component — a chat widget accessible from any screen: javascript/** @odoo-module */ import { Component, useState } from "@odoo/owl";

export class ERPAssistant extends Component { static template = "erp_assistant.ChatWidget";

setup() {
    this.state = useState({
        messages: [],
        isListening: false,
        isProcessing: false,
    });
}

async sendMessage(query) {
    this.state.isProcessing = true;
    
    const response = await this.env.services.rpc("/api/assistant/query", {
        query: query,
        context: {
            active_model: this.env.config.activeModel,
            active_id: this.env.config.activeId,
            user_id: this.env.services.user.userId,
        }
    });
    
    this.state.messages.push({
        role: "assistant",
        content: response.answer,
        sources: response.sources,
    });
    
    this.state.isProcessing = false;
}

}

Challenges and Lessons Learned

1. Keeping embeddings in sync with live data Odoo data changes constantly — new products, updated prices, modified policies. I built a scheduled action that re-indexes changed records every hour: pythonclass EmbeddingSync(models.Model): _name = 'ai.embedding.sync'

   @api.model def _cron_sync_embeddings(self): """Sync modified records to vector store.""" last_sync = self._get_last_sync_time()

    # Find all records modified since last sync
    modified_records = self.env['ir.model'].search([
        ('write_date', '>', last_sync)
    ])
    
    for record in modified_records:
        self._update_embedding(record)
   

2. Hallucination control The LLM sometimes generated plausible-sounding but incorrect numbers. My solution:

Always verify numerical answers against the ORM before returning them Include source citations in every response so users can verify Add a confidence score — if the model isn't confident, it says "I'm not sure, let me show you the relevant screen instead" and navigates the user to the right Odoo view

1. Response latency Enterprise users expect instant answers. My optimizations:

Cached embeddings for frequently accessed data (top products, common policies) Streaming responses so users see the answer forming in real-time Query classification to route simple queries directly to the ORM (under 200ms) instead of the full RAG pipeline (2-3 seconds)

Results After deploying across multiple enterprise clients:

Data processing time significantly reduced — users get answers in seconds instead of navigating multiple screens Voice command adoption grew rapidly — warehouse workers loved the hands-free operation Strong user adoption within weeks of launch — users preferred chatting over navigating menus Helpdesk ticket volume dropped — employees could self-serve common questions

Tech Stack Summary ComponentTechnologyLLMMistral 7B + QLoRA fine-tuningRAG FrameworkLangChainVector Storepgvector (PostgreSQL)Embeddingssentence-transformers/all-MiniLM-L6-v2Speech-to-TextWhisperOCRPaddleOCRERPOdoo (v17)BackendPython, FastAPIFrontendOWL (Odoo Web Library)InfrastructureGPU server, Docker, Nginx

What I Would Do Differently

Start with a smaller model — I initially tried a 13B model but 7B with good fine-tuning performed just as well for this domain-specific use case, at half the inference cost. Invest more in evaluation — I should have built an automated eval pipeline earlier. Manual testing doesn't scale when you have thousands of possible queries. Hybrid search from day one — Combining vector similarity search with traditional keyword search (BM25) would have improved retrieval accuracy for queries containing specific product codes or order numbers.

Wrapping Up Building an AI assistant for an ERP system is fundamentally different from building a general-purpose chatbot. The data is structured, the answers need to be precise, and users have zero tolerance for wrong numbers. The combination of RAG (for knowledge retrieval), QLoRA fine-tuning (for domain understanding), and deep Odoo integration (for real-time data access) made this possible without requiring massive infrastructure. If you're building something similar or have questions about any part of this architecture, feel free to reach out — I'd love to chat about it.

I'm Harideevagan M, a Full-Stack Developer and AI Engineer at Futurenet Technologies in Chennai, India. I specialize in LLM engineering, Odoo ERP, and enterprise automation. Check out my portfolio at harideevagan.netlify.app or connect with me on LinkedIn and GitHub.

Originally published on Dev.to