Урок 9.10. Enterprise context platforms и connectors

Цель лекции

Разобрать инструменты и подходы, которые подключают агента к корпоративному контексту: documents, SaaS, databases, tickets, CRM, repositories, permissions and metadata graphs.

Ожидаемый результат

Читатель понимает, почему enterprise memory начинается не с vector DB, а с connectors, identity, permissions, document parsing, source metadata, freshness and audit. Он знает, где помогают open-source building blocks: MCP, LangChain loaders, LlamaIndex/LlamaHub, Unstructured, Docling, Apache Tika, Airbyte and custom connectors.

Зачем это нужно

Enterprise agent редко работает с одной базой знаний.

Он должен читать:

Google Drive, SharePoint, Box, Notion, Confluence;
Slack, Teams, email;
Jira, Linear, GitHub issues;
Salesforce, HubSpot, internal CRM;
data warehouse, PostgreSQL, BI dashboards;
PDF, DOCX, PPTX, spreadsheets;
внутренние policy documents;
репозитории и design artifacts.

Если все это просто выгрузить в один vector index, получится не memory layer, а источник leakage.

Enterprise context platform отвечает на вопрос:

Как дать агенту доступ к нужному контексту так,
чтобы он соблюдал права, freshness, audit and source boundaries?

Основная идея

Enterprise memory состоит из трех связанных слоев:

flowchart TD S[Enterprise sources] --> C[Connectors] C --> P[Parsing and normalization] P --> M[Metadata and permissions] M --> I[Indexing and context store] I --> R[Permission-aware retrieval] R --> A[Agent context assembly] A --> AU[Audit and user controls]

Connectors достают данные. Parsing превращает их в usable units. Metadata сохраняет source, owner, permissions and freshness. Retrieval обязан учитывать identity. Audit показывает, что именно было использовано.

Ключевые термины

Термин	Короткое определение
`Connector`	Компонент, который подключается к external source and retrieves data.
`Context platform`	Слой, который объединяет connectors, permissions, metadata, retrieval and audit.
`Source of truth`	Система, где данные считаются authoritative: CRM, repo, policy store, ticket system.
`Permission-aware retrieval`	Retrieval, который фильтрует candidates по правам пользователя and agent.
`Metadata graph`	Граф источников, документов, людей, команд, проектов and permissions.
`Incremental sync`	Обновление только изменившихся данных.
`Access revocation`	Удаление доступа после смены роли, удаления документа or policy update.
`Data lineage`	Путь от source до memory item and answer.

MCP как открытый стандарт подключения контекста

Model Context Protocol, или MCP, - open-source standard для подключения AI applications к external systems.

MCP servers могут предоставлять три основных типа возможностей:

resources: данные и контекст;
tools: действия and API calls;
prompts: reusable interaction templates.

Для memory architecture MCP важен как standardized connector layer.

Пример:

Agent runtime
  -> MCP client
    -> GitHub MCP server
    -> Google Drive MCP server
    -> PostgreSQL MCP server
    -> Internal policy MCP server

Но MCP сам по себе не решает enterprise governance полностью. Его нужно сочетать с:

identity and authorization;
allowlists;
human approval for risky tools;
audit logs;
data classification;
retrieval policies.

MCP дает общий протокол подключения. Memory layer определяет, что делать с полученным context.

LangChain document loaders

LangChain document loaders дают standard interface для чтения данных из разных sources в формат Document.

Они полезны, когда нужно быстро подключить:

web pages;
PDFs;
Google Drive;
SharePoint;
Notion;
Slack exports;
GitHub files;
CSV/JSON/HTML;
cloud storage.

Для enterprise memory loaders являются ingestion edge.

Но loader - это не governance layer. После загрузки нужно добавить:

source id;
document version;
owner;
tenant;
permissions;
created/updated timestamps;
deletion status;
classification labels.

Если loader потерял metadata, downstream retrieval уже не сможет безопасно фильтровать context.

LlamaIndex and LlamaHub

