Практичні нотатки: 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
Що таке ембеддинг?
На етапі «Що таке Embedding» необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке відображення витрат заздалегідь запобігає несподіваним рахункам під час переходу з демо-середовища у спільні. Наводьте конкретні уривки тексту, які лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем з індексуванням.
"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: Токенізація
Під час виконання кроку 1 з токенізації спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте безповідомного часткового виконання. Зберігайте у кеші стабільні інструкції системи та схеми інструментів. Повторна передача ідентичних даних є поширеною причиною витрат ресурсів.
"backend engineer jobs in bangalore"
Tokens: ["backend", "engineer", "jobs", "in", "bang", "##alore"]
Крок 2: Шари трансформера
Під час роботи над етапом «Шари Transformer, крок 2», спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Виміряйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити ефективність пошуку.
"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"
Кращі підходи:
Під час роботи на етапі кращих підходів спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Зміна підказок рідко вирішує проблеми слабкого пошуку інформації. Під час роботи на етапі кращих підходів спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.
Повний огляд з реальними цифрами
„The A Complete Walkthrough With“ працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад виконання, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику поділу на частини та політику отримання даних. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.
"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:
Для методу Pooling з 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"
Чек-лист для експлуатації
Під час роботи над етапом перевірки операційного процесу спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді.
Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людські контролі та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки.