Практичні нотатки: Я створив 16 систем RAG з нуля — ось що насправді

У цьому посібнику детально описано шлях від сировини до функціональної системи для проекту «Я створив 16 систем RAG з нуля — ось що справді працює». Основна увага приділяється конкретним крокам виконання, чітким перевіркам та коду, який можна просто додати до репозиторію, не намагаючись здогадатися про його призначення. На етапі огляду необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись зрозуміти прихований стан системи. Необхідно одночасно задокументувати шлях успішного виконання та шлях відновлення після проблем. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

Три проблеми, які мав вирішити RAG

Під час роботи над етапом The Three Problems RAG спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну функцію, а не на складну послідовність операцій. Перед налаштуванням запитів вимірюйте рівень відтворення інформації на фіксованому наборі запитань. Часта зміна формулювань запитів рідко допомагає покращити якість пошуку.

Without RAG:
  User: "What's our refund policy?"
  LLM:  "I believe you offer a 14-day return..." (guessing)

With RAG:
  User: "What's our refund policy?"
  → Step 1: Search internal docs → Finds: "Refunds within 30 days..."
  → Step 2: LLM reads the doc and answers accurately
  LLM:  "Your refund policy allows returns within 30 days..."

16 шаблонів RAG (розташовані за рівнем впливу у реальному світі)

Під час роботи над етапом «16 шаблонів RAG» спочатку запишіть угоду: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко виправляє проблеми з недостатньою ефективністю пошуку інформації.

РІВЕНЬ 1: Обов’язково знати

Під час роботи над етапом TIER 1 MUST KNOW спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли система переходить від демо-режиму до спільних середовищ. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити якість пошуку інформації.

Використовується майже в кожній продакшн-системі RAG

Під час роботи над проектом, який використовується майже на кожному етапі, спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Зміна підказок рідко вирішує проблеми слабкого пошуку інформації.

1. Стандартний RAG — основа

Під час роботи над етапом 1 Standard RAG спочатку запишіть умови виконання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Перед налаштуванням запитів вимірюйте рівень відтворення інформації на фіксованому наборі запитань. Зміна запитів рідко допомагає вирішити проблеми з недостатньою ефективністю пошуку.

# The core loop in ~10 lines
query_embedding = embed(user_query)
relevant_docs = vector_store.search(query_embedding, top_k=5)
context = "\n".join(relevant_docs)
prompt = f"Answer using this context:\n{context}\n\nQuestion: {user_query}"
answer = llm.generate(prompt)

2. Гібридний RAG — найбільший крок до покращення якості

Під час роботи над етапом 2 Hybrid RAG спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко вирішує проблеми слабкого пошуку інформації.

User: "React useState hook"
→ Semantic search finds: "state management in React components"
→ BM25 finds: docs with exact string "useState"
→ Hybrid (RRF fusion): gets the best of both

3. Контекстуальний пошук RAG — для реальних розмов

Під час роботи над 3-м етапом контекстуального пошуку RAG спочатку запишіть угоду: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко виправляє слабкі алгоритми пошуку.

User turn 1: "Tell me about the Premium plan"
User turn 2: "How much does it cost?"

Before search, rewrite → "How much does the Premium plan cost?"
Now retrieve → finds the pricing document ✓

РІВЕНЬ 2: КОМПЕТИТИВНА ПЕРЕВАГА

Під час роботи над етапом TIER 2 COMPETITIVE EDGE спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити якість пошуку.

Що відрізняє хороші системи від чудових

Під час роботи над етапом «Що відрізняє хороші системи» спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, бази зберігання секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Перед налаштуванням запитів вимірюйте рівень відтворення інформації на фіксованому наборі запитань. Зміна формулювань запитів рідко допомагає покращити якість пошуку.

4. Agentic RAG — найпопулярніша тенденція 2025–2026 років

Під час роботи над 4 етапами Agentic RAG спочатку запишіть умови виконання: необхідні дані вхіду, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Перед налаштуванням запитів вимірюйте рівень відтворення інформації на фіксованому наборі запитань. Зміна запитів рідко допомагає вирішити проблеми з недостатньою ефективністю пошуку.

User: "What was NVDA's stock return last quarter vs its historical average?"

Agentic RAG decides:
  → Use web_search tool for current stock data
  → Use calculator tool for return calculation
  → Use document_retrieval tool for historical reports
  → Synthesize all three into one answer

5. Self-RAG — Коли помилка є неприпустимою

Під час роботи над 5 етапом Self-RAG For When спочатку запишіть умови виконання: необхідні дані вхіду, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Перед налаштуванням запитів вимірюйте рівень відтворення інформації на фіксованому наборі запитань. Часта зміна формулювань запитів рідко допомагає покращити ефективність пошуку інформації.

6. HyDE RAG — Місток між словниковими запасами

Під час роботи над 6 етапами HyDE RAG спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви кожному елементу, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко вирішує проблеми слабкого пошуку інформації.

