RAG Over Technical and Regulatory Documentation: Cited Answers, Not Hallucination

# RAG Over Technical and Regulatory Documentation: Cited Answers, Not Hallucination

TL;DR: A properly built RAG (retrieval augmented generation) system for technical and regulatory documentation is not "plug a chatbot into your PDFs" — it is a chain of engineering decisions (chunking, embeddings, hybrid search, reranking) that must end in a verifiable source citation; skip that last piece and you are simply automating hallucination with more confidence attached.

The real problem

An operator with a pipeline integrity manual in English, an ANPG compliance dossier in Portuguese, and a set of third-party-translated HSE standards has, in practice, three overlapping problems: the documents come in different formats (scanned PDF, Word, spreadsheets with technical tables), they exist in two languages, and nobody has time to read all of them before answering a question like "what is the recommended torque for this flange, per the manufacturer's manual?" or "which documents does ANPG require to certify a drilling subcontractor?".

The temptation is to paste all the documents into a language model and ask it to answer. This fails for two structural reasons. First, most document corpora at an operator or EPC vastly exceed the context window that is practical — or affordable — to send with every request. Second, and this is the point that most worries engineering and compliance teams, a language model without access to the actual documents tends to fill gaps with plausible but invented text. In regulatory documentation, a plausible but wrong answer about a tax deadline or a certification requirement is not a cosmetic error; it is a compliance risk with a real cost attached.

RAG (retrieval augmented generation) is the architecture that solves this by separating two things language models tend to blur together: memorizing facts and reasoning over text. Instead of asking the model to "know" the manual's content, the system first retrieves the relevant excerpts from a controlled document base, and only then asks the model to reason over those specific excerpts — and to cite exactly where each statement came from. Academic research on this topic consistently shows that grounding generation in retrieved documents significantly reduces hallucination rates and improves factual fidelity on domain-specific questions, precisely because the model stops having to "guess" and starts having to "cite" [Yao et al., arXiv 2503.10677]. That shift — from "the model knows" to "the model shows where it read it" — is the difference between a useful tool and a liability generator.

The real mechanics, step by step

1. Chunking — splitting without destroying meaning

A technical document cannot be indexed whole (too large for efficient search) nor blindly cut every 500 characters (that slices a specifications table in half, or separates a clause from its article number). Chunking is the process of splitting each document into independently searchable segments ("chunks").

In engineering practice, the most common starting point for prose-heavy technical documents is a chunk of 400 to 512 tokens (roughly 300 to 400 words), with 10% to 20% overlap between consecutive chunks so context spanning a cut boundary is not lost. For documents with clear structure — manuals with numbered sections and subsections, standards with articles and clauses, which describes most Angolan regulatory documentation — the split should respect those structural boundaries (section, article, table) rather than a fixed character count; in those cases the necessary overlap tends to be smaller, in the 5% to 10% range, because the document's own structure already preserves context [Databricks Engineering Blog, "The Ultimate Guide to Chunking Strategies for RAG Applications"]. A technical specifications table or a tax rate schedule should, wherever possible, be kept as a single indivisible unit — splitting it in half is one of the most common causes of wrong answers in RAG systems poorly designed for technical content.

2. Embeddings — turning text into coordinates of meaning

Each chunk is converted into a numerical vector (an "embedding") by an embedding model, so that chunks with similar meaning end up close together in that vector space, regardless of whether they use the same words. This is what lets a question like "what to do if a worker doesn't wear PPE" find a chunk that talks about "non-compliance with personal protective equipment use," even without literal word overlap.

For a bilingual Portuguese/English context — which is the real situation for any operator or EPC working in Angola, with international manufacturers' manuals in English and regulatory and contractual documentation in Portuguese — the choice of embedding model matters more than in monolingual environments. Multilingual models such as Cohere's embed-multilingual-v3.0, trained to cover more than 100 languages, place equivalent Portuguese and English sentences close together in the same vector space, which lets a user search in Portuguese and retrieve an excerpt that only exists in English in the original manual — with no manual pre-translation of the whole corpus [Cohere Documentation, "Cohere's Embed Models"].

3. Hybrid search — vector and keyword, not one or the other