LlamaIndex ecosystem полезен, когда основная задача - data ingestion and query over knowledge sources.

Connectors помогают приводить sources к node/document representation, после чего можно строить indexes, retrievers and query engines.

Сильная сторона для enterprise:

много integrations;
document/node abstraction;
metadata-aware retrieval;
data-centric RAG workflows;
query engines over structured and unstructured data.

Ограничение то же: enterprise memory не заканчивается на ingestion. Нужны identity, access control and audit.

Unstructured, Docling and Apache Tika

Корпоративные данные часто живут в документах, которые плохо превращаются в plain text:

PDF with tables;
scanned documents;
PowerPoint;
Word;
spreadsheets;
HTML;
email attachments;
images;
reports with headers/footers;
multi-column layouts.

Document parsing становится критическим quality gate.

Инструмент	Где полезен
Unstructured	Open-source prototyping для partitioning documents into elements and metadata.
Docling	Open-source parsing diverse formats into unified document representation, Markdown/JSON/chunks.
Apache Tika	Mature open-source toolkit для detecting and extracting text/metadata from many file types.
PyMuPDF/PDFPlumber	Low-level PDF extraction for custom pipelines.

Parsing quality напрямую влияет на memory quality. Если таблица распарсилась неправильно, retrieval может найти текст, но ответ будет неверным.

Airbyte and data connectors

Airbyte - open-source data replication platform with many connectors. В контексте agents он полезен как слой доступа к business data and data sync.

Возможные роли:

sync SaaS data into warehouse/lake/database;
provide connector catalog;
expose data through APIs or MCP-style interfaces;
keep source metadata and update cadence.

Для memory layer Airbyte-like подход полезен, когда sources много и нужно не писать каждый connector manually.

Но replication имеет риск:

Если replicated copy не учитывает source permissions,
agent index может стать шире, чем разрешенный доступ пользователя.

Поэтому source permissions and revocation должны быть частью design.

Enterprise permissions: главный слой

В enterprise retrieval главный вопрос:

Не "нашли ли мы правильный документ?",
а "имел ли этот user and agent право его использовать?"

Permission-aware retrieval требует:

user identity;
group membership;
tenant/project scope;
document ACL;
source-level authorization;
role-based or attribute-based policies;
time-based validity;
revocation propagation;
audit.

flowchart LR Q[Query] --> ID[Resolve identity] ID --> SRC[Allowed sources] SRC --> RET[Retrieve candidates] RET --> ACL[Apply ACL filters] ACL --> F[Freshness and classification filters] F --> C[Context assembly]

Нельзя сначала сделать global retrieval, а потом надеяться, что LLM "не раскроет лишнее". Фильтрация должна происходить до prompt.

Metadata graph

Enterprise context часто графовый:

Person -> belongs_to -> Team
Team -> owns -> Service
Service -> documented_in -> Runbook
Runbook -> updated_by -> Engineer
Incident -> affects -> Customer
Customer -> has_contract -> Region

Metadata graph помогает:

ограничивать retrieval by ownership;
искать dependencies;
объяснять provenance;
строить impact analysis;
обнаруживать stale docs;
связывать tickets, docs, services and people.

Graph не обязан быть отдельной graph database с первого дня. Иногда достаточно relational schema with links. Но мыслить в graph terms полезно.

Freshness and incremental sync

Корпоративная память быстро устаревает.

Нужно отслеживать:

source updated time;
index updated time;
document version;
deleted or archived status;
permission changes;
stale index lag;
failed sync jobs.

Пример failure:

Policy document был обновлен в SharePoint.
Indexing job упала.
Agent продолжил отвечать по старой версии.

Observability должна показывать source_updated_at and indexed_at, а context assembly должен предпочитать свежую authoritative source.

Source attribution and audit

Enterprise answer должен быть explainable:

какие sources использованы;
какие chunks были injected;
какие permissions применены;
какая версия документа;
кто запросил;
какой agent ответил;
какой model/version использовался;
какие tool calls были выполнены.

