Практические заметки: RAG, Embeddings и векторные базы данных — объяснено с нуля
Пошаговое руководство по практическим заметкам: RAG, Embeddings и векторные базы данных — объяснено с нуля: контракты, проверки и готовые блоки кода для команд, использующих эту модель.
Используйте это как переработанную версию идей из статьи «RAG, Embeddings, and Vector Databases — Explained From Scratch», ориентированную на операторов: четкие этапы, упорядоченные блоки кода и записи для восстановления, которые сохраняются при передаче задач. Этап обзора работает лучше всего, если рассматривать его как измеримую основу. Соберите один идеальный пример работы, один случай сбоя и записи по возврату к предыдущему состоянию перед расширением объема работ. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг терпит неудачу, причина сбоя должна указывать на конкретную ответственность, а не на запутанную цепочку операций.
Что такое RAG?
На этапе «Что такое RAG» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Рассматривайте этот этап как контракт между входными данными и проверенными результатами. Укажите названия элементов, определите критерии успеха и не допускайте молчаливого частичного завершения работы. Цитируйте те фрагменты, которые фактически легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
[ Documents ] --> [ Chunk ] --> [ Embed ] --> [ Store in Vector DB ]
|
User Question --> [ Embed Question ] --> [ Find Similar Chunks ] --> [ LLM ] --> Answer
Что такое эмбеддинг?
На этапе «Что такое эмбеддинг» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Рядом с функциональными результатами следует записывать время выполнения и стоимость токенов или запросов. Отображение стоимости заранее предотвращает неожиданные счета при переходе с демо-среды в общедоступные среды. Указывайте те фрагменты текста, которые легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
"king" → [0.21, -0.05, 0.87, ..., 0.33] (384 numbers)
"queen" → [0.19, -0.03, 0.85, ..., 0.31] (384 numbers)
"banana" → [-0.72, 0.44, 0.01, ..., -0.56] (384 numbers)
Как текст превращается в числа
На этапе «Как текст превращается в числа» необходимо определить входные данные, ответственного за шаг и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, которое операторы могут проверять, не читая весь код. Указывайте те участки текста, которые фактически легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации. На этапе «Как текст превращается в числа» необходимо определить входные данные, ответственного за шаг и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Предпочитайте небольшие, тестируемые единицы кода большим, запутанным скриптам. Когда шаг терпит неудачу, причина должна указывать на конкретную ответственность, а не на запутанную структуру.
Пайплайн.
Шаг 1: Токенизация
При работе над этапом токенизации сначала запишите контракт: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой чек-лист поможет избежать ошибок при последующих изменениях кода. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия создаваемым элементам, определите критерии успешности и не допускайте безусловного частичного завершения работы. Храните в кэше стабильные системные инструкции и схемы инструментов. Пересылка одинаковых данных несколько раз — частая причина ресурсозатрат.
"backend engineer jobs in bangalore"
Tokens: ["backend", "engineer", "jobs", "in", "bang", "##alore"]
Шаг 2: Слои трансформера
При работе над этапом слоев Transformer на втором шаге сначала запишите условия работы: необходимые входные данные, сигнал о успешном выполнении и что происходит при частичной неудаче. Такой список помогает сохранять честность при последующих изменениях кода. Рядом с функциональными результатами записывайте время выполнения и стоимость обработки токенов или запросов. Отслеживание затрат с самого начала предотвращает неожиданные расходы при переходе с демо-среды в общедоступные среды. Перед настройкой подсказок измерьте уровень воспроизведения ответов на фиксированном наборе вопросов. Частая смена подсказок редко помогает улучшить качество поиска.
"backend" → [0.52, -0.18, 0.83, 0.45, ...] (384 numbers)
"engineer" → [0.48, -0.15, 0.79, 0.41, ...] (384 numbers)
"jobs" → [0.31, -0.05, 0.67, 0.22, ...] (384 numbers)
"in" → [0.07, 0.02, 0.11, 0.04, ...] (384 numbers)
"bang" → [0.39, 0.27, 0.55, 0.30, ...] (384 numbers)
"##alore" → [0.14, 0.10, 0.21, 0.11, ...] (384 numbers)
Шаг 3: Объединение результатов
При работе над этапом объединения данных из Шага 3 сначала запишите условия работы системы: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список поможет сохранять честность последующих изменений в коде. Храните конфигурацию отдельно от кода приложения. Файлы с настройками, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Оцените уровень точности постоянного набора вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска. При работе над этапом объединения данных из Шага 3 сначала запишите условия работы системы: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список поможет сохранять честность последующих изменений в коде. Всегда предпочитайте небольшие, тестируемые единицы кода крупным скриптам. Если какой-то шаг не сработает, причина должна быть связана с конкретной функцией, а не с запутанной цепочкой операций.
Dimension 1: (0.52 + 0.48 + 0.31 + 0.07 + 0.39 + 0.14) / 6 = 0.318
Dimension 2: (-0.18 + -0.15 + -0.05 + 0.02 + 0.27 + 0.10) / 6 = 0.002
... same for all 384 dimensions ...
Final: [0.318, 0.002, ...] ← ONE vector for the entire sentence
Краткое уточнение: векторы против размерностей
Краткое уточнение относительно векторов и размерностей наиболее эффективно при рассмотрении их как измеримой поверхности. Соберите один образец успешного результата, один пример сбоя и запись о возврате к предыдущему состоянию перед расширением объёма работы. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия создаваемым элементам, определите критерии успеха и не соглашайтесь на молчаливое частичное выполнение задачи. Разделяйте политику разбиения данных на части и политику их извлечения. Изменение одной из них не должно приводить к переписыванию другой при изменении показателей качества.
2D point (on a map): [x, y] → 1 vector, 2 dimensions
3D point (in a room): [x, y, z] → 1 vector, 3 dimensions
Embedding: [n1, n2, ..n384] → 1 vector, 384 dimensions
Что такое база данных векторов?
Этап «Что такое вектор» работает наилучшим образом, если рассматривать его как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объёма работ. Записывайте временные показатели, а также стоимость токенов или запросов рядом с функциональными результатами. Отслеживание затрат на раннем этапе предотвращает неожиданные счёты при переходе от демо-среды к общедоступным средам. Разделяйте политику разбиения данных на части и политику их поиска. Изменение одной из них не должно приводить к необходимости переписывания другой при изменении показателей качества.
┌──────────────────────────────────────────────────┐
│ Vector DB │
│ │
│ Entry 1: │
│ text: "Senior Backend Engineer Wipro..." │
│ vector: [0.21, -0.05, 0.87, ...] │
│ │
│ Entry 2: │
│ text: "Frontend dev needed Chennai..." │
│ vector: [0.71, 0.55, -0.30, ...] │
│ │
│ Entry 3: │
│ text: "Backend Engineer Flipkart..." │
│ vector: [0.19, -0.03, 0.85, ...] │
│ │
└──────────────────────────────────────────────────┘
Сколько векторов сохраняется?
Этап «Сколько векторов получено» работает наилучшим образом, когда его рассматривают как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объёма работ. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь граф. Разделяйте политику разбиения на части и политику получения данных. Изменение одной из них не должно приводить к переписыванию другой при изменении показателей качества. Этап «Сколько векторов получено» работает наилучшим образом, когда его рассматривают как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объёма работ. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-либо шаг срабатывает некорректно, причина сбоя должна указывать на конкретную ответственность, а не на запутанную цепочку операций.
Page 1 (naukri.com) → 3000 chars → split into 6 chunks → 6 vectors
Page 2 (linkedin.com) → 5000 chars → split into 10 chunks → 10 vectors
Page 3 (indeed.com) → 2000 chars → split into 4 chunks → 4 vectors
Page 4 (glassdoor.com) → 4500 chars → split into 9 chunks → 9 vectors
Page 5 (some blog) → 1500 chars → split into 3 chunks → 3 vectors
─────────
32 vectors in the database
Как происходит получение данных
На этапе «Как работает поиск» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Рассматривайте этот этап как контракт между входными данными и проверенными результатами. Дайте названия элементам, определите критерии успеха и не допускайте молчаливого частичного завершения работы. Указывайте те фрагменты текста, которые легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
Шаг 1: Вставить запрос с тем же моделью
На этапе 1 «Встраивание сцены» необходимо определить входные данные, ответственного за шаг и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Рядом с функциональными результатами следует записывать время выполнения и стоимость токенов или запросов. Отображение стоимости заранее предотвращает неожиданные счета при переходе от демо-среды к общедоступным средам. При следующем шаге, представляющем собой код или вызов инструмента, следует отдавать предпочтение структурированным выводам с проверкой схемы перед свободным текстом.
"backend engineering jobs in Bengaluru" → [0.20, -0.04, 0.86, ...]
Шаг 2: Сравнение с каждым сохраненным вектором
На этапе 2 «Сравнение с эталоном» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед внесением изменений в код. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Конфигурацию следует хранить отдельно от кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Указывайте те участки текста, которые легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации. На этапе 2 «Сравнение с эталоном» необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед внесением изменений в код. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Предпочитайте небольшие, тестируемые единицы кода большим, запутанным скриптам. При сбое шага он должен указывать на конкретную причину, а не на запутанную структуру обработки данных.
Итог.
Query vector vs Chunk 1 ("Senior Backend Engineer Wipro, Bengaluru...")
→ similarity: 0.95 ✅
Query vector vs Chunk 2 ("Frontend dev needed Chennai...")
→ similarity: 0.23 ❌Query vector vs Chunk 3 ("Backend Engineer Flipkart Bengaluru...")
→ similarity: 0.97 ✅
Шаг 3: Возврат топ-k фрагментов
При работе над шагом 3 «Возврат» сначала запишите контракт: необходимые входные данные, сигнал о успехе и действия при частичной неудаче. Такой чек-лист поможет избежать ошибок при последующих изменениях кода. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Укажите названия элементов, определите критерии успеха и не допускайте молчаливого частичного выполнения задачи. Оцените уровень воспроизводимости на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска.
Проблема фрагментации
При работе над этапом «Проблема кусочковой обработки» сначала запишите условия работы алгоритма: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает избегать ошибок при последующих изменениях кода. Рядом с функциональными результатами записывайте время выполнения и стоимость обработки токенов или запросов. Отслеживание затрат с самого начала предотвращает неожиданные расходы при переходе с демо-среды в общедоступные среды. Перед настройкой подсказок измерьте уровень воспроизведения ответов на фиксированный набор вопросов. Частая смена подсказок редко помогает улучшить качество поиска.
Original text:
"...looking for a talented software engineer with 5 years of backend experience..."
Chunk 1 (chars 0-500): "...looking for a talented software engi"
Chunk 2 (chars 500-999): "neer with 5 years of backend experience..."
"Home About Careers Login Contact Us Senior Backend Eng"
Лучшие подходы:
На этапе поиска лучших решений сначала запишите условия работы алгоритма: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист помогает сохранять честность последующих изменений в коде. Храните конфигурацию отдельно от кода приложения. Файлы с настройками, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Измеряйте степень воспроизведения результатов на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска. На этапе поиска лучших решений сначала запишите условия работы алгоритма: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой чек-лист помогает сохранять честность последующих изменений в коде. Предпочитайте небольшие, тестируемые единицы кода большим скриптам. Если какой-то шаг не сработает, причина должна быть связана с конкретной функцией, а не с запутанной цепочкой операций.
Подробный обзор с реальными цифрами
Полное руководство по данному этапу наиболее эффективно при рассмотрении его как измеримой поверхности. Зафиксируйте один идеальный пример выполнения, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия создаваемым элементам, определите критерии успешного выполнения и не соглашайтесь на молчаливое частичное завершение работы. Разделяйте политику разбиения на части и политику извлечения данных. Изменение одной из них не должно приводить к переписыванию другой при изменении показателей качества.
"Home Jobs Companies Senior Backend Engineer Wipro, Bengaluru
Build scalable APIs using Java Spring Boot. 5+ years experience required."
Токенизация (29 токенов):
Этап токенизации, включающий 29 токенов, работает наилучшим образом, если рассматривать его как измеримый показатель. Соберите один идеальный пример обработки, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объёма работ. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Отслеживание затрат на раннем этапе предотвращает неожиданные счёты при переходе от демо-среды к общедоступным средам. Установите лимит токенов на один ход и на одну сессию. Инструменты агентного типа активно расширяют контекст; жёсткие ограничения не позволяют демо-версиям превращаться в неожиданные счёты.
["[CLS]", "home", "jobs", "companies", "senior", "backend", "engineer",
"wi", "##pro", ",", "bengal", "##uru", "build", "scala", "##ble",
"api", "##s", "using", "java", "spring", "boot", ".", "5", "+",
"years", "experience", "required", ".", "[SEP]"]
Векторы по токену (для лучшей читаемости показано 8 измерений вместо 384):
Векторы на единицу токена, представляющие 8 этапов, лучше всего использовать как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь граф работы.
"[CLS]" → [ 0.01, 0.03, -0.02, 0.05, 0.01, -0.04, 0.02, 0.06]
"home" → [ 0.44, 0.12, -0.33, 0.08, -0.21, 0.55, 0.09, -0.17]
"jobs" → [ 0.31, -0.05, 0.67, 0.22, 0.14, -0.08, 0.43, 0.11]
"companies" → [ 0.28, 0.09, 0.51, 0.18, 0.07, -0.12, 0.38, 0.05]
"senior" → [ 0.15, -0.22, 0.71, 0.33, 0.41, 0.09, 0.55, 0.27]
"backend" → [ 0.52, -0.18, 0.83, 0.45, 0.38, 0.21, 0.61, 0.34]
"engineer" → [ 0.48, -0.15, 0.79, 0.41, 0.35, 0.18, 0.58, 0.31]
"wi" → [ 0.11, 0.04, 0.22, 0.09, 0.03, 0.07, 0.14, 0.02]
"##pro" → [ 0.08, 0.02, 0.19, 0.06, 0.01, 0.05, 0.11, -0.01]
"," → [ 0.00, 0.01, 0.00, 0.01, -0.01, 0.00, 0.01, 0.00]
"bengal" → [ 0.39, 0.27, 0.55, 0.30, 0.22, 0.33, 0.41, 0.19]
"##uru" → [ 0.14, 0.10, 0.21, 0.11, 0.08, 0.12, 0.15, 0.07]
"build" → [ 0.35, -0.11, 0.62, 0.28, 0.19, 0.15, 0.47, 0.22]
"scala" → [ 0.29, -0.09, 0.54, 0.24, 0.16, 0.11, 0.40, 0.18]
"##ble" → [ 0.10, 0.03, 0.18, 0.07, 0.05, 0.04, 0.13, 0.06]
"api" → [ 0.41, -0.14, 0.73, 0.37, 0.30, 0.19, 0.53, 0.28]
"##s" → [ 0.03, 0.01, 0.05, 0.02, 0.01, 0.01, 0.04, 0.01]
"using" → [ 0.07, 0.02, 0.11, 0.04, 0.03, 0.02, 0.08, 0.03]
"java" → [ 0.46, -0.20, 0.77, 0.39, 0.32, 0.17, 0.56, 0.29]
"spring" → [ 0.42, -0.16, 0.70, 0.35, 0.28, 0.14, 0.51, 0.25]
"boot" → [ 0.38, -0.13, 0.65, 0.31, 0.25, 0.12, 0.48, 0.23]
"." → [ 0.00, 0.01, 0.00, 0.01, -0.01, 0.00, 0.01, 0.00]
"5" → [ 0.05, 0.01, 0.09, 0.03, 0.02, 0.01, 0.06, 0.02]
"+" → [ 0.01, 0.00, 0.02, 0.01, 0.00, 0.00, 0.01, 0.00]
"years" → [ 0.20, -0.07, 0.44, 0.19, 0.13, 0.08, 0.33, 0.14]
"experience" → [ 0.33, -0.10, 0.61, 0.27, 0.20, 0.13, 0.45, 0.21]
"required" → [ 0.18, -0.06, 0.39, 0.16, 0.11, 0.07, 0.29, 0.12]
"." → [ 0.00, 0.01, 0.00, 0.01, -0.01, 0.00, 0.01, 0.00]
"[SEP]" → [ 0.02, 0.01, -0.01, 0.03, 0.00, -0.02, 0.01, 0.04]
Векторы на единицу токена, представляющие 8 этапов, лучше всего использовать как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг сбивается, причина сбоя должна указывать на конкретную ответственность, а не на запутанную цепочку операций.
Объединение — 29 векторов превращаются в 1:
Для метода объединения 29 векторов формируется этап, при котором до изменения кода необходимо определить входные данные, ответственного за выполнение шага и критерии завершения. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Укажите названия результатов работы, определите критерии успеха и не допускайте молчаливого частичного завершения задачи. Цитируйте те фрагменты, которые фактически легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
Dim 1: (0.01 + 0.44 + 0.31 + 0.28 + 0.15 + 0.52 + 0.48 + 0.11 + 0.08 + 0.00
+ 0.39 + 0.14 + 0.35 + 0.29 + 0.10 + 0.41 + 0.03 + 0.07 + 0.46 + 0.42
+ 0.38 + 0.00 + 0.05 + 0.01 + 0.20 + 0.33 + 0.18 + 0.00 + 0.02) / 29
= 0.231
Dim 2: (0.03 + 0.12 + -0.05 + 0.09 + -0.22 + -0.18 + -0.15 + 0.04 + 0.02 + 0.01
+ 0.27 + 0.10 + -0.11 + -0.09 + 0.03 + -0.14 + 0.01 + 0.02 + -0.20 + -0.16
+ -0.13 + 0.01 + 0.01 + 0.00 + -0.07 + -0.10 + -0.06 + 0.01 + 0.01) / 29
= -0.030... same for all 384 dimensions ...
Хранится в базе данных векторов:
Для этапа хранения в векторе необходимо заранее определить входные данные, ответственного за выполнение шага и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Рядом с функциональными результатами следует записывать время выполнения и стоимость токенов или запросов. Отображение стоимости заранее предотвращает неожиданные счета при переходе с демо-среды в общедоступные среды. Указывайте те фрагменты текста, которые на самом деле легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации.
text: "Home Jobs Companies Senior Backend Engineer Wipro, Bengaluru..."
vector: [0.231, -0.030, 0.421, 0.189, ...]
Теперь пользователь ищет: «старший инженер бэкенда в Wipro»
На этапе поиска пользователя в For the Now необходимо заранее определить входные данные, ответственного за шаг и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь кодовый граф. Указывайте те участки текста, которые фактически легли в основу ответа. Без цитат операторы не смогут отличить галлюцинации от пробелов в индексации. На этапе поиска пользователя в For the Now необходимо заранее определить входные данные, ответственного за шаг и критерии завершения перед изменением кода. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не догадываясь о скрытом состоянии. Предпочитайте небольшие, тестируемые единицы кода большим, запутанным скриптам. При сбое шага он должен указывать на конкретную причину, а не на сложную цепочку операций.
Query vector: [0.228, -0.028, 0.418, 0.185, ...]
Chunk vector: [0.231, -0.030, 0.421, 0.189, ...]
Два модели, две задачи
На этапе «Два модели, две задачи» сначала запишите контракт: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой список помогает избегать некорректных изменений в коде позже. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия создаваемым элементам, определите критерии успешности и не допускайте молчаливого частичного выполнения задачи. Храните в кэше стабильные инструкции системы и схемы инструментов. Повторная отправка одинакового входного сообщения — частая причина избыточных ресурсов.
Почему важен RAG
При работе над этапом «Почему важен RAG» сначала запишите условия работы: необходимые входные данные, сигнал успешного выполнения и последствия частичной неудачи. Такой список помогает сохранять честность при последующих изменениях кода. Рядом с функциональными результатами записывайте время выполнения и стоимость токенов или запросов. Очевидность затрат с самого начала предотвращает неожиданные счета при переходе от демо-среды к общедоступным средам. Измеряйте уровень воспроизведения ответов на фиксированном наборе вопросов перед настройкой подсказок. Частая смена подсказок редко помогает улучшить качество поиска информации.
Что делает хорошей модель эмбеддингов?
При работе над этапом «Что делает решение хорошим», сначала запишите условия взаимодействия: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает сохранять честность последующих изменений в коде. Храните конфигурацию отдельно от кода приложения. Файлы с настройками окружения, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Храните в кэше стабильные инструкции системы и схемы инструментов. Пересылка одинаковых данных является распространенной причиной избыточных затрат. При работе над этапом «Что делает решение хорошим», сначала запишите условия взаимодействия: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает сохранять честность последующих изменений в коде. Воздерживайтесь от использования обширных скриптов в пользу небольших, тестируемых единиц. При сбое какого-либо шага причина должна быть связана с конкретной функцией, а не с запутанной цепочкой операций.
A: "Senior Backend Engineer at Wipro"
B: "Software Developer role in Bengaluru"
C: "Best chocolate cake recipe"
Чек-лист для эксплуатации
При работе над этапом операционного чек-листа сначала запишите условия контракта: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой чек-лист помогает сохранять честность при последующих изменениях кода.
Документируйте как успешный сценарий работы, так и сценарий восстановления. Повторные попытки, проверки со стороны человека и обработка неработоспособных сообщений являются частью продукта, а не элементами последующей доработки.