Как создать готовый для корпоративного использования RAG-пайплайн на AWS с Bedrock, Zilliz Cloud и LangChain
Генерация с дополненным поиском (Retrieval-Augmented Generation, RAG) быстро стала основой корпоративных решений на базе LLM — почти 90% компаний полагаются на нее, чтобы дополнять LLM надежными, предметно-ориентированными знаниями. Но реальность сложнее: экосистема RAG взорвалась множеством вариантов. LLM, модели эмбеддингов, фреймворки оркестрации и векторные базы данных — у каждого есть собственные паттерны интеграции, из-за чего командам трудно собрать решения, которые работают в рамках корпоративных ограничений.
Для организаций, глубоко инвестировавших в AWS, эта проблема еще острее. Нельзя просто вырвать существующую инфраструктуру или обойти устоявшиеся политики безопасности и соответствия требованиям. Вам нужна архитектура RAG, которая бесшовно интегрируется с вашей средой AWS, использует сервисы, готовые для корпоративного применения, и остается устойчивой к будущим изменениям.
В этом руководстве мы пошагово создадим именно такую систему: готовый для корпоративного использования RAG-пайплайн с применением AWS Bedrock (модели Nova + Titan), Zilliz Cloud в качестве векторной базы данных и LangChain для оркестрации. К концу у вас будет практичная, безопасная и готовая к продакшену основа, которую можно развернуть напрямую в вашем AWS-стеке — без компромиссов и обходных решений.
Как мы проектируем RAG для масштабирования
Прежде чем перейти к коду, давайте разберемся, что мы создаем и почему это решает реальные корпоративные проблемы.
Традиционные LLM в корпоративной среде упираются в две серьезные стены. Их знания заканчиваются на моменте обучения — у них нет доступа к вашим последним отчетам, данным клиентов или отраслевым изменениям. Кроме того, они часто галлюцинируют, и нет способа проследить их рассуждения. Не совсем то, что хочется использовать в приложениях, ориентированных на клиентов.
RAG полностью меняет правила игры. Вместо переобучения огромных моделей вы сначала извлекаете релевантную информацию, а затем генерируете ответы на основе этого контекста. Преимущества проявляются сразу: точность выше на 25–40%, галлюцинаций меньше более чем на 60%, а ответы полностью трассируемы. Ваш ИИ внезапно знает о доходах за прошлый квартал и может ссылаться на источники.
Наша корпоративная RAG-система следует проверенному архитектурному шаблону MVC (Model-View-Controller):
Слой Model: Выполняет основную тяжелую работу — обработку документов, эмбеддинги, векторное хранение и инференс LLM
Слой View: Управляет пользовательскими интерфейсами и API-ответами
Слой Controller: Оркестрирует рабочий процесс через функции Lambda и обработку событий
Пять ключевых движков обеспечивают работу нашей реализации:
Движок обработки запросов: Преобразует вопросы пользователей в оптимизированные поисковые запросы
Движок векторного извлечения: Находит релевантный контент с помощью семантического поиска Zilliz Cloud
Модуль реранжирования: Расставляет результаты по приоритету с учетом релевантности и бизнес-правил
Движок генерации: Синтезирует контекст в точные ответы через AWS Bedrock
Событийно-ориентированная основа: Поддерживает слабую связанность компонентов через Amazon EventBridge
Технологический стек, который мы будем использовать
Создание корпоративного RAG — это не просто выбор «лучших» отдельных инструментов, а сборка технологий, которые бесшовно интегрируются в вашу экосистему AWS. В этом руководстве мы объединим AWS Lambda для вычислений, AWS Bedrock (модели Nova + Titan) для эмбеддингов и генерации, Zilliz Cloud для векторного поиска и LangChain для оркестрации.
AWS Lambda: эластичная вычислительная основа
Lambda дает нам serverless-основу: никаких серверов для управления, мгновенное масштабирование от нуля до тысяч запросов и тарификация за выполнение. Каждый этап RAG — обработка документов, векторизация, извлечение и генерация — выполняется как отдельная независимая функция Lambda. Такой дизайн делает систему модульной, отказоустойчивой и экономически эффективной.
AWS Bedrock: гибкий хаб моделей
Bedrock предоставляет доступ к более чем 50 бессерверным фундаментальным моделям (плюс более 120 вариантов на marketplace от Amazon, Anthropic, Meta и других). Его ключевая возможность? Замена моделей без изменения кода вашего приложения. Это означает, что вы можете проводить A/B-тесты, оптимизировать задержку относительно стоимости или внедрять новые модели без перестройки архитектуры.
Zilliz Cloud: Самая производительная корпоративная векторная база данных
Построенный на open-source Milvus, Zilliz Cloud устраняет необходимость гадать с настройкой индексов благодаря AutoIndex, который динамически адаптируется к вашим данным. Его поисковый движок Cardinal обеспечивает до 10 раз более высокую производительность по сравнению с традиционными векторными базами данных, при этом бесшовно масштабируясь до миллиардов векторов — что критически важно для развертываний корпоративного масштаба.
LangChain: Слой оркестрации
LangChain связывает всё воедино — управляет потоком между embedding, retrieval и generation. Благодаря интеграциям с AWS и гибким абстракциям он сохраняет нашу архитектуру чистой, модульной и готовой к production.
Когда наш стек готов, пора перейти к практике и начать сборку.
Начало работы по созданию enterprise-ready RAG на AWS
Настройка инфраструктуры AWS CDK
Мы будем использовать AWS CDK (Cloud Development Kit), чтобы определить весь ваш стек — Lambda-функции, API Gateway, S3-бакеты, CloudFront — и последовательно развертывать его в разных средах. CDK позволяет версионировать и проверять вашу инфраструктуру так же, как код приложения.
# Core Lambda function configuration
lambda_function = lambda_.Function(
self, "RAGQueryFunction",
runtime=lambda_.Runtime.PYTHON_3_9,
memory_size=3008,
timeout=Duration.seconds(30),
reserved_concurrency=100,
environment={
"ZILLIZ_ENDPOINT": self.zilliz_endpoint,
"BEDROCK_MODEL_ID": "amazon.nova-pro-v1:0"
}
)
Шаг CDK Bootstrap создает базовые ресурсы AWS: S3-бакеты для артефактов развертывания, IAM-роли для разрешений и SSM-параметры для конфигурации. Затем вы можете развертывать отдельные стеки для сред разработки, staging и production.
Подключение к Zilliz Cloud
Настройка Zilliz Cloud включает три шага: создать коллекцию, оптимизировать индексирование и установить подключения. Мы используем 1024-мерные векторы с индексированием HNSW для оптимального баланса между точностью поиска и скоростью.
# Zilliz connection configuration
connections.connect(
alias="default",
uri=ZILLIZ_ENDPOINT,
token=ZILLIZ_TOKEN,
timeout=30
)
# Create optimized collection
collection = Collection("rag_collection")
index_params = {
"metric_type": "IP",
"index_type": "HNSW",
"params": {"M": 16, "efConstruction": 128}
}
Используйте партиции, чтобы организовать данные по типу документа или бизнес-области для повышения производительности поиска при работе с большими коллекциями документов.
Оптимизация вашего процесса разработки
Makefile предоставляет унифицированные команды для установки зависимостей, запуска тестов, развертывания в разные среды и очистки ресурсов.
# Standardized development process
install: # Install dependencies
test: # Run tests
lint: # Code checking
deploy: # Deploy application
clean: # Clean environment
CI/CD-пайплайны выполняют проверки качества кода, валидацию типов и автоматизированное тестирование.
Создание ключевых функций
Пайплайн обработки документов
Пайплайн обрабатывает документы в четыре этапа: парсинг, очистка контента, интеллектуальное разбиение на фрагменты и извлечение метаданных.class DocumentProcessor:
class DocumentProcessor:
def process(self, document):
# Document Parsing
parsed_content = self.parse_document(document)
# Content cleaning and preprocessing
cleaned_text = self.clean_content(parsed_content)
# Intelligent chunking
chunks = self.chunk_text(cleaned_text,
chunk_size=1000,
overlap=100)
# Metadata extraction
metadata = self.extract_metadata(document)
return processed_chunks
Наша стратегия разбиения на фрагменты использует семантически осведомленную сегментацию, которая учитывает границы абзацев и сохраняет связанную информацию вместе. Размеры фрагментов автоматически адаптируются в зависимости от типа документа.
Векторизация и хранение
Titan Embeddings от AWS Bedrock обрабатывает документы пакетами для повышения эффективности. Кэширование векторов предотвращает повторное вычисление эмбеддингов для ранее обработанного контента.
class VectorProcessor:
def __init__(self):
self.embedding_model = TitanEmbeddings()
self.batch_size = 32
def vectorize_batch(self, texts):
# Batch vectorization
embeddings = self.embedding_model.embed_documents(texts)
# Vector normalization
normalized_embeddings = self.normalize_vectors(embeddings)
return normalized_embeddings
Многоуровневый подход к хранению сохраняет часто используемые векторы в высокоскоростном хранилище, а более старый контент архивирует в уровни, оптимизированные по стоимости.
Гибридная стратегия извлечения
Мы объединяем векторное сходство с сопоставлением по ключевым словам с помощью многоэтапного процесса: сначала широкий первичный поиск, затем точное ранжирование для получения лучших результатов.
class HybridRetriever:
def retrieve(self, query, top_k=10):
# Vector retrieval
vector_results = self.vector_search(query, top_k*2)
# Keyword retrieval
keyword_results = self.keyword_search(query, top_k*2)
# Result fusion
merged_results = self.merge_results(
vector_results, keyword_results
)
# Reranking
reranked_results = self.rerank(query, merged_results)
return reranked_results[:top_k]
Модели Cross-Encoder выполняют повторное ранжирование для определения наиболее релевантных результатов. Оптимизация контекстного окна гарантирует, что вы получите нужный объем информации для каждого запроса.
Интеграция LangChain
LangChain координирует процесс извлечения и генерации, используя проверенные шаблоны RAG из LangChain Hub.
from langchain.chains import RetrievalQA
from langchain.retrievers import VectorStoreRetriever
# Build RAG chain
qa_chain = RetrievalQA.from_chain_type(
llm=BedrockLLM(model_id="amazon.nova-pro-v1:0"),
chain_type="stuff",
retriever=ZillizRetriever(
collection=collection,
search_params={"top_k": 5}
),
return_source_documents=True
)
# Execute query
result = qa_chain.invoke({"query": user_question})
Управление памятью сохраняет контекст беседы для многоходовых обсуждений. Потоковые ответы отображают результаты в реальном времени вместо ожидания полного ответа. Обработка ошибок обеспечивает корректное восстановление при возникновении проблем.
Развертывание бессерверной архитектуры
Превосходный дизайн Lambda-функций
Каждая Lambda-функция следует принципам единственной ответственности, фокусируясь на конкретной бизнес-логике. Наши основные функции — обработка документов, векторизация, извлечение и генерация — развертываются и масштабируются независимо для максимальной гибкости.
# Query processing Lambda function
def lambda_handler(event, context):
try:
# Initialize connections (outside handler)
query = event['query']
# Vector retrieval
retriever = ZillizRetriever()
relevant_docs = retriever.search(query, top_k=5)
# LLM generation
llm = BedrockLLM()
response = llm.generate(query, relevant_docs)
return {
'statusCode': 200,
'body': json.dumps(response)
}
except Exception as e:
logger.error(f"Error: {str(e)}")
return error_response(e)
Выделение памяти варьируется в зависимости от ответственности функции: функции запросов получают 1 ГБ, функции обработки документов — 2 ГБ для оптимального баланса стоимости и производительности. Настройки тайм-аутов отражают операционные потребности: 30 секунд для запросов, 300 секунд для обработки документов.
Зарезервированная параллельность со 100 экземплярами для функций запросов устраняет влияние холодного старта на критически важные пользовательские операции.
Конфигурация API Gateway
API Gateway служит нашей единой точкой входа в систему, предоставляя RESTful-интерфейсы с комплексной маршрутизацией запросов. Безопасность и стабильность обеспечиваются тщательно настроенными политиками ограничения скорости, аутентификации и CORS.
# Конфигурация API Gateway
endpoints:
- path: /query
method: POST
integration: lambda
rate_limit: 1000/min
auth: IAM
- path: /documents
method: POST
integration: lambda
rate_limit: 100/min
auth: IAM
Интеллектуальное кэширование на уровне API Gateway снижает нагрузку на backend за счет стратегического кэширования результатов. Валидация запросов обеспечивает целостность входных параметров, защищая backend-системы от некорректных запросов.
Оптимизация CloudFront CDN
CloudFront обеспечивает глобальную доставку контента со сложным кэшированием статических ресурсов, значительно повышая скорость доступа пользователей по всему миру. Наша стратегия включает разделение динамического и статического контента, интеллектуальную маршрутизацию и оптимизацию кэширования на edge-узлах.
# Конфигурация кэша CloudFront
cache_behaviors = [
{
'path_pattern': '/api/*',
'ttl': 300, # Краткосрочный кэш ответов API
'headers': ['Authorization']
},
{
'path_pattern': '/static/*',
'ttl': 86400, # Долгосрочный кэш статических ресурсов
'compress': True
}
]
Оптимизация edge-локаций обеспечивает время отклика менее 100 миллисекунд для пользователей по всему миру благодаря стратегическому географическому распределению.
Оптимизация производительности
Стратегии снижения cold start
Cold starts представляют собой основную проблему serverless-архитектуры, которую мы решаем с помощью комплексного многоуровневого подхода к оптимизации. Механизмы прогрева на основе CloudWatch Events поддерживают готовность среды выполнения для критически важных функций.
# Конфигурация прогрева Lambda
def warm_up_handler(event, context):
if event.get('source') == 'aws.events':
return {'statusCode': 200, 'body': 'warmed up'}
# Обычная бизнес-логика
return business_logic(event, context)
Оптимизация зависимостей сокращает длительность cold start за счет минимизации размеров пакетов и выбора легковесных библиотек. Инициализация пула соединений в глобальной области устраняет накладные расходы на повторные соединения.
Provisioned Concurrency для критически важных функций полностью устраняет задержку cold start. Динамическая настройка экземпляров на основе бизнес-паттернов оптимизирует баланс производительности и затрат.
Интеллектуальная параллельная обработка
Наш многоуровневый контроль параллелизма применяет разные лимиты в зависимости от требований к ресурсам. Настройки параллелизма Lambda отражают характеристики функций: легковесные функции запросов поддерживают высокий параллелизм, тогда как ресурсоемкие функции обработки документов используют контролируемые лимиты для предотвращения конкуренции за ресурсы.
# Пример конфигурации параллелизма
functions_config:
query_function:
reserved_concurrency: 100
memory: 1024
document_processing:
reserved_concurrency: 10
memory: 2048
Асинхронная обработка через SQS и SNS обеспечивает развязку задач, предотвращая каскадные сбои синхронных вызовов. Оптимизация пакетной обработки объединяет похожие задачи для повышения эффективности использования ресурсов.
Многоуровневая архитектура кэширования
Наша трехуровневая система кэширования оптимизирована для различных шаблонов доступа:
Кэш L1 использует память функции Lambda (TTL 5 минут, емкость 100MB), кэш L2 использует кластер Redis (TTL 1 час, емкость 1GB), а кэш L3 использует хранилище S3 (TTL 1 день, неограниченная емкость).
class CacheManager:
def get(self, key):
# Запрос кэша L1
if key in self.memory_cache:
return self.memory_cache[key]
# Запрос кэша L2
value = self.redis_client.get(key)
if value:
self.memory_cache[key] = value
return value
# Запрос кэша L3
return self.s3_cache.get(key)
Прогнозный прогрев кэша использует исторические шаблоны запросов для проактивной загрузки данных. Интеллектуальная инвалидация кэша поддерживает согласованность данных с помощью стратегий активных обновлений и пассивного истечения срока действия.
Стратегическая оптимизация затрат
Тонкая настройка ресурсов обеспечивает оптимизацию оплаты по требованию. Динамическая корректировка ресурсов автоматически настраивает параметры памяти и тайм-аута Lambda на основе паттернов нагрузки в реальном времени.
Reserved Instances и Savings Plans для стабильных рабочих нагрузок обеспечивают экономию вычислительных затрат до 72%. Spot Instances обрабатывают некритичную пакетную обработку для дополнительного сокращения затрат.
# Cost optimization configuration
cost_optimization = {
'lambda_memory_optimization': True,
'auto_scaling': True,
'reserved_capacity': {
'query_functions': 50,
'processing_functions': 5
}
}
Комплексный мониторинг и эксплуатация
Мониторинг метрик производительности
Интеграция с CloudWatch обеспечивает полную видимость производительности по следующим критически важным метрикам:
Время ответа API поддерживается на уровне P50 < 1s, P95 < 3s, P99 < 5s, показатель успешности остается > 99.9%, для одновременных пользователей выполняется мониторинг в реальном времени, производительность извлечения векторов остается < 200ms, а время генерации LLM остается < 2s.
# Custom metrics sending
def send_metrics(metric_name, value, unit='Count'):
cloudwatch = boto3.client('cloudwatch')
cloudwatch.put_metric_data(
Namespace='RAG/System',
MetricData=[{
'MetricName': metric_name,
'Value': value,
'Unit': unit,
'Timestamp': datetime.utcnow()
}]
)
Анализ структурированных журналов
Структурированное логирование в формате JSON обеспечивает мощные возможности запросов и анализа. Комплексные журналы фиксируют идентификаторы запросов, временные метки, контекст пользователя, метрики производительности и подробную информацию об ошибках.
Проактивное управление сбоями
AWS X-Ray обеспечивает сквозную распределенную трассировку для быстрого выявления узких мест производительности. Автоматизированные системы оповещения отслеживают ключевые метрики с настраиваемыми порогами и многоканальными уведомлениями.
# Alert rule configuration
alerts = [
{
'metric': 'ResponseTime',
'threshold': 3000, # 3 seconds
'comparison': 'GreaterThanThreshold',
'action': 'sns_notification'
},
{
'metric': 'ErrorRate',
'threshold': 1, # 1%
'comparison': 'GreaterThanThreshold',
'action': 'auto_scaling'
}
]
Механизмы самовосстановления используют возможности автоматических повторных попыток Lambda и функциональность Dead Letter Queue (DLQ) для автономного восстановления после сбоев. Планирование мощностей использует исторические данные и прогнозы роста для проактивного масштабирования ресурсов.
От учебного руководства к продакшену: ваша RAG-система готова
Вы только что создали полноценную корпоративную RAG-систему, которая решает проблему интеграции, останавливающую большинство RAG-проектов. Это не очередная демонстрация на localhost — у вас есть готовая к продакшену инфраструктура, работающая на AWS, с обработкой документов, векторным хранилищем через Zilliz Cloud, гибридным поиском и генерацией LLM через модели Bedrock Nova.
Модульная архитектура позволяет сразу развертывать AI-функции, постепенно дорабатывая компоненты по мере изменения потребностей. Вы строите систему на проверенных корпоративных паттернах, которые масштабируются вместе с вашим бизнесом, а не на экспериментальных фреймворках, которые ломаются под нагрузкой.
Готовы развивать это дальше? Разверните систему с вашими реальными данными и посмотрите, на что она способна. Нам было бы интересно узнать о вашем опыте и внесенных изменениях.
Полный репозиторий кода: https://github.com/yincma/AWS-zilliz-RAG/tree/main
Читать далее
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.