Audit нужен не только для compliance. Он помогает debugging and trust.

Если пользователь говорит "ответ неправильный", команда должна найти exact source path.

Типовая архитектура enterprise context layer

Connectors:
  Google Drive, SharePoint, Jira, GitHub, CRM, DB

Parsing:
  Docling / Unstructured / Tika / custom parsers

Normalization:
  Document nodes, chunks, metadata, source ids

Permissions:
  IAM/SSO groups, ACL mapping, tenant filters

Indexes:
  Search engine, vector DB, graph/metadata store

Runtime:
  Permission-aware retrieval, reranking, context assembly

Controls:
  Audit, deletion, retention, monitoring, user feedback

Это сложнее, чем "RAG over docs", но именно здесь проходит граница production enterprise memory.

Мини-кейс: support agent

Support agent должен ответить customer success manager:

"Почему у клиента ACME снова ошибка экспорта?"

Нужный context:

ACME account from CRM;
current plan and entitlements;
past tickets;
known incidents;
product docs;
recent deployment notes.

Запрещенный context:

tickets других customers;
internal security notes без допуска;
старые docs до migration;
private sales notes.

Архитектура:

CRM connector + helpdesk connector + docs parser
-> tenant metadata
-> hybrid retrieval
-> ACL filters
-> source citations
-> answer trace

Мини-кейс: coding enterprise agent

Agent помогает разработчику в монорепозитории.

Sources:

repo files;
ownership map;
CI logs;
architecture docs;
incident tickets;
internal wiki;
secrets policy.

Memory risks:

использовать старую architecture note;
раскрыть security runbook не той команде;
применить convention из другого service;
сохранить secret from logs.

Нужны:

repo as source of truth;
code search;
docs RAG;
ownership metadata;
permission-aware retrieval;
secret filtering;
audit of tool calls.

Типичные ошибки

Ошибка 1: индексировать все документы в один глобальный vector DB.

Так быстро появляется cross-team and cross-tenant leakage.

Ошибка 2: терять source metadata at ingestion.

Без source, version and owner невозможно безопасно использовать context.

Ошибка 3: не учитывать access revocation.

Если сотрудник потерял доступ к документу, agent retrieval должен измениться.

Ошибка 4: считать parser технической мелочью.

Плохой parsing ломает chunks, citations and answers.

Ошибка 5: не разделять source of truth and memory cache.

Memory index может ускорять доступ, но authoritative facts часто живут в CRM, IAM, repo or policy store.

Ошибка 6: не проверять connectors на incremental sync failures.

Сломанный sync создает stale memory.

Источники для дальнейшего чтения

MCP introduction: https://modelcontextprotocol.io/docs/getting-started/intro
MCP server primitives: https://modelcontextprotocol.io/specification/2025-06-18/server/index
MCP resources: https://modelcontextprotocol.io/specification/2025-06-18/server/resources
MCP tools: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
LangChain document loaders: https://docs.langchain.com/oss/python/integrations/document_loaders/index
Unstructured open-source overview: https://docs.unstructured.io/open-source/introduction/overview
Docling docs: https://docling-project.github.io/docling/
Apache Tika project info: https://tika.apache.org/project-info.html
Airbyte docs: https://docs.airbyte.com/

Краткое резюме

Enterprise context platforms and connectors связывают агента с реальными источниками организации. Их задача - не просто загрузить документы, а сохранить permissions, metadata, freshness, source attribution and audit.

Главная мысль: enterprise memory должна уважать source systems. Если agent index обходить IAM, ACL and retention, он становится риском, даже если retrieval quality высокая.

Вопросы для самопроверки

Почему connector не равен enterprise context platform?
Какие metadata нельзя терять при ingestion?
Почему permission-aware retrieval должен происходить до prompt?
Чем MCP полезен как слой подключения контекста?
Как parsing quality влияет на memory quality?

Что дальше

В следующем модуле мы применим инструменты и паттерны к практическим сценариям: personal assistant, coding agent, enterprise knowledge agent and multi-agent system.