Практичні поради: LlamaIndex RAG: Практичний посібник зі створення розумнішого ШІ
Покрокова інструкція з практичних нотаток: LlamaIndex RAG: Практичний посібник з створення розумнішого ШІ: контракти, перевірки та готові блоки коду для команд, які використовують цю схему.
Використовуйте цей документ як оновлену версію ідей з книги „LlamaIndex RAG: A Practical Guide to Building Smarter AI Applications“ для спеціалістів-операторів: чіткі етапи, впорядковані блоки коду та примітки щодо відновлення, які зберігаються під час передачі обов’язків. Етап Огляду найкраще функціонує, якщо його розглядати як вимірювану основу. Запишіть один ідеальний запис, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ.
Що саме таке 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 Pipeline необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, тестовані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Наводьте уривки тексту, які фактично лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем із індексуванням. Для етапу The LlamaIndex RAG Pipeline необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити разом із функціональними результатами. Чітке відображення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-режиму до спільного використання.
середовищ.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. Зберігання векторів
Етап 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 — це більше, ніж „пошук векторів + LLM“
Для етапу 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 для AI-застосунків
Для етапу 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