Урок 9.8. RAG frameworks для памяти: LangChain, LlamaIndex, Haystack

Цель лекции

Разобрать RAG frameworks как инструменты для world memory: LangChain, LlamaIndex и Haystack. Показать, где они помогают агентской памяти, а где не заменяют user memory, policies и lifecycle.

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

Читатель понимает, какие задачи закрывают RAG frameworks: ingestion, chunking, retrieval, reranking, citations, query transformation, agentic RAG and connectors. Он умеет отличать RAG pipeline от полноценной memory layer.

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

В content_plan.md RAG frameworks выделены отдельно от memory frameworks и agent frameworks. Это правильное разделение.

RAG framework отвечает на вопрос:

Как найти и подать модели релевантные внешние знания?

Memory layer отвечает на более широкий вопрос:

Как агент сохраняет, обновляет, извлекает и безопасно использует контекст во времени?

RAG является критически важной частью world memory, но он не решает все типы памяти.

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

RAG framework - это набор abstractions для работы с knowledge sources:

загрузить документы;
распарсить их;
разбить на chunks;
создать embeddings;
построить индексы;
выполнить retrieval;
сделать reranking;
вставить источники в prompt;
сгенерировать grounded answer;
вернуть citations.

Для агента это слой доступа к миру: документации, wiki, ticket systems, репозиториям, CRM, policy documents, research papers, logs and databases.

flowchart TD S[Sources] --> L[Loaders] L --> P[Parsers] P --> C[Chunking] C --> E[Embeddings] C --> K[Keyword index] E --> V[(Vector store)] K --> H[Hybrid retrieval] V --> H H --> RR[Reranking] RR --> CA[Context assembly] CA --> LLM[LLM answer with sources]

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

Термин	Короткое определение
`RAG`	Retrieval-Augmented Generation: поиск релевантных источников перед генерацией ответа.
`Loader`	Компонент, который загружает документы из файлов, веба, SaaS, databases or APIs.
`Parser`	Компонент, который извлекает текст и структуру из PDF, HTML, Markdown, code, tables.
`Chunking`	Разбиение документа на фрагменты, которые можно искать и вставлять в context.
`Retriever`	Интерфейс поиска документов или chunks по запросу.
`Reranker`	Второй этап ранжирования retrieved candidates.
`Citation`	Ссылка на источник, из которого взят ответ или claim.
`Agentic RAG`	Паттерн, где агент сам решает, когда искать, как переформулировать запрос и какие источники использовать.

LangChain: modular retrieval and agentic RAG

LangChain полезен как универсальный набор компонентов вокруг LLM applications:

document loaders;
text splitters;
embeddings;
vector stores;
retrievers;
tools;
agents;
structured output;
LangGraph integration;
tracing через LangSmith.

Для памяти важны две линии.

Первая: retrieval pipeline. LangChain позволяет собрать knowledge base из documents and structured data, затем подключить retriever к agent.

Вторая: agentic RAG. Агент может решать:

нужен ли retrieval;
какой query сформировать;
достаточно ли найденных документов;
нужно ли переписать запрос;
нужно ли искать в другом source;
можно ли ответить с citations.

Это важно для world memory, потому что не каждый вопрос требует поиска. Иногда memory retrieval добавит шум.

Пример:

User: "Какой стиль финального ответа предпочитает Иван?"
Need: user/project memory.

User: "Что в документации OpenSearch сказано про hybrid query?"
Need: RAG over external docs.

LangChain хорош там, где нужна гибкая композиция retrieval tools. Но он не должен быть единственным policy layer. Permissions, retention, user control and memory updates должны быть спроектированы отдельно.

LlamaIndex: data framework для knowledge-intensive agents

LlamaIndex часто удобен, когда центр задачи - данные и документы.

Его сильные стороны:

ingestion pipelines;
indexes;
retrievers;
query engines;
chat engines;
agent workflows;
vector store integrations;
document stores;
chat stores;
abstractions вокруг nodes and metadata.

