Практические советы: LlamaIndex RAG: практическое руководство по созданию более умных ИИ-систем
Пошаговое руководство по использованию «Практических заметок: LlamaIndex RAG — практическое руководство по созданию более умных ИИ», включающее контракты, проверки и готовые блоки кода для команд, внедряющих эту технологию.
Используйте это как упрощённую версию идей из книги «LlamaIndex RAG: Практическое руководство по созданию более умных AI-приложений», ориентированную на операторов: чёткие этапы, структурированные блоки кода и записи о восстановлении, которые сохраняются при передаче задач. Этап обзора работает наилучшим образом, если рассматривать его как измеримую основу. Сначала соберите один идеальный пример работы, один случай сбоя и записи о возврате к предыдущему состоянию, прежде чем расширять объём работы. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Отображение затрат на раннем этапе помогает избежать неожиданных счётов при переходе от демо-версии к общедоступным средам.
Что же такое RAG?
На этапе «Что именно такое RAG» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Конфигурацию следует хранить отдельно от кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Указывайте те участки текста, которые легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
User
↓
Question
↓
LLM
↓
Answer
User Question
↓
Retrieval
↓
Relevant Documents
↓
LLM Prompt
↓
LLM
↓
Answer
Где находится LlamaIndex
На этапе определения места применения LlamaIndex необходимо заранее определить входные данные, ответственного за выполнение шага и критерии завершения перед внесением изменений в код. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Необходимо одновременно задокументировать успешный сценарий выполнения и сценарий восстановления. Повторные попытки, проверка человеком и обработка неработоспособных сообщений являются частью продукта, а не этапом последующей доработки. Указывайте те фрагменты текста, которые легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
Your Data
│
┌────────────┼────────────┐
↓ ↓ ↓
PDFs Websites Databases
│ │ │
└────────────┼────────────┘
↓
LlamaIndex
↓
Data Ingestion
↓
Chunks
↓
Embeddings
↓
Vector Store
↓
Retriever
↓
Reranker
↓
LLM
↓
Answer
Пайплайн RAG LlamaIndex
Для этапа пайплайна The LlamaIndex RAG необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Лучше использовать небольшие, тестируемые единицы кода вместо обширных скриптов. При сбое шага причина должна быть связана с конкретной областью ответственности, а не с запутанным пайплайном. Указывайте те фрагменты текста, на которых основан ответ. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации. Для этапа пайплайна The LlamaIndex RAG необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Записывайте время выполнения, а также стоимость токенов или запросов рядом с функциональными результатами. Отображение стоимости заранее предотвращает неожиданные счета при переходе от демо-режима к общему использованию.
среды.Documents
↓
Loading
↓
Parsing
↓
Chunking
↓
Indexing
↓
Retrieval
↓
Context Selection
↓
Generation
1. Загрузка ваших данных
При работе над этапом «Загрузка ваших данных» сначала запишите условия работы: необходимые входные данные, сигнал о успешности и действия при частичной неудаче. Такой список поможет избежать ошибок при последующих изменениях кода. Храните конфигурацию отдельно от кода приложения. Файлы с настройками среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Оцените уровень воспроизводимости ответов на фиксированный набор вопросов перед настройкой подсказок. Изменение подсказок редко помогает улучшить качество поиска.
PDFs
Markdown
Web pages
Notion
Google Drive
SQL databases
APIs
CSV files
documents = load_documents("data/")
Offline / ingestion time
↓
Prepare the knowledge
Online / query time
↓
Retrieve the knowledge
2. Разделение документов на части
При работе над этапом «Разделение документов на 2 части» сначала запишите условия контракта: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист поможет сохранять честность при последующих изменениях кода. Документируйте одновременно успешный и восстановительный сценарии работы. Повторные попытки, проверки человеком и обработка неработоспособных сообщений являются частью продукта, а не элементами последующей доработки. Измеряйте уровень воспроизведения ответов на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска.
Document
↓
Chapter
↓
Section
↓
Paragraph
↓
Chunk
chunks = split_document(
document,
chunk_size=512,
)
Huge chunk
↓
Lots of irrelevant information
↓
Large prompt
↓
Higher latency
Tiny chunk
↓
Missing context
↓
Poor retrieval
3. Создание эмбеддингов
При работе над тремя этапами создания вкладок сначала запишите условия использования: необходимые входные данные, сигнал о успешном выполнении и последствия частичной неудачи. Такой чек-лист поможет сохранять честность при последующих изменениях кода. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Если какой-то шаг не сработает, причина должна быть связана с конкретной функцией, а не с запутанной цепочкой операций. Оцените уровень воспроизводимости ответов на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска. При работе над тремя этапами создания вкладок сначала запишите условия использования: необходимые входные данные, сигнал о успешном выполнении и последствия частичной неудачи. Такой чек-лист поможет сохранять честность при последующих изменениях кода. Рядом с функциональными результатами записывайте время выполнения и стоимость в токенах или запросах. Отслеживание затрат с самого начала предотвращает неожиданные расходы при переходе с демо-среды в общедоступные среды.
"How can I reset my password?"
"What should I do if I forgot my login credentials?"
Text
↓
Embedding Model
↓
[0.12, -0.42, 0.81, ...]
4. Хранение векторов
Этот этап хранения векторов работает наилучшим образом, если рассматривать его как измеримую поверхность. Соберите один идеальный пример, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь граф. Разделяйте политику разбиения на части и политику поиска информации. Изменение одной из них не должно приводить к переписыванию другой при изменении показателей качества.
Document
↓
Chunk
↓
Embedding
↓
Vector Store
Vector Store
ID Vector Metadata
--------------------------------
001 [....] product=api
002 [....] product=web
003 [....] product=mobile
document_id
page_number
department
product
version
created_at
tenant_id
access_level
5. Получение релевантной информации
Этап «5. Получение релевантной информации» работает наилучшим образом, если рассматривать его как измеримую характеристику. Соберите один идеальный пример обработки, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Документируйте одновременно успешный и восстановительный сценарии работы. Повторные попытки, проверки человеком и обработка неработоспособных сообщений являются частью продукта, а не этапами последующей доработки. Разделяйте политику разбиения данных на части и политику поиска информации; изменение одной из них не должно приводить к переписыванию другой при изменении показателей качества.
Question
↓
Query Embedding
↓
Vector Search
Top 5 Results
1. API Authentication Guide
2. OAuth Configuration
3. API Token Documentation
4. Authentication Troubleshooting
5. Security Configuration
6. Преобразование полученных документов в контекст
Этап извлечения документов за 6 шагов работает наилучшим образом, если рассматривать его как измеримую единицу. Соберите один идеальный пример вывода, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Предпочитайте небольшие, тестируемые модули вместо обширных скриптов. Когда какой-либо шаг срабатывает некорректно, причина сбоя должна указывать на конкретный элемент ответственности, а не на запутанную цепочку операций. Разделяйте политику разбиения данных на части и политику их извлечения. Изменение одной из них не должно приводить к необходимости переписывания другой при изменении показателей качества. Этап извлечения документов за 6 шагов работает наилучшим образом, если рассматривать его как измеримую единицу. Соберите один идеальный пример вывода, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Записывайте время выполнения операций, а также стоимость токенов или запросов рядом с функциональными результатами. Отслеживание затрат на раннем этапе предотвращает неожиданные расходы при переходе с демо-среды в общедоступные среды.
User Question
+
Retrieved Context
↓
Prompt
↓
LLM
System:
Answer using the supplied context.
Context:
[Relevant document 1]
[Relevant document 2]
[Relevant document 3]
Question:
How do I configure API authentication?
7. Формирование ответа
На этапе 7 «Генерация ответа» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Конфигурацию следует хранить отдельно от кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Указывайте те участки текста, которые фактически легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
Question
+
Relevant Context
User
↓
Query
↓
Query Embedding
↓
Vector Retrieval
↓
Relevant Chunks
↓
Context Assembly
↓
LLM
↓
Answer
LlamaIndex — это не просто «поиск векторов + большая языковая модель»
На этапе LlamaIndex Is More Than необходимо заранее определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Необходимо одновременно задокументировать успешный сценарий выполнения и сценарий восстановления. Повторные попытки, проверка человеком и обработка неработоспособных сообщений являются частью продукта, а не этапом последующей доработки. При следующем шаге, представляющем собой код или вызов инструмента, следует отдавать предпочтение структурированным выводам с проверкой по схеме перед текстовыми описаниями в свободной форме.
Query
↓
Vector Search
↓
Top 5 Documents
↓
LLM
Query
↓
Query Processing
↓
┌─────────┴─────────┐
↓ ↓
Dense Search Keyword Search
↓ ↓
└─────────┬─────────┘
↓
Fusion
↓
Rerank
↓
Context Selection
↓
LLM
Механизмы поиска: преобразование процесса извлечения данных в систему ответов на вопросы
На этапе получения результатов поиска в движках запросов необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Лучше использовать небольшие, тестируемые единицы кода вместо обширных скриптов. При сбое шага он должен указывать на конкретную причину, а не на сложную структуру обработки данных. Указывайте те фрагменты текста, которые легли в основу ответа. Без цитат операторы не смогут отличить вымысел от проблем с индексацией. На этапе получения результатов поиска в движках запросов необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Отображение стоимости заранее предотвращает неожиданные счета при переходе от демо-режима к рабочему.
совместные среды.query_embedding = embed(query)
documents = search(query_embedding)
context = build_context(documents)
answer = llm.generate(
query=query,
context=context,
)
query_engine = index.as_query_engine()
response = query_engine.query(
"How does authentication work?"
)
Именно на этапе извлечения данных многие системы RAG терпят неудачу
При работе над этапом извлечения данных сначала запишите условия работы: необходимые входные данные, сигнал о успехе и что происходит при частичной неудаче. Такой список помогает избегать ошибок при последующих изменениях кода. Храните конфигурацию вне кода приложения. Файлы с настройками среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Оцените уровень воспроизведения информации на фиксированном наборе вопросов перед настройкой подсказок. Изменение подсказок редко помогает улучшить качество извлечения данных.
User Question
↓
Bad Retrieval
↓
Wrong Context
↓
LLM
↓
Bad Answer
Улучшение процесса извлечения данных с помощью метаданных
При работе над этапом «Улучшение поиска с использованием метаданных» сначала запишите описание функционала: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой чек-лист поможет сохранять честность при последующих изменениях кода. Документируйте одновременно успешный и восстановительный сценарии работы. Повторные попытки, проверка человеком и обработка неработоспособных сообщений являются частью продукта, а не элементами последующей доработки. Измеряйте показатель воспроизводимости на фиксированном наборе вопросов перед настройкой подсказок — частая смена подсказок редко помогает улучшить качество поиска.
Product A
Product B
Product C
product = Product B
version = 3
document_type = documentation
Entire Knowledge Base
↓
Metadata Filter
↓
Relevant Subset
↓
Semantic Search
Гибридный поиск может быть лучше, чем векторный поиск в одиночку
При работе над этапом «Hybrid Search Can Be» сначала запишите условия работы алгоритма: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист поможет сохранять честность последующих изменений в коде. Предпочитайте небольшие, тестируемые модули большим скриптам. Если какой-то шаг не сработает, причина должна быть связана с конкретной функцией, а не с запутанной цепочкой операций. Оцените уровень воспроизводимости результатов на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска. При работе над этапом «Hybrid Search Can Be» сначала запишите условия работы алгоритма: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист поможет сохранять честность последующих изменений в коде. Рядом с функциональными результатами записывайте время выполнения и стоимость в использовании токенов или запросов. Отслеживание затрат с самого начала предотвращает неожиданные расходы при переходе с демо-среды в общедоступные среды.
ERR_CONNECTION_RESET_502
Dense Retrieval
+
Sparse Retrieval
↓
Result Fusion
↓
Reranking
Переупорядочивание: тратить больше вычислительных ресурсов только на лучшие кандидаты
Этап переупорядочивания с акцентом на использование большего количества вычислительных ресурсов работает наилучшим образом, если его рассматривать как измеримую структуру. Соберите один идеальный пример работы, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Разделяйте политику разбиения данных на части и политику их поиска. Изменение одной из них не должно приводить к необходимости переписывания другой при изменении показателей качества.
Top 20 documents
Vector Search
↓
20 candidates
↓
Reranker
↓
Top 5
↓
LLM
Retriever
→ Find potentially relevant documents
Reranker
→ Determine which are actually relevant
LLM
→ Use those documents to answer
Контекст — это ограниченный ресурс
Подход «ограниченной сцены» работает наилучшим образом, когда его рассматривают как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Документируйте одновременно успешный и восстановительный пути выполнения. Повторные попытки, проверки человеком и обработка неработающих сообщений являются частью продукта, а не этапом последующей доработки. Разделяйте политику разбиения данных на части и политику их извлечения; изменение одной не должно принуждать к переписыванию другой при изменении показателей качества.
20 chunks
×
500 tokens
=
10,000 tokens
Retrieve 20
↓
Rerank
↓
Keep 5
↓
Compress
↓
Send 2,500 tokens
LlamaIndex RAG для PDF-файлов
Этап LlamaIndex RAG для PDF работает наилучшим образом, когда его рассматривают как измеримую среду. Перед расширением объёма работы необходимо зафиксировать один идеальный пример обработки, один случай сбоя и записку о возврате к предыдущему состоянию. Лучше использовать небольшие, тестируемые единицы вместо обширных скриптов. При сбое какого-либо шага причина должна быть связана с конкретной функцией, а не с запутанной цепочкой операций. Необходимо разделять политику разбиения данных на части и политику поиска информации. Изменение одной из них не должно вынуждать переписывать другую при изменении показателей качества. Этап LlamaIndex RAG для PDF работает наилучшим образом, когда его рассматривают как измеримую среду. Перед расширением объёма работы необходимо зафиксировать один идеальный пример обработки, один случай сбоя и записку о возврате к предыдущему состоянию. Рядом с функциональными результатами следует записывать время выполнения и стоимость обработки токенов или запросов. Отслеживание затрат на раннем этапе предотвращает неожиданные расходы при переходе с демо-среды в общедоступные среды.
PDF Files
↓
Document Loading
↓
Text Extraction
↓
Chunking
↓
Embeddings
↓
Vector Store
↓
Retriever
↓
LLM
Company Handbook
↓
Employee Documentation
↓
HR Policies
↓
Benefits
↓
Leave Policies
LlamaIndex RAG для ИИ-приложений
Для этапа LlamaIndex RAG for AI необходимо заранее определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Конфигурацию следует хранить отдельно от кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Указывайте те участки текста, на которых основан ответ. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
User
↓
RAG
↓
Answer
User
↓
Agent
↓
┌─────────┼─────────┐
↓ ↓ ↓
RAG Database API
↓ ↓ ↓
└─────────┼─────────┘
↓
LLM
↓
Answer
Задержка в RAG имеет значение
На этапе RAG Latency Matters необходимо заранее определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг, исходя из известной точки контроля, без необходимости угадывать скрытое состояние. Необходимо одновременно задокументировать успешный сценарий выполнения и сценарий восстановления. Повторные попытки, проверка человеком и обработка неработоспособных сообщений являются частью продукта, а не этапом последующей доработки. Указывайте конкретные фрагменты текста, на которых основан ответ. Без цитат операторы не смогут отличить галлюцинации от проблем с индексацией.
Query
↓
Embedding API
↓
Vector Database
↓
Reranker
↓
LLM
Получить меньше документов
На этапе «Получение меньшего количества документов» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Лучше использовать небольшие, тестируемые единицы кода вместо обширных скриптов. При сбое шага причина должна быть связана с конкретной функцией, а не с запутанной структурой обработки. Указывайте те части текста, которые легли в основу ответа. Без цитат операторы не смогут отличить вымысел от проблем с индексацией. На этапе «Получение меньшего количества документов» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Записывайте время выполнения, а также стоимость токенов или запросов рядом с функциональными результатами. Отображение стоимости заранее предотвращает неожиданные счета при переходе от демо-режима к общей среде.
Использование фильтров метаданных
На этапе использования фильтров метаданных сначала запишите условия работы: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист поможет сохранять честность при последующих изменениях кода. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Перед настройкой подсказок измерьте уровень воспроизведения ответов на фиксированном наборе вопросов. Частая смена подсказок редко помогает улучшить качество поиска.
Параллелизация независимых операций поиска
При работе над этапом параллелизации независимого поиска сначала запишите спецификацию: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист поможет сохранять честность при последующих изменениях кода. Документируйте одновременно успешный и восстановительный сценарии работы. Повторные попытки, проверки человеком и обработка неработоспособных сообщений являются частью продукта, а не элементами последующей доработки. Измеряйте показатель воспроизводимости на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска.
Dense ──────┐
├──→ Fusion
Sparse ─────┘
Dense
↓
Sparse
↓
Fusion
Уменьшить размер подсказок
При работе над этапом сокращения размера запроса сначала запишите контракт: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает сохранять честность последующих изменений в коде. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг терпит неудачу, она должна указывать на конкретную ответственность, а не на запутанную цепочку операций. Храните в кэше стабильные инструкции системы и схемы инструментов. Повторная отправка одинакового входного данных — частая причина избыточных затрат. При работе над этапом сокращения размера запроса сначала запишите контракт: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает сохранять честность последующих изменений в коде. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Отслеживание затрат на раннем этапе предотвращает неожиданные счета при переходе от демо-среды к общедоступным средам.
Стриминг ответа
Этап обработки ответов с использованием потока работает наилучшим образом, если рассматриваться как измеримая поверхность. Соберите один идеальный пример ответа, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объема работ. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Разделяйте политику разбиения данных на части и политику их извлечения. Изменение одной из них не должно приводить к необходимости переписывания другой при изменении показателей качества.
RAG — это не только точность
RAG будет работать наилучшим образом, если рассматривать его как измеримую поверхность. Соберите один идеальный пример обработки данных, один пример сбоя и запись о возврате к предыдущему состоянию перед расширением объёма работ. Документируйте одновременно успешный и восстановительный пути выполнения задач. Повторные попытки, проверки человеком и обработка неработающих сообщений являются частью продукта, а не этапом последующей доработки. Разделяйте политику разбиения данных на части и политику их поиска; изменение одной из них не должно приводить к переписыванию другой при изменении показателей качества.
RAG Quality
│
┌────────────┼────────────┐
↓ ↓ ↓
Retrieval Generation System
Quality Quality Performance
│ │ │
Recall Faithfulness Latency
Precision Relevance Cost
Ranking Completeness Reliability
Распространённые ошибки при создании RAG для LlamaIndex
Частые ошибки при создании этапных решений наилучшим образом удается избежать, если рассматривать их как измеримые элементы. Соберите один эталонный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объема работ. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг терпит неудачу, причина сбоя должна указывать на конкретную ответственность, а не на запутанную структуру обработки данных. Разделяйте политику разбиения на части и политику извлечения данных. Изменение одной из них не должно вынуждать переписывать другую при изменении показателей качества.
Ошибка 1: Рассматривание LLM как всей системы
Ошибка 1: Рассмотрение этапа как измеримой поверхности. Соберите один идеальный пример работы, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Рассматривайте этот этап как контракт между входными данными и проверенными результатами. Дайте названия создаваемым элементам, определите критерии успеха и не соглашайтесь на молчаливое частичное выполнение задач. Установите лимиты на количество токенов за один ход и за сессию. Инструменты агентов активно расширяют объем контекста; строгие ограничения предотвращают появление неожиданных счетов.
Ошибка 2: Использование огромных объемов данных
Ошибка 2: Работа с огромными объемами данных на этапе эффективнее всего при рассмотрении его как измеримой поверхности. Соберите один идеальный пример работы, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Записывайте время выполнения и стоимость токенов или запросов вместе с функциональными результатами. Отображение стоимости заранее предотвращает неожиданные счета при переходе от демо-версии к общим средам.
Ошибка 3: Получение слишком большого объема информации
Ошибка 4: Игнорирование метаданных
Ошибка 5: Пропуск оценки
Ошибка 6: Предположение, что векторный поиск достаточен
Архитектура LlamaIndex RAG, ориентированная на производство
User Query
│
▼
Query Processing
│
▼
Query Router
│
┌──────────────┴──────────────┐
│ │
Direct Answer Retrieval Needed
│
▼
Metadata Filtering
│
┌──────────────────┴──────────────────┐
▼ ▼
Dense Search Sparse Search
│ │
└──────────────────┬──────────────────┘
▼
Fusion
│
▼
Rerank
│
▼
Context Selection
│
▼
LLM
│
▼
Response
Начните с самой простой версии RAG
Documents
↓
Chunk
↓
Embed
↓
Vector Store
↓
Retrieve
↓
LLM
Add metadata
Add hybrid retrieval
Add reranking
Add context compression
Cache + parallelize + reduce retrieval
Настоящая мощность LlamaIndex
Documents
Databases
APIs
Knowledge Bases
Search Systems
Structured Data
Unstructured Data
LLM
AI Application
│
┌────────────────┼────────────────┐
↓ ↓ ↓
LLM Tools Data
│ │
└───────┬────────┘
↓
Retrieval
↓
Context
↓
LLM
Заключительные мысли
Data
↓
Ingestion
↓
Indexing
↓
Retrieval
↓
Context
↓
LLM
↓
Answer