santismm-knowledge-mcp 0.2.1

package/content/knowledge/context-engineering.json

@@ -0,0 +1,153 @@
+{
+  "slug": "context-engineering",
+  "category": "harness",
+  "updated": "2026-06-21",
+  "version": "1.0",
+  "related": ["harness-engineering", "prompt-engineering", "agent-memory", "enterprise-rag"],
+  "references": [
+    { "title": "Anthropic — Effective context engineering for AI agents (2025)", "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents" },
+    { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }
+  ],
+  "evidence": {
+    "evidenceLevel": "industry_observation",
+    "confidenceLevel": "high",
+    "sourceType": ["industry_observation", "paper"]
+  },
+  "locales": {
+    "en": {
+      "title": "What is Context Engineering?",
+      "summary": "Context engineering is the discipline of deciding what information enters a model's limited context window at each step — and what stays out. As agents run over many steps, naively stuffing everything into context degrades quality and cost. Context engineering curates the right instructions, retrieved knowledge, tool results and memory so the model has exactly what it needs, when it needs it. It is a core part of harness engineering.",
+      "definition": "Context engineering is the practice of curating, compressing and sequencing the information placed in a model's context window so it has the most relevant signal — and the least noise — at each step.",
+      "takeaways": [
+        "Context is a scarce resource; what you leave out matters as much as what you include.",
+        "More context is not better — irrelevant tokens degrade quality and raise cost.",
+        "Techniques: retrieval, summarization, compaction, and structured memory.",
+        "It generalizes prompt engineering from one prompt to a whole agent run.",
+        "It is a core layer of the harness around a model."
+      ],
+      "context": [
+        "Every model has a finite context window, and quality degrades when it is filled with low-signal content. In single-turn use this is manageable, but agents accumulate history, tool outputs and retrieved documents across many steps, quickly overwhelming the window.",
+        "Context engineering treats the window as a budget to be managed deliberately: keep the durable instructions, retrieve only what is relevant now, summarize or compact the rest, and store long-term state outside the window in memory."
+      ],
+      "architecture": [
+        "Core moves: select (retrieve only relevant passages), compress (summarize prior steps), compact (drop or fold stale turns), and externalize (push long-term state to a memory store, pulling it back on demand).",
+        "In an agent loop, context is reassembled each step from layered sources: stable system instructions, task state, relevant retrieved knowledge, recent tool results and selected long-term memories — ordered so the most important signal is most salient."
+      ],
+      "components": ["System instructions", "Task state", "Retrieved knowledge", "Tool results", "Long-term memory", "Summaries / compaction"],
+      "pros": [
+        "Keeps quality high as tasks grow long.",
+        "Controls token cost and latency.",
+        "Reduces distraction and hallucination from noise.",
+        "Enables long-horizon agents within finite context."
+      ],
+      "risks": [
+        "Over-aggressive compression can drop needed information.",
+        "Poor retrieval injects irrelevant or wrong context.",
+        "Complexity in deciding what to keep each step.",
+        "Bugs here surface as subtle quality regressions."
+      ],
+      "tools": ["Retrieval / RAG pipelines", "Summarization models", "Memory stores", "Context-management frameworks (e.g. LangGraph)"],
+      "examples": [
+        "Summarizing earlier agent steps so the window stays focused on the current subtask.",
+        "Retrieving only the policy section relevant to a question instead of the whole manual.",
+        "Storing a user's preferences in memory and recalling them only when relevant."
+      ],
+      "faqs": [
+        { "q": "How is context engineering different from prompt engineering?", "a": "Prompt engineering crafts a single instruction. Context engineering manages the full set of information in the window across an entire agent run — retrieval, memory, tool results and compression included." },
+        { "q": "Why not just use a bigger context window?", "a": "Larger windows help but do not eliminate the problem: quality and cost degrade as windows fill with low-signal tokens. Curation still wins." },
+        { "q": "How does it relate to RAG and memory?", "a": "RAG and memory are sources of context; context engineering decides what from them actually enters the window, when, and in what form." },
+        { "q": "Is it part of harness engineering?", "a": "Yes. Context management is one of the core layers of the harness that turns model capability into reliable agent behavior." }
+      ]
+    },
+    "es": {
+      "title": "¿Qué es la Ingeniería de Contexto (Context Engineering)?",
+      "summary": "La ingeniería de contexto es la disciplina de decidir qué información entra en la ventana de contexto limitada de un modelo en cada paso, y qué se queda fuera. Como los agentes se ejecutan en muchos pasos, meter todo ingenuamente en el contexto degrada calidad y coste. La ingeniería de contexto cura las instrucciones, el conocimiento recuperado, los resultados de herramientas y la memoria adecuados para que el modelo tenga justo lo que necesita cuando lo necesita. Es una parte central de la ingeniería de harness.",
+      "definition": "La ingeniería de contexto es la práctica de curar, comprimir y secuenciar la información que se coloca en la ventana de contexto de un modelo para que tenga la señal más relevante —y el menor ruido— en cada paso.",
+      "takeaways": [
+        "El contexto es un recurso escaso; lo que dejas fuera importa tanto como lo que incluyes.",
+        "Más contexto no es mejor: los tokens irrelevantes degradan calidad y suben el coste.",
+        "Técnicas: recuperación, resumen, compactación y memoria estructurada.",
+        "Generaliza la ingeniería de prompts de un prompt a toda una ejecución de agente.",
+        "Es una capa central del harness alrededor del modelo."
+      ],
+      "context": [
+        "Todo modelo tiene una ventana de contexto finita, y la calidad se degrada cuando se llena de contenido de baja señal. En uso de un solo turno es manejable, pero los agentes acumulan historial, salidas de herramientas y documentos recuperados a lo largo de muchos pasos, saturando rápido la ventana.",
+        "La ingeniería de contexto trata la ventana como un presupuesto a gestionar de forma deliberada: conservar las instrucciones duraderas, recuperar solo lo relevante ahora, resumir o compactar el resto y guardar el estado a largo plazo fuera de la ventana en memoria."
+      ],
+      "architecture": [
+        "Movimientos clave: seleccionar (recuperar solo pasajes relevantes), comprimir (resumir pasos previos), compactar (descartar o plegar turnos obsoletos) y externalizar (llevar el estado a largo plazo a un almacén de memoria y traerlo bajo demanda).",
+        "En un bucle de agente, el contexto se reensambla en cada paso desde fuentes en capas: instrucciones de sistema estables, estado de la tarea, conocimiento recuperado relevante, resultados recientes de herramientas y memorias a largo plazo seleccionadas, ordenadas para que la señal más importante sea la más saliente."
+      ],
+      "components": ["Instrucciones de sistema", "Estado de la tarea", "Conocimiento recuperado", "Resultados de herramientas", "Memoria a largo plazo", "Resúmenes / compactación"],
+      "pros": [
+        "Mantiene alta la calidad cuando las tareas se alargan.",
+        "Controla el coste de tokens y la latencia.",
+        "Reduce la distracción y la alucinación por ruido.",
+        "Habilita agentes de horizonte largo dentro de un contexto finito."
+      ],
+      "risks": [
+        "Una compresión demasiado agresiva puede descartar información necesaria.",
+        "Una recuperación pobre inyecta contexto irrelevante o erróneo.",
+        "Complejidad al decidir qué conservar en cada paso.",
+        "Los errores aquí aparecen como regresiones sutiles de calidad."
+      ],
+      "tools": ["Pipelines de recuperación / RAG", "Modelos de resumen", "Almacenes de memoria", "Frameworks de gestión de contexto (p. ej. LangGraph)"],
+      "examples": [
+        "Resumir pasos anteriores del agente para que la ventana siga enfocada en la subtarea actual.",
+        "Recuperar solo la sección de la política relevante a una pregunta en vez de todo el manual.",
+        "Guardar las preferencias de un usuario en memoria y recordarlas solo cuando son relevantes."
+      ],
+      "faqs": [
+        { "q": "¿En qué se diferencia de la ingeniería de prompts?", "a": "La ingeniería de prompts crea una sola instrucción. La ingeniería de contexto gestiona todo el conjunto de información en la ventana a lo largo de una ejecución de agente, incluyendo recuperación, memoria, resultados de herramientas y compresión." },
+        { "q": "¿Por qué no usar simplemente una ventana de contexto más grande?", "a": "Las ventanas más grandes ayudan pero no eliminan el problema: la calidad y el coste se degradan al llenarse de tokens de baja señal. La curación sigue ganando." },
+        { "q": "¿Cómo se relaciona con RAG y la memoria?", "a": "RAG y la memoria son fuentes de contexto; la ingeniería de contexto decide qué de ellas entra realmente en la ventana, cuándo y en qué forma." },
+        { "q": "¿Es parte de la ingeniería de harness?", "a": "Sí. La gestión de contexto es una de las capas centrales del harness que convierte la capacidad del modelo en comportamiento fiable del agente." }
+      ]
+    },
+    "pt": {
+      "title": "O que é Engenharia de Contexto (Context Engineering)?",
+      "summary": "A engenharia de contexto é a disciplina de decidir qual informação entra na janela de contexto limitada de um modelo a cada passo, e o que fica de fora. Como os agentes rodam em muitos passos, enfiar tudo ingenuamente no contexto degrada qualidade e custo. A engenharia de contexto cura as instruções, o conhecimento recuperado, os resultados de ferramentas e a memória adequados para que o modelo tenha exatamente o que precisa quando precisa. É uma parte central da engenharia de harness.",
+      "definition": "A engenharia de contexto é a prática de curar, comprimir e sequenciar a informação colocada na janela de contexto de um modelo para que ele tenha o sinal mais relevante — e o menor ruído — a cada passo.",
+      "takeaways": [
+        "O contexto é um recurso escasso; o que você deixa de fora importa tanto quanto o que inclui.",
+        "Mais contexto não é melhor: tokens irrelevantes degradam a qualidade e elevam o custo.",
+        "Técnicas: recuperação, resumo, compactação e memória estruturada.",
+        "Generaliza a engenharia de prompts de um prompt para toda uma execução de agente.",
+        "É uma camada central do harness em torno do modelo."
+      ],
+      "context": [
+        "Todo modelo tem uma janela de contexto finita, e a qualidade se degrada quando ela é preenchida com conteúdo de baixo sinal. No uso de um único turno é gerenciável, mas os agentes acumulam histórico, saídas de ferramentas e documentos recuperados ao longo de muitos passos, saturando rápido a janela.",
+        "A engenharia de contexto trata a janela como um orçamento a gerir de forma deliberada: manter as instruções duráveis, recuperar só o relevante agora, resumir ou compactar o resto e guardar o estado de longo prazo fora da janela na memória."
+      ],
+      "architecture": [
+        "Movimentos centrais: selecionar (recuperar só trechos relevantes), comprimir (resumir passos anteriores), compactar (descartar ou dobrar turnos obsoletos) e externalizar (levar o estado de longo prazo a um armazenamento de memória e trazê-lo sob demanda).",
+        "Num laço de agente, o contexto é remontado a cada passo a partir de fontes em camadas: instruções de sistema estáveis, estado da tarefa, conhecimento recuperado relevante, resultados recentes de ferramentas e memórias de longo prazo selecionadas, ordenados para que o sinal mais importante seja o mais saliente."
+      ],
+      "components": ["Instruções de sistema", "Estado da tarefa", "Conhecimento recuperado", "Resultados de ferramentas", "Memória de longo prazo", "Resumos / compactação"],
+      "pros": [
+        "Mantém a qualidade alta quando as tarefas se alongam.",
+        "Controla o custo de tokens e a latência.",
+        "Reduz a distração e a alucinação por ruído.",
+        "Habilita agentes de horizonte longo dentro de um contexto finito."
+      ],
+      "risks": [
+        "Uma compressão agressiva demais pode descartar informação necessária.",
+        "Uma recuperação ruim injeta contexto irrelevante ou errado.",
+        "Complexidade ao decidir o que manter a cada passo.",
+        "Bugs aqui aparecem como regressões sutis de qualidade."
+      ],
+      "tools": ["Pipelines de recuperação / RAG", "Modelos de resumo", "Armazenamentos de memória", "Frameworks de gestão de contexto (ex.: LangGraph)"],
+      "examples": [
+        "Resumir passos anteriores do agente para a janela seguir focada na subtarefa atual.",
+        "Recuperar só a seção da política relevante a uma pergunta em vez de todo o manual.",
+        "Guardar as preferências de um usuário na memória e lembrá-las só quando relevantes."
+      ],
+      "faqs": [
+        { "q": "Qual a diferença para a engenharia de prompts?", "a": "A engenharia de prompts cria uma única instrução. A engenharia de contexto gere todo o conjunto de informação na janela ao longo de uma execução de agente, incluindo recuperação, memória, resultados de ferramentas e compressão." },
+        { "q": "Por que não usar simplesmente uma janela de contexto maior?", "a": "Janelas maiores ajudam mas não eliminam o problema: qualidade e custo se degradam ao se encherem de tokens de baixo sinal. A curadoria ainda vence." },
+        { "q": "Como se relaciona com RAG e memória?", "a": "RAG e memória são fontes de contexto; a engenharia de contexto decide o que delas realmente entra na janela, quando e em que forma." },
+        { "q": "É parte da engenharia de harness?", "a": "Sim. A gestão de contexto é uma das camadas centrais do harness que converte a capacidade do modelo em comportamento confiável do agente." }
+      ]
+    }
+  }
+}

