Англійська мова для розробників Feast Feature Store

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

Ключовий словник

** Перегляд властивостей ** — визначення, яке групує пов’ язані властивості разом з їх джерельними даними, ключами сутностей і часом до завершення, що служить як одиниця, яку Feast використовує для матеріалізації і обслуговування даних. “Розділити властивості користувача на їхні власні перегляди властивостей — об’ єднання їх з властивостями транзакцій означає, що ми занадто часто оновлюватимемо повільно змінювані дані.”

** Мережевий магазин ** — магазин ключів і значень з низькою затримкою, на зразок Redis або DynamoDB, який Feast використовує для надання найновіших значень можливостей у час виведення.

• “Затримка моделювання, оскільки інтернет- магазин не був реалізований з вчорашнього дня — функції, які обслуговуються, застаріли.” *

** Автономний склад** — склад, зазвичай, це сховище даних, яке використовується для створення історичних тренувальних наборів даних шляхом об’ єднання значень об’ єктів, які існували у певні моменти часу. “Для тренувальних даних, витягніть з автономного магазину з приєднанням у момент часу — ми не можемо просто запитати поточні значення онлайн- магазину для історичних міток.”

** Приєднання у точці часу ** — процес приєднання значень об’ єктів до позначених прикладів тренування за допомогою точного часу кожної позначки, що запобігає тренуванню моделі за даними, які не були доступними у той момент. “Без належного з’ єднання в момент часу, ця модель могла б витікати майбутню інформацію — значення властивостей повинні відображати те, що було відомо на час визначення, а не сьогодні.”

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

• “Встановити завдання матеріалізації, яке буде виконуватися кожні п’ ятнадцять хвилин — без цього, мережевий магазин буде просто продовжувати обслуговувати те, що було завантажено під час останнього вручну виконаного завдання.” *

Звичайні фрази

• Чи є цей перегляд властивостей обмежений до правильної сутності, або ми приєднуємося на неправильному ключі?»
• «Чи ми обслуговуємо з онлайн-магазину, або випадково потрапляємо в офлайн-магазин у час виведення?»
• Чи ми використовували приєднання в момент часу для цього тренувального набору, або є ризик витоку етикетки?
• «Чи матеріалізація працює за розкладом, чи ми покладаємося на когось, щоб запустити її вручну?»
• Як довго ці властивості можуть зберігатися, поки прогнози моделі не погіршаться значно?»

Приклади висловлювань

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

Пояснення вибору архітектури:

• “Ми розділяємо перегляд особливостей за частотою оновлення — повільно змінювані демографічні особливості відокремлені від швидко змінюваних поведінкових, тому матеріалізація не марнує циклів.” *

Перегляд запиту на звантаження: “Тетальний час життя перегляду цієї можливості занадто довгий для мережевого магазину — до моменту, коли вона буде використана, ця можливість вже застаріла у порівнянні з тим, як часто змінюються дані, що лежать в її основі.”

Професійні поради

• Розрізняйте **онлайн магазин ** від **офлайн магазин ** точно в будь-якій обговоренні обслуговування проти навчання - об’єднання їх є поширеним і дорогим джерелом тренування-обслуговування.
• Назвіть point-in-time join явно, коли обговорюється коректність тренувальних даних — це специфічний механізм, який запобігає витоку міток, і його назва сигналізує про суворе дотримання.
• При описі одиниці визначення властивості Feast скажіть feature view, а не « table » або « dataset » — вона має семантику сутності і свіжості, якої немає у звичайної таблиці.
• Посилання ** матеріалізація ** як конкретне, заплановане завдання під час зневадження застарілих — це переносить розмову з « дані здаються старими » на « коли останній раз матеріалізація запускалася. »

Практичні вправи

1. Поясніть різницю між мережевим і автономним магазинами у Feast.
2. Описати, чого запобігає об’ єднання у точці часу і чому воно важливе для тренувальних даних.
3. Напишіть речення, у якому пояснюється, що робить матеріалізація і чому її слід виконувати за розкладом.

Національний мовний стандарт: підготовка до впровадження

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

Однією з найчастіших перешкод є отримання коментарів про перегляд коду. Замість того, щоб сприймати їх як критику, сприймайте їх як можливість для * вдосконалення * або * оптимізації *. Коментар на кшталт «Це з’єднання могло б бути ефективнішим» не є негативним за своєю суттю. Перефразування його на «Чи можемо ми дослідити альтернативні стратегії з’єднання для поліпшення продуктивності в цьому з’єднанні в момент часу?» демонструє активний підхід і сигналізує, що ви відкриті до пропозицій. Аналогічно, коли ви пояснюєте свої аргументи — особливо, якщо вони відрізняються від точки зору рецензента — використовуйте такі фрази, як « Я розглядав [підхід] тому що … », надаючи чітке виправдання, а не просто заявивши « Це працює. » Пам’ ятайте, метою є спільне поліпшення коду, а не доведення точки зору. Інша область потенційного нерозуміння виникає в обговореннях Slack щодо переглядів функцій. На простий запит на допомогу може бути надіслано коротку відповідь на зразок « Перевірте документацію ». Замість цього спробуйте щось на зразок « Привіт, команда, я зіткнувся з проблемою під час створення нового перегляду можливостей за допомогою мережевого магазину, мені потрібні рекомендації щодо належного налаштування перевірки схеми. Буду дуже вдячний за будь- які пропозиції. » Остання частина повідомлення демонструє повагу до часу ваших колег і чітко описує ваші конкретні потреби.

Крім того, важливе значення має створення ефективних описів PR. Не просто перелік змін; наведіть контекст. Замість « Оновлено перегляд можливостей », напишіть: « Впроваджено новий перегляд можливостей для підтримки сегментації користувачів за історією покупок. Це оновлення містить правила перевірки схеми, які забезпечують цілісність даних і дотримуються встановлених правил присвоєння назв переглядів властивостей Feast. » Цей рівень деталізації надає переглядачеві можливість негайно зрозуміти, що відбувається, зменшуючи кількість питань, які потрібно задавати, і прискорюючи процес затвердження. Нарешті, пам’ятайте, що активне слухання є ключем. Перефразування того, що хтось сказав («Тоді, якщо я правильно розумію, ви турбуєтеся про…») демонструє залучення і забезпечує взаємне розуміння.

feast query --view my_feature_view --select user_id, purchase_amount

Ця проста команда показує типовий сценарій: запит даних з перегляду об’ єкта. Коли ви пояснюєте це колегі, ви можете сказати: « Давайте запустимо швидкий запит на my_feature_view, щоб побачити, чи можемо ми отримати останній ідентифікатор користувача і суму його покупки ». Точне формулювання має значення — мова йде не лише про те, що ви зробили, але і про те, чому і як ви це зробили.