Практические заметки: Что такое генерация с использованием дополнительных данных (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.

Чек-лист операций

На этапе чек-листа операций определите входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг, исходя из известной точки контроля, без необходимости угадывать скрытое состояние системы.

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

Разделяйте процесс создания клиента от цикла обработки сообщений, чтобы можно было заменять поставщиков без переписывания автоматы состояния обмена сообщениями.

Оценивайте уровень воспроизводимости ответов на фиксированном наборе вопросов перед настройкой подсказок. Изменение подсказок редко помогает улучшить качество поиска.

Заморозьте эталонный набор данных до изменения подсказок или моделей. Изменение как самой системы, так и критериев оценки может скрыть появление сбоев.

При наличии бюджета добавляйте тесты на работоспособность, которые проверяют критические участки работы в рамках процесса CI с использованием фикстчеров, а не реальных платных API.

Перед внедрением стека заморозьте версии, сделайте копию «золотого» отчета для критической цепочки операций и уточните шаги возврата к предыдущему состоянию. В совместных средах необходимы ограничения на частоту запросов, проверки принадлежности пользователя и четко определенный ответственный за обновление секретов. Лучше выбирать надежность, чем креативные одноразовые демонстрации.

Примечание для ce641ce6bc02: не храните ключи поставщика в репозитории, установите лимит токенов на сессию и сохраняйте отчеты рядом с фиксами для оценки, чтобы последующие замены моделей оставались сопоставимыми.