User: "Why do things fall down?"
→ LLM generates hypothesis: "Objects fall due to gravitational force..."
→ Search with the hypothesis (technical vocabulary)
→ Find the actual document about gravitational acceleration
→ Answer using the real document

РІВЕНЬ 3: СПЕЦІАЛІСТИ ВИСОКОГО РІВНЯ ВПЛИВУ

Під час роботи над етапом TIER 3 HIGH-IMPACT SPECIALISTS спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Вимірюйте рівень точності відповідей на фіксований набір запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити якість пошуку інформації.

Широко використовується у своїх галузях

Під час роботи над широко використовуваними на своїй стадії рішеннями спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Зміна підказок рідко вирішує проблеми слабкого пошуку даних.

7. Graph RAG — Для реляційного міркування

Під час роботи над 7-м етапом Graph RAG For запишіть спочатку контракт: необхідні вхідні дані, сигнал успіху та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Документуйте як шлях успішної роботи, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Зберігайте у кеші стабільні інструкції системи та схеми інструментів. Повторна передача ідентичних даних є поширеною причиною витрат ресурсів.

Text: "Dr. Chen collaborated with Dr. Patel on a 2022 study funded by NIH."

Graph nodes: Dr. Chen, Dr. Patel, 2022 study, NIH
Graph edges: COLLABORATED_WITH, FUNDED_BYQuery: "Who funded Dr. Chen's work?" → traverse: Chen → study → NIH

8. Memory-Augmented RAG — Ваш бот пам’ятає вас

Під час роботи над етапом 8 «Memory-Augmented RAG» спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко вирішує проблеми слабкого пошуку інформації.

user_profile = memory.get_user_facts(user_id)
recent_context = memory.get_recent_conversations(user_id, k=3)
answer = rag_with_context(query, user_profile, recent_context)
memory.update(user_id, query, answer)

9. Модульний RAG — замінюйте будь-яку частину без переписування

Під час роботи над 9-м етапом Modular RAG Swap спочатку запишіть угоду: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко вирішує проблеми слабкого пошуку інформації.

Standard RAG:   [fixed retriever] → [fixed reranker] → [fixed LLM]

Modular RAG:    [pluggable retriever] → [pluggable reranker] → [pluggable LLM]
                     ↑ swap anytime         ↑ swap anytime        ↑ swap anytime

10. RAG, спеціалізований для вашої галузі — створений під ваш бізнес

Під час роботи над етапом 10 «Специфічні для домену RAG Built», спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Відомі заздалегідь витрати запобігають несподіваним рахункам, коли система переходить від демо-режиму до спільних середовищ. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити ефективність пошуку інформації. Під час роботи над етапом 10 «Специфічні для домену RAG Built», спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте оптимальний та альтернативний шляхи виконання завдань. Повторні спроби, людський контроль та обробка невдалих запитів є частиною продукту, а не етапом подальшої оптимізації.

11. Покращений RAG — три джерела, одна відповідь

Модель 11 Enhanced RAG у трьох етапах працює найкраще, якщо її розглядати як вимірювану систему. Зберігайте один ідеальний запис, один випадок збою та примітку про скасування дій перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними сценаріями. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Розділяйте політику формування частин та політику пошуку інформації. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

Query: "Tell me about the Mars Exploration Program"

→ SQL: "Mars: 1.52 AU from sun, 687-day orbit"
→ Graph: Mars → explored_by → Curiosity Rover, Perseverance
→ Text: "Mars is the fourth planet... known as the Red Planet..."→ Fused Answer: Combines all three for comprehensive, expert-level response

12. Рекурсивний/багатокроковий RAG — для складних запитань

12-етапна рекурсивна багатокрокова процедура RAG працює найкраще, якщо її розглядати як вимірювану поверхню. Збережіть один ідеальний зразок результату, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику формування частин даних та політику їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

Round 1: Retrieve about transistors → learn about miniaturization
Round 2: Retrieve about integrated circuits → learn about computing power
Round 3: Retrieve about GPUs → learn about parallel processing
Round 4: Retrieve about deep learning → learn about compute requirements
Round 5: Synthesize the full chain into a coherent answer

РІВЕНЬ 4: СПЕЦІАЛІЗОВані сценарії використання

Етап SPECIALIZED USE рівня TIER 4 працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний зразок результату, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуальний контроль витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних. Розділяйте політику часткової обробки даних та політику їх отримання. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

Необхідні, коли вони потрібні

Інструмент Essential, який потрібен під час роботи на сцені, найкраще функціонує, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад виконання, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Розділяйте політику часткового оброблення даних та політику їх отримання. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

13. ODQA RAG — Відповідайте на все

13-й етап відповідей ODQA RAG працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу. Документуйте як успішний, так і відновлювальний сценарії разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Розділіть політику часткової обробки даних від політики їх пошуку. Зміна однієї не повинна змушувати переписувати іншу при зміні показників якості.

14. Багатомодальний RAG — текст, зображення та аудіо разом

Етап 14 Multi-Modal RAG Text працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування дій перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Розділяйте політику часткового оброблення даних та політику їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