This is the most common mistake in rushed RAG implementations: using only vector (semantic) search. Vector search is excellent at finding meaning, but is systematically weak at finding exact things — a standard number ("ISO 14224"), a legal article reference ("Presidential Decree No. 271/20"), a part code, an invoice number. For those cases, classic keyword search (the BM25 algorithm, used in search engines for decades) remains more reliable than any embedding.

The now-standard engineering solution is to run both searches in parallel — vector and keyword — over the same document base, then merge the two result sets with a rank-fusion algorithm, typically Reciprocal Rank Fusion (RRF), which combines each result's position across both lists into a single final ranking [Microsoft Learn, "Hybrid Search Scoring (RRF) — Azure AI Search"]. This is not vendor-specific: the same BM25 + vector + RRF hybrid approach is available both in dedicated search engines (Azure AI Search, Elasticsearch) and directly inside a Postgres database via the pgvector extension, combined with Postgres's native full-text search — an especially relevant option for operators whose stack already runs on Postgres, avoiding the need to introduce a separate vector database just for this purpose [ParadeDB, "Hybrid Search in PostgreSQL: The Missing Manual"; pgvector documentation].

4. Reranking — the second pass that separates "relevant" from "correct"

Hybrid search typically returns 20 to 50 plausible candidates. Not all of them are equally useful — and sending 50 chunks to the generation model is expensive, slow, and dilutes the right signal in noise. Reranking is a second pass, performed by a specialized model (smaller and cheaper than the final generation model), that reorders these candidates by their real relevance to the user's exact question, looking at the question and each candidate together — something first-pass search algorithms do not do with the same precision.

Models such as Cohere Rerank support more than 100 languages and achieve equivalent performance in Portuguese relative to other key business languages [Cohere Documentation, "An Overview of Cohere's Models"], which matters precisely because, in a bilingual corpus, the question may arrive in Portuguese while the most relevant chunk sits in English (or vice versa) — the reranker has to judge that match without being thrown off by the language difference.

5. Forcing source citation — the point that separates a serious tool from a toy

This is the heart of everything else. After reranking, the generation model receives only the top 3 to 8 most relevant chunks — and an explicit instruction that every factual statement in the answer must carry an exact reference to the document and section it was drawn from, and that if the answer is not supported by any retrieved chunk, the system must say it found no information rather than invent one.

In engineering practice this requires three concrete things: (1) every stored chunk carries provenance metadata — document name, version, section or article number, page number; (2) the generation model's prompt is built so that citation is a structural requirement of the answer (for example, forcing an output format where every sentence carries an attached source identifier), not a suggestion; (3) a post-generation validation layer confirms that every citation the model points to actually corresponds to a chunk it was given — preventing the case, observed in poorly implemented systems, where the model "cites" a real document but with a fabricated section number. Research literature calls this "grounded citation," and shows that forcing generation to be anchored to a verifiable citation, produced together with the answer rather than bolted on afterward, consistently reduces the proportion of statements unsupported by source documents [arXiv 2507.18910, "A Systematic Review of Key Retrieval-Augmented Generation (RAG) Systems"]. Without this layer, a RAG system is just a chatbot with a search bolted on upstream — it can still hallucinate, only now with an appearance of rigor that more easily fools a hurried reader.

The Portuguese/English bilingual case: the real Angolan scenario

Any operator, EPC or oilfield services company working in Angola lives this problem daily, even without calling it "multilingual": equipment manuals arrive from the manufacturer in English (often also in French or Chinese, in the case of Asian suppliers), internal reports and correspondence with local regulators are in Portuguese, and compliance documentation has to reference international technical standards (API, ISO, NFPA) and Angolan legal frameworks at the same time.

Two concrete examples of the kind of regulatory documentation that requires this treatment in Angola today:

