Patrones de arquitectura para sistemas de conocimiento empresarial

Every enterprise has the same problem in a different shape: the knowledge people need exists, but it is spread across wikis, document management systems, ticket histories, contracts, product databases, and shared drives. Retrieval-augmented generation (RAG) promises a conversational layer over all of it, grounding answers in the organization's own content rather than in a model's general training.

The basic pattern is simple — split documents into chunks, embed them, retrieve the closest matches for a question, and pass them to a model — and it works well on clean, homogeneous content. Enterprise content is rarely either. It contains scanned forms, tables, superseded policy versions, exact identifiers, and, critically, permissions. In our engineering practice, quality and security problems in knowledge systems trace back to ingestion and retrieval decisions more often than to the choice of language model.

This deep dive covers the architecture patterns we recommend at each stage, the trade-offs between them, and the failure modes to plan for.

Ingestion is where answer quality is decided

Connectors should sync incrementally using change feeds, webhooks, or modification timestamps, and they must propagate deletions and permission changes, not just new content. A knowledge system that keeps serving a withdrawn policy is worse than one that has no answer at all.

Parsing deserves more investment than it usually gets. Layout-aware extraction preserves headings, lists, and tables; scanned documents need OCR with quality checks; tables often need to be kept intact or converted to a structured form rather than split across chunks. Chunk along the document's own structure — sections and subsections — rather than at fixed character counts, and consider a parent-child arrangement in which small chunks are used for precise matching while the larger surrounding section is passed to the model for context.

Attach rich metadata to every chunk. At minimum:

• Source system, document identifier, and a stable link back to the original
• Version and effective dates, so superseded content can be excluded
• Access control list: the users and groups permitted to see the source
• Owner or responsible team, for content-quality follow-up
• Document type, product, region, and language, for filtering
• Classification level, where the organization uses one

Retrieval: hybrid by default

Dense vector search captures meaning but is weak at exact matches — part numbers, policy codes, error strings, and internal acronyms the embedding model has never seen. Lexical search such as BM25 handles those well but misses paraphrase. Running both and merging the results, for example with reciprocal rank fusion, is a sound default for enterprise content. A cross-encoder reranker applied to the merged candidates then improves precision before anything reaches the model.

For complex questions, add query transformation: rewrite conversational follow-ups into standalone queries, or decompose a multi-part question into several retrievals. Apply metadata filters for region, product, or effective date when the question or the user's context makes the scope clear.

Store selection is a trade-off between operational footprint and capability. A vector extension in a database you already run, such as pgvector in PostgreSQL, keeps content, metadata, and permissions in one transactional system. Search engines with vector support, such as OpenSearch or Elasticsearch, bring mature lexical search and hybrid queries. Dedicated vector databases can simplify very large-scale similarity search. The right choice depends on corpus size, filtering complexity, and what your team already operates well.

Permission-aware retrieval is not optional

The cardinal rule is that a knowledge system must never retrieve content the user could not open in the source system. Filtering after generation is too late: once restricted text has entered the model's context, it can leak into the answer in paraphrased form.

There are two main patterns. Early binding indexes access control lists alongside each chunk and filters at query time — fast, but only as current as the last permission sync. Late binding checks each candidate against the source system after retrieval — accurate, but slower, and recall suffers when many candidates are filtered out. A common compromise is early binding with frequent permission sync for most content, plus a late check for the most sensitive sources. Either way, expand the user's group memberships from the identity provider at query time.

-- Dense retrieval leg with permission and version filters (PostgreSQL + pgvector)
-- $1 = query embedding, $2 = tenant, $3 = user id plus expanded group ids
SELECT c.id,
       c.document_id,
       c.content,
       1 - (c.embedding <=> $1) AS cosine_similarity
FROM   chunks c
WHERE  c.tenant_id = $2
  AND  c.acl_principals && $3::text[]
  AND  c.effective_to IS NULL
ORDER  BY c.embedding <=> $1
LIMIT  50;
-- The lexical leg runs separately; results are fused and reranked in the service.

One caution: approximate nearest-neighbor indexes that apply filters after the index scan can silently return fewer results than requested when filters are selective. Test retrieval with realistic permission sets, not with an administrator account that can see everything.

Generation with grounding and citations

Instruct the model to answer only from the supplied passages, to cite the passages it used, and to say so when the sources do not contain an answer. Then verify citations programmatically: confirm that each cited passage was actually retrieved and supports the claim attached to it. When retrieval confidence is low, abstaining with a clear message and links to likely sources is better than a fluent guess.

Conflicting sources are normal in enterprises. Prefer the current effective version, and when genuine conflicts remain, surface them rather than letting the model choose silently. Larger context windows do not remove the need for retrieval; passing entire repositories into every request raises cost and latency and can dilute the model's attention on the passages that matter.

Evaluate retrieval and generation separately

When an answer is wrong, you need to know whether the right content was never retrieved or was retrieved and misused. Measure retrieval with recall at k and mean reciprocal rank against a labeled set of questions and relevant passages. Measure generation for faithfulness to the retrieved sources, relevance to the question, and citation accuracy. Build the question set from real user queries, collected with appropriate consent and review.

Treat changes to chunking, embedding models, or rerankers as migrations. Re-embedding a large corpus takes time and money, and vectors from different embedding models are not comparable. Build the new index alongside the old one, evaluate both against the same question set, and cut over deliberately.

Operating the system

Production knowledge systems need their own service levels and dashboards. Track index freshness as the lag between a source change and its availability in search, and set an explicit deadline for propagating deletions and permission revocations. Trace every query with the retrieved chunk identifiers, scores, reranker output, and prompt version so any answer can be reconstructed. Capture user feedback and route poor answers to content owners as well as engineers; many bad answers are accurate summaries of bad documents.

Finally, treat retrieved content as untrusted. Documents can contain text crafted to manipulate the model — the indirect prompt injection risk described in the OWASP Top 10 for LLM Applications. Keep the assistant's tool access minimal, separate instructions from retrieved data in the prompt structure, and never let retrieved text trigger actions without independent checks.

Designing for trust

A useful enterprise knowledge system is defined less by its model than by the discipline of its pipeline: structure-aware ingestion, hybrid retrieval, enforced permissions, verified citations, and continuous evaluation. Get those right and the model can be upgraded freely; get them wrong and no model will compensate. We recommend starting with one well-understood corpus and a clearly defined user group, proving retrieval quality and permission handling there, and then expanding source by source.