package/content/knowledge/embeddings.json

@@ -0,0 +1,153 @@
+{
+  "slug": "embeddings",
+  "category": "concept",
+  "updated": "2026-06-21",
+  "version": "1.0",
+  "related": ["enterprise-rag", "foundation-models", "fine-tuning", "agentic-ai"],
+  "references": [
+    { "title": "Reimers & Gurevych — Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks (2019)", "url": "https://arxiv.org/abs/1908.10084" },
+    { "title": "Mikolov et al. — Efficient Estimation of Word Representations (word2vec, 2013)", "url": "https://arxiv.org/abs/1301.3781" }
+  ],
+  "evidence": {
+    "evidenceLevel": "benchmark",
+    "confidenceLevel": "high",
+    "sourceType": ["benchmark", "paper"]
+  },
+  "locales": {
+    "en": {
+      "title": "What are Embeddings & Vector Search?",
+      "summary": "An embedding is a numeric vector that represents the meaning of text (or images, audio, code) so that semantically similar items sit close together in vector space. Vector search finds the nearest embeddings to a query, enabling search by meaning rather than keywords. Embeddings are the backbone of retrieval-augmented generation, semantic search, clustering and recommendation.",
+      "definition": "An embedding is a dense numeric vector that encodes the meaning of a piece of data, positioned so that similar items are close in vector space; vector search retrieves the nearest embeddings to a query.",
+      "takeaways": [
+        "Embeddings turn meaning into vectors; similar things sit close together.",
+        "Vector search retrieves by semantic similarity, not exact keywords.",
+        "They power RAG, semantic search, clustering and recommendation.",
+        "Hybrid search (vector + keyword) usually beats either alone.",
+        "Chunking and the embedding model choice drive retrieval quality."
+      ],
+      "context": [
+        "Computers compare numbers, not meaning. Embeddings bridge that gap: an embedding model maps text to a vector such that 'cancel my subscription' and 'how do I unsubscribe' land near each other, even with no shared words.",
+        "This is what makes semantic retrieval possible. Instead of matching keywords, a system embeds the query and finds the closest stored vectors — the foundation of how RAG and modern search retrieve relevant content."
+      ],
+      "architecture": [
+        "Indexing: content is split into chunks, each passed through an embedding model to produce a vector, then stored in a vector index. Querying: the query is embedded and the index returns the nearest vectors by a similarity metric (e.g. cosine).",
+        "Production systems add a re-ranker to refine the top results, combine vector search with keyword search (hybrid), and filter by metadata and permissions. Quality depends heavily on chunking and the embedding model."
+      ],
+      "components": ["Embedding model", "Chunking", "Vector index / database", "Similarity metric (cosine)", "Re-ranker", "Hybrid (keyword) search"],
+      "pros": [
+        "Search by meaning, robust to wording.",
+        "Cross-lingual and multimodal matching.",
+        "The backbone of RAG and semantic search.",
+        "Cheap to query at scale once indexed."
+      ],
+      "risks": [
+        "Poor chunking degrades every downstream result.",
+        "Embedding model mismatch hurts relevance.",
+        "Vectors can leak sensitive info; secure the store.",
+        "Pure vector search can miss exact-match needs (use hybrid)."
+      ],
+      "tools": ["Embedding models (OpenAI, Cohere, open-source)", "Vector databases (pgvector, Pinecone, Vertex AI Vector Search)", "Re-rankers", "Hybrid search engines"],
+      "examples": [
+        "Semantic search over a help center that matches intent, not keywords.",
+        "Retrieving relevant passages to ground a RAG answer.",
+        "Clustering support tickets by topic using their embeddings."
+      ],
+      "faqs": [
+        { "q": "How are embeddings different from keywords?", "a": "Keyword search matches exact words; embeddings match meaning, so paraphrases and synonyms still retrieve the right content." },
+        { "q": "What is vector search?", "a": "Finding the stored embeddings nearest to a query embedding by a similarity metric like cosine distance — search by semantic closeness." },
+        { "q": "Why combine vector and keyword search?", "a": "Vectors excel at meaning but can miss exact terms (codes, names). Hybrid search blends both for the best recall and precision." },
+        { "q": "Do embeddings power RAG?", "a": "Yes. RAG embeds documents and queries, retrieves the nearest chunks by vector search, and grounds the model's answer in them." }
+      ]
+    },
+    "es": {
+      "title": "¿Qué son los Embeddings y la Búsqueda Vectorial?",
+      "summary": "Un embedding es un vector numérico que representa el significado de un texto (o imágenes, audio, código) de modo que los elementos semánticamente similares quedan cerca en el espacio vectorial. La búsqueda vectorial encuentra los embeddings más cercanos a una consulta, permitiendo buscar por significado en vez de por palabras clave. Los embeddings son la columna vertebral de la generación aumentada por recuperación, la búsqueda semántica, el clustering y la recomendación.",
+      "definition": "Un embedding es un vector numérico denso que codifica el significado de un dato, situado de forma que los elementos similares quedan cerca en el espacio vectorial; la búsqueda vectorial recupera los embeddings más cercanos a una consulta.",
+      "takeaways": [
+        "Los embeddings convierten el significado en vectores; lo similar queda cerca.",
+        "La búsqueda vectorial recupera por similitud semántica, no por palabras exactas.",
+        "Sustentan el RAG, la búsqueda semántica, el clustering y la recomendación.",
+        "La búsqueda híbrida (vector + palabras clave) suele superar a cada una sola.",
+        "El chunking y la elección del modelo de embeddings determinan la calidad."
+      ],
+      "context": [
+        "Los ordenadores comparan números, no significado. Los embeddings salvan esa brecha: un modelo de embeddings mapea texto a un vector de modo que 'cancela mi suscripción' y 'cómo me doy de baja' caen cerca, aun sin palabras compartidas.",
+        "Esto es lo que hace posible la recuperación semántica. En vez de casar palabras clave, el sistema embebe la consulta y encuentra los vectores almacenados más cercanos: la base de cómo el RAG y la búsqueda moderna recuperan contenido relevante."
+      ],
+      "architecture": [
+        "Indexación: el contenido se divide en chunks, cada uno pasa por un modelo de embeddings para producir un vector y se guarda en un índice vectorial. Consulta: la consulta se embebe y el índice devuelve los vectores más cercanos por una métrica de similitud (p. ej. coseno).",
+        "Los sistemas en producción añaden un re-ranker para refinar los mejores resultados, combinan búsqueda vectorial con búsqueda por palabras clave (híbrida) y filtran por metadatos y permisos. La calidad depende mucho del chunking y del modelo de embeddings."
+      ],
+      "components": ["Modelo de embeddings", "Chunking", "Índice / base de datos vectorial", "Métrica de similitud (coseno)", "Re-ranker", "Búsqueda híbrida (palabras clave)"],
+      "pros": [
+        "Búsqueda por significado, robusta a la redacción.",
+        "Coincidencia translingüe y multimodal.",
+        "La columna vertebral del RAG y la búsqueda semántica.",
+        "Barata de consultar a escala una vez indexada."
+      ],
+      "risks": [
+        "Un chunking pobre degrada todo resultado posterior.",
+        "Un modelo de embeddings inadecuado daña la relevancia.",
+        "Los vectores pueden filtrar info sensible; asegura el almacén.",
+        "La búsqueda vectorial pura puede fallar en coincidencias exactas (usa híbrida)."
+      ],
+      "tools": ["Modelos de embeddings (OpenAI, Cohere, open source)", "Bases de datos vectoriales (pgvector, Pinecone, Vertex AI Vector Search)", "Re-rankers", "Motores de búsqueda híbrida"],
+      "examples": [
+        "Búsqueda semántica en un centro de ayuda que casa la intención, no las palabras.",
+        "Recuperar pasajes relevantes para fundamentar una respuesta RAG.",
+        "Agrupar tickets de soporte por tema usando sus embeddings."
+      ],
+      "faqs": [
+        { "q": "¿En qué se diferencian los embeddings de las palabras clave?", "a": "La búsqueda por palabras clave casa palabras exactas; los embeddings casan significado, así que paráfrasis y sinónimos siguen recuperando el contenido correcto." },
+        { "q": "¿Qué es la búsqueda vectorial?", "a": "Encontrar los embeddings almacenados más cercanos al embedding de una consulta por una métrica como la distancia coseno: búsqueda por cercanía semántica." },
+        { "q": "¿Por qué combinar búsqueda vectorial y por palabras clave?", "a": "Los vectores destacan en significado pero pueden fallar en términos exactos (códigos, nombres). La búsqueda híbrida combina ambas para mejor recall y precisión." },
+        { "q": "¿Los embeddings sustentan el RAG?", "a": "Sí. El RAG embebe documentos y consultas, recupera los chunks más cercanos por búsqueda vectorial y fundamenta en ellos la respuesta del modelo." }
+      ]
+    },
+    "pt": {
+      "title": "O que são Embeddings e Busca Vetorial?",
+      "summary": "Um embedding é um vetor numérico que representa o significado de um texto (ou imagens, áudio, código) de modo que itens semanticamente similares ficam próximos no espaço vetorial. A busca vetorial encontra os embeddings mais próximos de uma consulta, permitindo buscar por significado em vez de palavras-chave. Os embeddings são a espinha dorsal da geração aumentada por recuperação, da busca semântica, do clustering e da recomendação.",
+      "definition": "Um embedding é um vetor numérico denso que codifica o significado de um dado, posicionado de forma que itens similares ficam próximos no espaço vetorial; a busca vetorial recupera os embeddings mais próximos de uma consulta.",
+      "takeaways": [
+        "Embeddings transformam significado em vetores; o similar fica próximo.",
+        "A busca vetorial recupera por similaridade semântica, não por palavras exatas.",
+        "Sustentam o RAG, a busca semântica, o clustering e a recomendação.",
+        "A busca híbrida (vetor + palavras-chave) costuma superar cada uma sozinha.",
+        "O chunking e a escolha do modelo de embeddings determinam a qualidade."
+      ],
+      "context": [
+        "Os computadores comparam números, não significado. Os embeddings preenchem essa lacuna: um modelo de embeddings mapeia texto a um vetor de modo que 'cancele minha assinatura' e 'como eu me descadastro' caem próximos, mesmo sem palavras em comum.",
+        "Isso é o que torna possível a recuperação semântica. Em vez de casar palavras-chave, o sistema embeda a consulta e encontra os vetores armazenados mais próximos: a base de como o RAG e a busca moderna recuperam conteúdo relevante."
+      ],
+      "architecture": [
+        "Indexação: o conteúdo é dividido em chunks, cada um passa por um modelo de embeddings para produzir um vetor e é guardado num índice vetorial. Consulta: a consulta é embedada e o índice devolve os vetores mais próximos por uma métrica de similaridade (ex.: cosseno).",
+        "Os sistemas em produção adicionam um re-ranker para refinar os melhores resultados, combinam busca vetorial com busca por palavras-chave (híbrida) e filtram por metadados e permissões. A qualidade depende muito do chunking e do modelo de embeddings."
+      ],
+      "components": ["Modelo de embeddings", "Chunking", "Índice / banco de dados vetorial", "Métrica de similaridade (cosseno)", "Re-ranker", "Busca híbrida (palavras-chave)"],
+      "pros": [
+        "Busca por significado, robusta à redação.",
+        "Correspondência translíngue e multimodal.",
+        "A espinha dorsal do RAG e da busca semântica.",
+        "Barata de consultar em escala uma vez indexada."
+      ],
+      "risks": [
+        "Um chunking ruim degrada todo resultado posterior.",
+        "Um modelo de embeddings inadequado prejudica a relevância.",
+        "Os vetores podem vazar info sensível; proteja o armazenamento.",
+        "A busca vetorial pura pode falhar em correspondências exatas (use híbrida)."
+      ],
+      "tools": ["Modelos de embeddings (OpenAI, Cohere, open source)", "Bancos de dados vetoriais (pgvector, Pinecone, Vertex AI Vector Search)", "Re-rankers", "Motores de busca híbrida"],
+      "examples": [
+        "Busca semântica numa central de ajuda que casa a intenção, não as palavras.",
+        "Recuperar trechos relevantes para fundamentar uma resposta RAG.",
+        "Agrupar chamados de suporte por tema usando seus embeddings."
+      ],
+      "faqs": [
+        { "q": "Como os embeddings diferem das palavras-chave?", "a": "A busca por palavras-chave casa palavras exatas; os embeddings casam significado, então paráfrases e sinônimos ainda recuperam o conteúdo correto." },
+        { "q": "O que é busca vetorial?", "a": "Encontrar os embeddings armazenados mais próximos do embedding de uma consulta por uma métrica como a distância cosseno: busca por proximidade semântica." },
+        { "q": "Por que combinar busca vetorial e por palavras-chave?", "a": "Os vetores se destacam em significado mas podem falhar em termos exatos (códigos, nomes). A busca híbrida combina ambas para melhor recall e precisão." },
+        { "q": "Os embeddings sustentam o RAG?", "a": "Sim. O RAG embeda documentos e consultas, recupera os chunks mais próximos por busca vetorial e fundamenta neles a resposta do modelo." }
+      ]
+    }
+  }
+}