Для agent memory LlamaIndex особенно полезен, когда нужно:

построить RAG поверх большого corpus;
хранить document nodes with metadata;
использовать chat store для истории диалога;
подключить vector stores;
делать source-aware query engines;
строить agents, которые вызывают data tools.

LlamaIndex ближе к data layer, чем к generic orchestration layer. Он помогает превратить documents into retrievable knowledge.

Но вопрос:

Стоит ли сохранить этот пользовательский факт в long-term profile?

не является чистой задачей LlamaIndex. Это memory write policy.

Haystack: pipelines and production RAG

Haystack полезен как pipeline-oriented framework для search and RAG systems.

Его сильные стороны:

explicit pipeline graph;
components for retrieval and generation;
document stores;
rankers;
readers/generators;
evaluation workflows;
production-oriented RAG structure.

Haystack хорошо ложится на задачи:

enterprise document search;
support knowledge assistant;
retrieval pipelines with clear stages;
experimentation with retrievers and rankers;
RAG evaluation.

Для memory architecture Haystack может быть world memory subsystem:

Memory layer
  -> asks RAG subsystem for source-grounded context
  -> receives documents with metadata
  -> applies permissions/freshness/context budget
  -> injects selected evidence into prompt

Сама по себе RAG pipeline не знает, что является user preference, reflection, procedural rule or shared team memory.

RAG frameworks vs dedicated memory frameworks

Вопрос	RAG framework	Dedicated memory framework
Основная задача	Достать внешние знания	Запоминать и извлекать agent/user memory
Тип данных	Documents, chunks, sources	Facts, preferences, episodes, summaries
Источник истины	External corpus	Conversation/app events/memory records
Сильная сторона	Grounding and citations	Personalization and continuity
Главный риск	Stale or unauthorized documents	Wrong/stale personal memory
Примеры	LangChain, LlamaIndex, Haystack	Mem0, Zep, Letta

На практике они часто работают вместе.

Где RAG становится частью памяти

RAG становится memory subsystem, когда он подключен к agent lifecycle:

flowchart LR O[Observation] --> Q[Need external knowledge?] Q -->|yes| RAG[RAG retrieval] Q -->|no| M[Internal memory retrieval] RAG --> F[Source filtering] M --> F F --> C[Context assembly] C --> A[Answer or action] A --> W[Optional memory write]

Пример coding agent:

RAG по документации framework;
search по репозиторию;
project memory про conventions;
episodic memory про прошлые failures.

Если пользователь спрашивает, как вызвать API, нужен RAG по docs. Если он спрашивает, какой стиль принят в проекте, нужна project/procedural memory.

Важные open-source компоненты вокруг RAG

RAG framework почти всегда работает вместе с infrastructure:

Слой	Примеры
Vector store	Qdrant, Chroma, Milvus, Weaviate, LanceDB, pgvector
Search engine	OpenSearch, Elasticsearch, PostgreSQL full-text, Tantivy
Graph retrieval	Neo4j, Graphiti, graph retrievers, metadata graph
Document parsing	Unstructured, Docling, MarkItDown, custom parsers
Reranking	Cross-encoders, Cohere/Jina/TEI-style rerankers, local rankers
Observability	traces, retrieval logs, eval dashboards

Важное правило: RAG quality часто определяется не framework, а качеством parsing, metadata, permissions, chunking and evaluation.

Chunking как memory design decision

Chunking кажется технической деталью, но для memory layer это design decision.

Плохой chunking приводит к:

потере source context;
смешиванию unrelated sections;
невозможности точной citation;
retrieval noise;
wrong grounding;
дублированию fragments.

Для Markdown lectures chunk может быть heading section. Для API docs - endpoint block. Для legal docs - clause. Для code - function/class/module. Для support tickets - issue, diagnosis, resolution.

Правильный chunk отвечает не на вопрос "сколько токенов?",
а на вопрос "какая единица смысла должна извлекаться целиком?"

Metadata важнее embeddings