User (text): "Show me the anatomy of the heart"
→ Retrieves both: text descriptions AND anatomical diagrams
→ Response includes both text explanation and relevant image

15. Streaming RAG — знання в реальному часі

Етап 15 Streaming RAG Real-Time працює найкраще, якщо його розглядати як вимірювану поверхню. Зафіксуйте один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику часткового оброблення даних від політики їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

Time 9:00 AM: "What's happening with NVDA?"
→ Retrieves this morning's earnings report

Time 11:30 AM (after news breaks): "What's happening with NVDA?"
→ Retrieves the breaking news from 11:15 AM

16. Federated RAG — приватність на першому місці, багатоджерельний підхід

16 етапів Federated RAG Privacy-First працюють найкраще, коли їх розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ. Розділіть політику часткового оброблення даних від політики їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу, коли змінюються показники якості. 16 етапів Federated RAG Privacy-First працюють найкраще, коли їх розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний сценарії роботи разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

Central Query: "What's the survival rate for treatment X?"

→ Hospital A retriever: returns relevant anonymized snippets
→ Hospital B retriever: returns relevant anonymized snippets
→ Hospital C retriever: returns relevant anonymized snippets
→ Central LLM synthesizes — never saw raw patient recordsResult: HIPAA/GDPR compliant, collaborative AI

Практичний план дій: що створювати місяць за місяцем

У рамках Практичного плану дій на кожному етапі необхідно визначити вхідні дані, відповідальну особу та критерії завершення роботи перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Якщо крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну структуру процесу. Необхідно цитувати ті частини тексту, які фактично лежать в основі відповіді. Без цитат оператори не зможуть відрізнити галюцинацію від проблем з індексуванням.

Month 1:  Standard RAG           ← Get something working
Month 2:  + Hybrid RAG            ← Biggest retrieval quality win
Month 3:  + Contextual Retrieval  ← Multi-turn conversations work now
Month 4:  + Self-RAG              ← Stop hallucinations
Month 5:  + Agentic capabilities  ← Tools beyond just search

This covers 80-90% of production RAG needs.

Поєднання типів RAG: практичні приклади

Для етапу «Реальний світ» типів комбінування RAG необхідно визначити вхідні дані, відповідального за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового завершення. Наводьте уривки тексту, які фактично лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинацію від проблем із індексуванням.

Швидкий посібник: виберіть свій RAG

Для швидкого ознайомлення: оберіть свою стадію, визначте вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не здогадуючись про прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні середовища. Наводьте цитати з тих частин тексту, які фактично лежать в основі відповіді. Без цитат оператори не можуть відрізнити галюцинації від проблем з індексуванням. Для швидкого ознайомлення: оберіть свою стадію, визначте вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не здогадуючись про прихований стан. Документуйте як успішний, так і відновлювальний сценарії роботи разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

.

Почніть працювати за 5 хвилин

Під час виконання етапу «Почніть працювати за 5 хвилин» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру обробки даних. Перед налаштуванням запитів вимірюйте рівень точності відповідей на фіксованому наборі запитань. Часта зміна формулювань запитів рідко допомагає покращити якість отримання інформації.

# Clone the repo
git clone https://github.com/Manjunadh86/RAG-Materials.git
cd RAG-Materials

# Install dependencies
pip install -r requirements.txt# Set your OpenAI API key
export OPENAI_API_KEY="sk-your-key-here"# Run your first RAG system
cd 01-Standard-RAG
python hands_on.py

Що далі

Під час роботи над етапом «Що далі» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень запам’ятовування на фіксованому наборі запитань перед налаштуванням промптів. Часта зміна промптів рідко виправляє слабкі алгоритми пошуку інформації.

Перелік операційних кроків

Етап переліку операційних кроків працює найкраще, коли його розглядають як вимірюваний показник. Збережіть один ідеальний запис виконання, один випадок невдачі та примітки щодо скасування змін перед розширенням обсягу роботи.

Тримайте конфігурацію окремо від коду програми. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь код.

Розділіть політику чанкування від політики отримання даних. Зміна однієї не повинна змушувати переписувати іншу, коли змінюються показники якості.

Додайте тест на працездатність, який буде перевіряти критичний шлях у процесі інтеграції з використанням фікстур, а не реальних платних API, коли це дозволяють бюджетні обмеження.

Описайте одночасно і оптимальний шлях виконання, і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

Розділіть політику чанкування від політики отримання даних. Зміна однієї не повинна змушувати переписувати іншу, коли змінюються показники якості.

Перед впровадженням всієї стек-технології заморозьте версії, зафіксуйте ідеальний запис дій для критичного шляху та підтвердьте кроки для відкату. У спільних середовищах необхідні обмеження на частоту запитів, перевірки прав доступу та чіткий власник для зміни секретних даних. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.

Примітка до пакету ba5dd76016c2: не включайте ключі постачальників у репозиторій, встановіть ліміт токенів на сеанс та зберігайте транскрипції поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.