package/content/knowledge/enterprise-rag.json

@@ -0,0 +1,154 @@
+{
+  "slug": "enterprise-rag",
+  "category": "pattern",
+  "updated": "2026-06-21",
+  "version": "1.0",
+  "featured": true,
+  "related": ["agentic-ai", "model-context-protocol", "ai-governance", "ai-agent"],
+  "references": [
+    { "title": "Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020)", "url": "https://arxiv.org/abs/2005.11401" },
+    { "title": "Model Context Protocol — Resources", "url": "https://modelcontextprotocol.io" }
+  ],
+  "evidence": {
+    "evidenceLevel": "benchmark",
+    "confidenceLevel": "high",
+    "sourceType": ["benchmark", "paper", "industry_observation"]
+  },
+  "locales": {
+    "en": {
+      "title": "What is Enterprise RAG?",
+      "summary": "Enterprise RAG (retrieval-augmented generation) is the pattern of grounding a model's answers in an organization's own documents, retrieved at query time, instead of relying on the model's parametric memory. It lets a company use private, current and governed knowledge — policies, manuals, tickets, contracts — without retraining a model, while keeping access control, citations and auditability that enterprises require.",
+      "definition": "Enterprise RAG is a pattern that retrieves relevant passages from an organization's governed knowledge sources and supplies them to a model as context, so answers are grounded, current and citable.",
+      "takeaways": [
+        "RAG grounds answers in retrieved documents, reducing hallucination.",
+        "It uses private and fresh knowledge without retraining.",
+        "Retrieval quality (chunking + embeddings) drives answer quality.",
+        "Enterprise-grade RAG adds access control, citations and audit.",
+        "Becomes agentic when the system decides when and what to retrieve."
+      ],
+      "context": [
+        "A base model only knows what it learned during training. Enterprise knowledge is private, changing and access-controlled. RAG bridges that gap by fetching the right passages at query time and grounding the answer in them.",
+        "The enterprise difference is governance: who is allowed to see which documents, where the answer's sources came from, and whether the whole interaction can be audited. RAG that ignores these is a prototype, not a production system."
+      ],
+      "architecture": [
+        "Ingestion: documents are parsed, split into self-contained chunks, embedded and stored in a vector index (often alongside keyword search). Retrieval: a query is embedded, the nearest chunks are fetched, optionally re-ranked and filtered by permissions. Generation: the model answers using those chunks and cites them.",
+        "Quality hinges on the unglamorous parts: clean parsing, sensible chunking, hybrid (vector + keyword) retrieval, re-ranking, and permission filtering. Well-structured source content makes every one of these steps easier."
+      ],
+      "components": ["Ingestion & chunking", "Embeddings", "Vector / hybrid index", "Retriever & re-ranker", "Permission filter", "Generator (LLM)", "Citation layer"],
+      "pros": [
+        "Grounded, citable, up-to-date answers.",
+        "Uses private knowledge without retraining.",
+        "Respects access control and auditability.",
+        "Cheaper and faster to update than fine-tuning."
+      ],
+      "risks": [
+        "Poor chunking or retrieval yields wrong or irrelevant context.",
+        "Stale or unpermissioned data leaks into answers.",
+        "Citations can be plausible but unsupported if not verified.",
+        "Retrieval latency and cost at scale."
+      ],
+      "tools": ["Vector databases (e.g. pgvector, Pinecone, Vertex AI Vector Search)", "Embedding models", "Re-rankers", "Hybrid search engines", "MCP resource servers"],
+      "examples": [
+        "An internal assistant answering HR policy questions with cited passages.",
+        "A support agent retrieving product docs to resolve tickets.",
+        "A legal assistant surfacing relevant clauses with source links."
+      ],
+      "faqs": [
+        { "q": "Is RAG better than fine-tuning?", "a": "They solve different problems. RAG injects fresh, governed knowledge at query time; fine-tuning adapts behavior or style. They are often combined." },
+        { "q": "Why does chunking matter so much?", "a": "Retrieval works on chunks. Self-contained, well-structured chunks retrieve cleanly; fragmented ones return noise. Chunk quality largely sets RAG quality." },
+        { "q": "What makes RAG enterprise-grade?", "a": "Access control on retrieval, source citations, auditability, freshness, and evaluation — not just a vector store plus a model." },
+        { "q": "When does RAG become agentic?", "a": "When retrieval is one step in a multi-step loop where the system decides whether, when and what to retrieve, rather than always retrieving once." }
+      ]
+    },
+    "es": {
+      "title": "¿Qué es el RAG empresarial (Enterprise RAG)?",
+      "summary": "El RAG empresarial (generación aumentada por recuperación) es el patrón de fundamentar las respuestas de un modelo en los propios documentos de la organización, recuperados en el momento de la consulta, en lugar de depender de la memoria paramétrica del modelo. Permite usar conocimiento privado, actual y gobernado —políticas, manuales, tickets, contratos— sin reentrenar un modelo, manteniendo el control de acceso, las citas y la auditabilidad que exigen las empresas.",
+      "definition": "El RAG empresarial es un patrón que recupera pasajes relevantes de las fuentes de conocimiento gobernadas de una organización y los entrega a un modelo como contexto, para que las respuestas estén fundamentadas, actualizadas y sean citables.",
+      "takeaways": [
+        "El RAG fundamenta las respuestas en documentos recuperados, reduciendo la alucinación.",
+        "Usa conocimiento privado y fresco sin reentrenar.",
+        "La calidad de recuperación (chunking + embeddings) determina la calidad de la respuesta.",
+        "El RAG de grado empresarial añade control de acceso, citas y auditoría.",
+        "Se vuelve agéntico cuando el sistema decide cuándo y qué recuperar."
+      ],
+      "context": [
+        "Un modelo base solo sabe lo que aprendió durante el entrenamiento. El conocimiento empresarial es privado, cambiante y con control de acceso. El RAG salva esa brecha recuperando los pasajes adecuados en el momento de la consulta y fundamentando la respuesta en ellos.",
+        "La diferencia empresarial es la gobernanza: quién puede ver qué documentos, de dónde vienen las fuentes de la respuesta y si toda la interacción puede auditarse. Un RAG que ignora esto es un prototipo, no un sistema en producción."
+      ],
+      "architecture": [
+        "Ingesta: los documentos se parsean, se dividen en chunks autocontenidos, se embeben y se guardan en un índice vectorial (a menudo junto a búsqueda por palabras clave). Recuperación: la consulta se embebe, se traen los chunks más cercanos, se re-rankean y se filtran por permisos. Generación: el modelo responde usando esos chunks y los cita.",
+        "La calidad depende de las partes poco glamurosas: parseo limpio, chunking sensato, recuperación híbrida (vector + palabras clave), re-ranking y filtrado por permisos. Un contenido fuente bien estructurado facilita cada uno de esos pasos."
+      ],
+      "components": ["Ingesta y chunking", "Embeddings", "Índice vectorial / híbrido", "Recuperador y re-ranker", "Filtro de permisos", "Generador (LLM)", "Capa de citas"],
+      "pros": [
+        "Respuestas fundamentadas, citables y actualizadas.",
+        "Usa conocimiento privado sin reentrenar.",
+        "Respeta el control de acceso y la auditabilidad.",
+        "Más barato y rápido de actualizar que el fine-tuning."
+      ],
+      "risks": [
+        "Un chunking o recuperación pobres dan contexto erróneo o irrelevante.",
+        "Datos desactualizados o sin permisos se filtran en las respuestas.",
+        "Las citas pueden ser plausibles pero no respaldadas si no se verifican.",
+        "Latencia y coste de recuperación a escala."
+      ],
+      "tools": ["Bases de datos vectoriales (p. ej. pgvector, Pinecone, Vertex AI Vector Search)", "Modelos de embeddings", "Re-rankers", "Motores de búsqueda híbrida", "Servidores de recursos MCP"],
+      "examples": [
+        "Un asistente interno que responde preguntas de políticas de RRHH con pasajes citados.",
+        "Un agente de soporte que recupera documentación de producto para resolver tickets.",
+        "Un asistente legal que muestra cláusulas relevantes con enlaces a la fuente."
+      ],
+      "faqs": [
+        { "q": "¿El RAG es mejor que el fine-tuning?", "a": "Resuelven problemas distintos. El RAG inyecta conocimiento fresco y gobernado en el momento de la consulta; el fine-tuning adapta comportamiento o estilo. A menudo se combinan." },
+        { "q": "¿Por qué importa tanto el chunking?", "a": "La recuperación opera sobre chunks. Los chunks autocontenidos y bien estructurados se recuperan limpiamente; los fragmentados devuelven ruido. La calidad del chunk fija en gran medida la del RAG." },
+        { "q": "¿Qué hace a un RAG de grado empresarial?", "a": "Control de acceso en la recuperación, citas de fuentes, auditabilidad, frescura y evaluación, no solo un almacén vectorial más un modelo." },
+        { "q": "¿Cuándo se vuelve agéntico el RAG?", "a": "Cuando la recuperación es un paso de un bucle de varios pasos en el que el sistema decide si, cuándo y qué recuperar, en vez de recuperar siempre una vez." }
+      ]
+    },
+    "pt": {
+      "title": "O que é RAG empresarial (Enterprise RAG)?",
+      "summary": "O RAG empresarial (geração aumentada por recuperação) é o padrão de fundamentar as respostas de um modelo nos próprios documentos da organização, recuperados no momento da consulta, em vez de depender da memória paramétrica do modelo. Permite usar conhecimento privado, atual e governado — políticas, manuais, chamados, contratos — sem retreinar um modelo, mantendo o controle de acesso, as citações e a auditabilidade que as empresas exigem.",
+      "definition": "O RAG empresarial é um padrão que recupera trechos relevantes das fontes de conhecimento governadas de uma organização e os fornece a um modelo como contexto, para que as respostas sejam fundamentadas, atuais e citáveis.",
+      "takeaways": [
+        "O RAG fundamenta as respostas em documentos recuperados, reduzindo a alucinação.",
+        "Usa conhecimento privado e fresco sem retreinar.",
+        "A qualidade da recuperação (chunking + embeddings) determina a qualidade da resposta.",
+        "O RAG de nível empresarial adiciona controle de acesso, citações e auditoria.",
+        "Torna-se agêntico quando o sistema decide quando e o que recuperar."
+      ],
+      "context": [
+        "Um modelo base só sabe o que aprendeu durante o treinamento. O conhecimento empresarial é privado, mutável e com controle de acesso. O RAG preenche essa lacuna recuperando os trechos adequados no momento da consulta e fundamentando a resposta neles.",
+        "A diferença empresarial é a governança: quem pode ver quais documentos, de onde vieram as fontes da resposta e se toda a interação pode ser auditada. Um RAG que ignora isso é um protótipo, não um sistema em produção."
+      ],
+      "architecture": [
+        "Ingestão: os documentos são parseados, divididos em chunks autocontidos, embedados e guardados num índice vetorial (muitas vezes junto à busca por palavras-chave). Recuperação: a consulta é embedada, os chunks mais próximos são trazidos, re-ranqueados e filtrados por permissões. Geração: o modelo responde usando esses chunks e os cita.",
+        "A qualidade depende das partes pouco glamourosas: parsing limpo, chunking sensato, recuperação híbrida (vetor + palavras-chave), re-ranking e filtragem por permissões. Um conteúdo-fonte bem estruturado facilita cada um desses passos."
+      ],
+      "components": ["Ingestão e chunking", "Embeddings", "Índice vetorial / híbrido", "Recuperador e re-ranker", "Filtro de permissões", "Gerador (LLM)", "Camada de citações"],
+      "pros": [
+        "Respostas fundamentadas, citáveis e atualizadas.",
+        "Usa conhecimento privado sem retreinar.",
+        "Respeita o controle de acesso e a auditabilidade.",
+        "Mais barato e rápido de atualizar que o fine-tuning."
+      ],
+      "risks": [
+        "Um chunking ou recuperação ruins dão contexto errado ou irrelevante.",
+        "Dados desatualizados ou sem permissões vazam nas respostas.",
+        "As citações podem ser plausíveis mas não comprovadas se não forem verificadas.",
+        "Latência e custo de recuperação em escala."
+      ],
+      "tools": ["Bancos de dados vetoriais (ex.: pgvector, Pinecone, Vertex AI Vector Search)", "Modelos de embeddings", "Re-rankers", "Motores de busca híbrida", "Servidores de recursos MCP"],
+      "examples": [
+        "Um assistente interno que responde perguntas de políticas de RH com trechos citados.",
+        "Um agente de suporte que recupera documentação de produto para resolver chamados.",
+        "Um assistente jurídico que mostra cláusulas relevantes com links para a fonte."
+      ],
+      "faqs": [
+        { "q": "O RAG é melhor que o fine-tuning?", "a": "Resolvem problemas distintos. O RAG injeta conhecimento fresco e governado no momento da consulta; o fine-tuning adapta comportamento ou estilo. Muitas vezes são combinados." },
+        { "q": "Por que o chunking importa tanto?", "a": "A recuperação opera sobre chunks. Chunks autocontidos e bem estruturados são recuperados de forma limpa; os fragmentados retornam ruído. A qualidade do chunk define em grande parte a do RAG." },
+        { "q": "O que torna um RAG de nível empresarial?", "a": "Controle de acesso na recuperação, citações de fontes, auditabilidade, frescor e avaliação, não só um armazenamento vetorial mais um modelo." },
+        { "q": "Quando o RAG se torna agêntico?", "a": "Quando a recuperação é um passo de um laço de vários passos em que o sistema decide se, quando e o que recuperar, em vez de recuperar sempre uma vez." }
+      ]
+    }
+  }
+}