Для agent memory metadata часто важнее similarity score.

Минимальные metadata для RAG-memory:

source id;
source URL/path;
document version;
timestamp;
author or owner;
tenant/project/user scope;
permissions;
freshness;
content type;
section heading;
deletion status.

Без metadata RAG framework может найти правильный текст, но memory layer не сможет понять, можно ли его использовать.

Agentic RAG: когда агент сам ищет

В agentic RAG retrieval становится tool.

Агент может:

решить, что информации не хватает;
вызвать search tool;
оценить найденные документы;
переформулировать query;
сделать второй поиск;
сравнить источники;
ответить с uncertainty.

Это полезно для research and troubleshooting. Но agentic RAG увеличивает latency and cost.

Для memory architecture это означает:

retrieval calls нужно trace;
queries нужно логировать;
source usage нужно объяснять;
repeated failed searches можно сохранять как episodic memory;
dangerous sources нужно фильтровать до prompt injection.

Мини-кейс: enterprise policy assistant

Задача: агент отвечает на вопросы сотрудников по внутренним политикам.

RAG subsystem:

загружает policy documents;
режет по sections;
индексирует vector + keyword;
возвращает top candidates;
дает citations.

Memory layer:

проверяет employee permissions;
учитывает регион и роль;
исключает устаревшие версии;
сохраняет feedback пользователя;
логирует, какие sources повлияли на ответ;
не превращает policy text в user memory.

Если RAG отвечает без permissions, система опасна. Если memory layer отвечает без citations, система недостоверна.

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

Research agent неделю работает над темой.

RAG хранит:

papers;
web pages;
reports;
notes;
citations.

Agent memory хранит:

что уже прочитано;
какие claims извлечены;
какие contradictions найдены;
какие questions остались открытыми;
какие sources признаны ненадежными.

Здесь RAG и memory дополняют друг друга. RAG отвечает "где текст?". Memory отвечает "что мы уже поняли и почему?".

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

Ошибка 1: считать RAG полноценной памятью агента.

RAG достает документы, но не управляет всеми видами памяти.

Ошибка 2: не хранить source attribution.

Без source answer выглядит уверенно, но его нельзя проверить.

Ошибка 3: индексировать документы без permissions.

Permission-aware retrieval должен быть встроен до context assembly.

Ошибка 4: выбирать chunk size наугад.

Chunk должен соответствовать смысловой структуре source.

Ошибка 5: не тестировать retrieval отдельно от generation.

Если retrieval плохой, LLM будет красиво отвечать на неправильном контексте.

Ошибка 6: игнорировать freshness.

Старая документация может быть хуже отсутствия документации.

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

LangChain retrieval: https://docs.langchain.com/oss/python/langchain/retrieval
LangChain retrievers: https://docs.langchain.com/oss/python/integrations/retrievers
LangGraph agentic RAG: https://docs.langchain.com/oss/python/langgraph/agentic-rag
LlamaIndex vector stores: https://docs.llamaindex.ai/en/v0.10.23/module_guides/storing/vector_stores/
LlamaIndex chat stores: https://docs.llamaindex.ai/en/v0.10.20/module_guides/storing/chat_stores.html
Haystack documentation: https://docs.haystack.de/

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

RAG frameworks - это основной инструмент для world memory: documents, code, docs, policies, wiki, tickets, research sources and citations.

Они закрывают ingestion, indexing, retrieval and grounding, но не заменяют memory lifecycle. User memory, project memory, procedural memory, reflection, deletion, permissions and audit требуют отдельного design.

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

Почему RAG framework не равен memory layer?
Чем LangChain-style retriever полезен для agentic RAG?
В каких сценариях LlamaIndex особенно удобен?
Почему chunking является архитектурным решением памяти?
Какие metadata обязательны для permission-aware RAG?

Что дальше

В следующей лекции мы разберем storage and search engines: vector databases, search engines, graph databases, KV/cache and local memory tools. Это инфраструктурный слой, на котором строятся и RAG, и memory frameworks.