• [Electronic invoicing](https://wise-hustlers.com/blog/facturacao-electronica-angola-2026-erp-petroleo-gas) and SAF-T (AO): Presidential Decree No. 71/25, of 20 March, makes the issuance and reporting of electronic invoices mandatory from 1 January 2026 for large taxpayers and companies invoicing State entities, and from 1 January 2027 for other taxpayers under the General and Simplified regimes; submission of the SAF-T (AO) accounting file is scheduled for 2026, covering 2025 data, and invoicing software must now be certified or validated by the General Tax Administration (AGT) [EY Angola, "Facturação Electrónica a partir de 1 de Janeiro de 2026"; Angola24Horas]. A finance or IT team that needs to quickly know whether a given type of transaction falls under the 2026 mandate or only the 2027 one is, in practice, asking a RAG question over a Portuguese-language regulatory document.
• ANPG certification and [local content](https://wise-hustlers.com/blog/conteudo-local-angola-anpg-software-conformidade): Presidential Decree No. 271/20 approved the new Legal Framework for Local Content in the Petroleum Sector, and Instructive No. 6/21 establishes that any entity providing services to the petroleum sector must register and be certified with ANPG, within a legal timeframe of up to 180 days after document submission [PwC Angola, "Obrigatoriedade de certificação pela ANPG"; ANPG, "Conteúdo Local"]. A subcontractor preparing that certification benefits directly from being able to ask, in Portuguese, "which documents do I need to submit" and getting back an answer that cites the exact article of the Instructive — instead of manually combing through a many-page PDF.

Neither of these two examples requires translating the corpus to work well in a properly designed RAG system — it requires a genuinely multilingual embedding model and reranker, and hybrid search that does not lose exact references to decree, article, or instructive numbers, which is exactly the kind of textual anchor where keyword search is irreplaceable.

Architecture: real options, without pushing a "one true solution"

There is no single "correct" vendor for this — the choice depends on document volume, the company's existing stack, and data-residency requirements.

Wise Hustlers builds and operates its own Postgres-backed ERP for the energy sector, and treats AI-augmented search over technical and regulatory documentation as part of that same data engineering work — not as a separate product. Anyone wanting to see how this fits into a broader applied machine learning system for operations can look at Wise Hustlers' Machine Learning service.

On cost and timeline: any number a vendor states without context on real document volume, number of languages, and required depth of integration should be treated with skepticism. As Wise Hustlers' own estimate — not a market average — a functional RAG pilot over a corpus of a few hundred technical and regulatory documents, with hybrid search, reranking and mandatory citation, is typically a project of several weeks, not a few days; most of the effort is not "wiring up a model's API," but cleaning and structuring the source documents (many scanned PDFs need OCR and manual correction before they can even be indexed) and validating, with real domain users, that the citations produced are in fact correct.

Frequently asked questions

Does RAG remove the need to manually review critical regulatory documentation?

No, and no serious system should be sold that way. RAG dramatically speeds up finding the relevant information and forces every answer to point to its exact source, but the compliance decision remains human. The value is cutting the time to find the right excerpt from hours to minutes — not eliminating review.

Do I need to translate all my English documents into Portuguese before indexing them?

No, if you use a genuinely multilingual embedding model and reranker (such as Cohere's, among other options). The system can take a question in Portuguese and correctly retrieve an excerpt that exists only in English in the original document, with no upfront translation of the entire corpus.

Isn't "good" vector search enough on its own, without keyword search?

Not for technical and regulatory documentation. Exact references — decree numbers, standard codes, article numbers — are precisely the kind of content where vector search fails most often, because an embedding captures meaning, not literal matching. The hybrid combination (vector + BM25) with RRF fusion is standard practice today, not a luxury option.

What happens if the system can't find the answer in the indexed documents?

In a well-designed system, it should explicitly say it found no documentary support for the question, rather than generate a plausible but unverified answer. This is, in practice, the most important engineering difference between a RAG system with mandatory citation and a plain chatbot with search access.

Sources

• EY Angola — Facturação Electrónica a partir de 1 de Janeiro de 2026
• Angola24Horas — Angola começa a aplicar faturação eletrónica em 01 de janeiro de 2026 – AGT
• PwC Angola — Obrigatoriedade de certificação pela ANPG para entidades prestadoras de serviços ao sector petrolífero
• ANPG — Conteúdo Local
• Lexology — Novo regime jurídico do conteúdo local do sector dos Petróleos, Decreto Presidencial n.º 271/20
• Microsoft Learn — Hybrid Search Scoring (RRF), Azure AI Search
• Cohere Documentation — Cohere's Embed Models
• Cohere Documentation — An Overview of Cohere's Models
• ParadeDB — Hybrid Search in PostgreSQL: The Missing Manual
• Databricks Community — The Ultimate Guide to Chunking Strategies for RAG Applications
• arXiv 2503.10677 — A Survey on Knowledge-Oriented Retrieval-Augmented Generation
• arXiv 2507.18910 — A Systematic Review of Key Retrieval-Augmented Generation (RAG) Systems