Практичні нотатки: Що таке генерація з підтримкою пошуку даних (RAG)? Практичний підхід
Покрокове керівництво з практичних нотаток: Що таке Retrieval-Augmented Generation (RAG)? Практичні поради щодо контрактів, перевірок та готових блоків коду для команд, які використовують цю модель.
Наступні примітки описують практичний підхід до вивчення книги „Що таке генерація з підтримкою пошуку (RAG)? Практичний посібник з прикладами на Python — Geeky Codes“. Основна увага приділяється контрактам, перевіркам та шаблонам коду, а не мотиваційному опису.
Дізнайтеся, як працює RAG, чому ШІ створюють халюцинації, та створіть свою першу систему генерації з підтримкою пошуку на Python.
Під час вивчення принципів роботи RAG спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та наслідки часткової невдачі. Такий перелік допоможе зберегти чесність у подальших змінах коду. Зберігайте конфігурацію окремо від коду програми. Файли середовища, сховища конфіденційних даних та флаги функціоналу мають знаходитися в одному місці, яке оператори можуть перевіряти, не читаючи весь код. Логуйте ідентифікатор запиту, ідентифікатор моделі та час виконання кожного запиту. Без цих записів періодичні помилки постачальника можуть здаватися багами програми.
Отримання даних
Під час роботи над етапом отримання даних спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Записуйте ідентифікатор запиту, ідентифікатор моделі та час відгуку після кожного виклику. Без цих записів періодичні помилки постачальника виглядають як баги програмного забезпечення.
Розширена версія
Під час роботи на етапі розширення спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Записуйте ідентифікатор запиту, ідентифікатор моделі та час відгуку після кожного виклику. Без цих даних періодичні помилки постачальника виглядають як баги програми.
Генерація
Під час роботи на етапі генерації спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви кожному елементу, визначте критерії успіху та не допускайте безпроблемного часткового виконання завдань. Записуйте ідентифікатор запиту, ідентифікатор моделі та час виконання кожного запиту. Без цих записів періодичні помилки постачальника можуть здаватися багами програми.
Documents
│
▼
Data Ingestion
│
▼
Text Extraction
│
▼
Chunking
│
▼
Embedding Model
│
▼
Vector Database
──────────────────────────────────────────
User Question
│
▼
Query Embedding
│
▼
Similarity Search
│
▼
Top-K Relevant Chunks
│
▼
Prompt Builder
│
▼
Large Language Model
│
▼
Final Answer
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
documents = [
"Employees receive 20 days of paid leave every year.",
"Annual bonuses are paid in December.",
"Health insurance covers hospitalization expenses."
]
model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode(documents)
index = faiss.IndexFlatL2(embeddings.shape[1])
index.add(np.array(embeddings).astype("float32"))
query = "How many leave days do employees receive?"
query_embedding = model.encode([query])
D, I = index.search(
np.array(query_embedding).astype("float32"),
k=1
)
print(documents[I[0][0]])
Поширені проблеми у продакшні
Під час роботи над етапом «Загальні виклики у продакшені» спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із результатами функціонування. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Фіксуйте ідентифікатор запиту, ідентифікатор моделі та час затримки при кожному виклику. Без цих записів періодичні помилки постачальника виглядають як баги програмного забезпечення. Під час роботи над етапом «Загальні виклики у продакшені» спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте оптимальний та резервний сценарії функціонування. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.
Ключові висновки
Етап «Ключові висновки» працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітку щодо скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Закріпіть інтерпретатор та файл блокування залежностей перед тим, як пояснювати принцип циклів. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв під час демонстрацій API.
Посилання
Етап посилань працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Закріпіть інтерпретатор та файл з параметрами залежностей перед тим, як пояснювати принцип роботи циклу. Відхилення між ноутбуком та системою CI є найпоширенішою причиною мовчазних збоїв під час демонстрацій API.
Чек-лист експлуатації
Для етапу чек-листу експлуатації необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення роботи перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан системи.
Зберігайте конфігурацію поза кодом додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код.
Розділіть створення клієнта від циклу обробки повідомлень, щоб можна було змінювати постачальників без переписування автомату стану розмови.
Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Зміна підказок рідко вирішує проблеми слабкого пошуку даних.
Заморозьте «золотий набір» даних перед зміною підказок чи моделей. Зміна як самої системи, так і критеріїв оцінки приховує можливі збої.
Коли дозволяє бюджет, додайте тест на працездатність, який перевіряє критичний шлях у процесі інтеграції за допомогою фікстур, а не реальних платних API.
Перш ніж запускати стек у продакшн, заморозьте версії, створіть «золотий» запис для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження швидкості, перевірки прав на використання та чіткий власник для зміни секретів. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.
Примітка для ce641ce6bc02: не включайте ключі постачальника до репозиторію, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.