Като част от пътя на Glassdoor да се превърне в управлявана от ML компания, ние създадохме изключителна платформа за машинно обучение и инженерен екип (вижте нашия блог за изграждането на този екип тук), посветен на разработването на основната инфраструктура за всички наши инициативи за ML . Стратегически изградихме нашата ML платформа, наречена „Glassmind“, като използвахме комбинация от закупуване, изграждане и приемане от съществуващи решения с отворен код. Този подход ни позволи да използваме най-доброто от всички светове. Нашият екип е имал възможността да изгради многобройни инструменти от нулата, включително канали за данни, инструменти за работа с човек в цикъла и други. Ние също така надградихме съществуващи инструменти като AWS Sagemaker, за да включим мощни вътрешни персонализации в нашия магазин за функции. Имаме още вълнуващи планове в полет, като изграждане на нова платформа за препоръки, допълнителни приноси с отворен код от нашата платформа и продължаване на изграждането върху основата, която сме установили. Днес ще разгледаме нашия нов ML регистър с отворен код.

Какво е ML регистър?

Жизненият цикъл на ML обхваща много повече от просто разработване на модел. След като моделът е изграден, възникват много въпроси: Къде се намира? Как да получим достъп до него? Какво става, ако са необходими актуализации или версии? Къде можем да съхраняваме метаданните, описващи модела? А какво да кажем за други немоделни артефакти? Как можем ефективно да управляваме всичко това? Влезте в регистъра на ML. ML Registry на Glassdoor е централизирана услуга за управление на ML артефакти и всички свързани метаданни. Той служи като единствен източник на истина за всички данни, свързани с машинното обучение, позволявайки еднакъв и надежден достъп до тези данни в различни екипи и приложения. Той безпроблемно се интегрира с други инструменти и услуги и осигурява стабилна, богата на функции функционалност.

Избор между покупка и изграждане, какво отличава ML регистъра на Glassmind?

Въпреки че вече съществуват няколко платени регистри с модели с отворен код, ние внимателно оценихме техните предложения и открихме, че нито едно съществуващо решение не отговаря напълно на нашите специфични изисквания. Въпреки че изборът на управлявана услуга може да осигури някои предимства, като например готова функционалност, която би изисквала значителна инвестиция във време, за да се изградим, ние решихме да изградим нашия регистър от нулата поради няколко убедителни причини:

  1. Пълно персонализиране— което позволява на нашите архитекти да го проектират според нашите уникални желания и нужди. Например проектиране на нашата плътно свързана Git интеграция, способност за обработка на немоделни артефакти и метаданни, нашия кеш на метаданни и интегриране в екосистемата Glassdoor.
  2. Незабавна и денонощна поддръжка — което дава възможност на Glassdoor да поправя бъгове незабавно. Освен това можем да повторим бързо въз основа на обратна връзка от нашите потребители.
  3. Безпроблемна интеграция в рамките на екосистемата Glassdoor — Внедряването на тази услуга по същия начин, както другите ни услуги, предлага подобрена свързаност, наблюдение, предупреждение, интеграция, отстраняване на проблеми и поддръжка.
  4. Разходи —Задълбочено разглеждане на разходите и въздействието върху латентността подсили решението ни да започнем изграждането на нашия ML регистър от нулата (за по-задълбочени прозрения вижте просветляващия Zillow Engineering Blog, сравняващ предимствата на изграждането срещу купуване).

Подходът на Glassdoor: Git First

В Glassdoor ние възприехме ориентиран към Git подход, при който всяко хранилище и клон съдържат файл artifacts.yml, който служи като централна конфигурационна точка за управление на метаданни. Този YAML файл позволява на отделни екипи и хранилища да дефинират и персонализират съответните метаданни, специфични за техните проекти. Вземете опростен пример за artifacts.yml по-долу:

topic-training-data:
  dataObjectId: 123
  type: dataset
  config:
    type: tsv
    hasHeader: true
classification-output:
  dataObjectId: 456
  type: dataset
  config:
    type: tsv
    hasHeader: true

Тук можем да конфигурираме метаданни за различни артефакти. За артефакта “topic-training-data” можем да видим нашето най-важно поле за конфигурация, dataObjectId, указващо неговия уникален идентификатор, който можем да използваме за запитване до ML Registry. Можем също да включим всякакви други полета с метаданни в свободна форма, специфични за този артефакт.

За да улесним безпроблемното управление на тези метаданни, ние предоставяме две удобни опции за тяхното актуализиране. Първо, екипите могат да инициират промени чрез заявка за сливане (MR), която задейства работен поток за одобрение, гарантирайки правилен преглед, преди да бъдат приложени модификациите. Второ, за по-рационализирана интеграция в нашите приложения, ние предлагаме API, който позволява лесни програмно управлявани актуализации на метаданните, давайки възможност на разработчиците да включат промените в метаданните като част от своя код. В допълнение, нашият API също така позволява плавни заявки за качване и изтегляне на артефакти, осигурявайки лесен механизъм за достъп и манипулиране на обекти с данни.

Използвайки Git като най-добрия източник на истина, нашият ML регистър синхронизира тези метаданни от файловете artifacts.yml (за проект, за клон) в Redis кеш по време на стартиране на приложението и гарантира синхронизиране след всякакви последващи промени. Използването на Git като източник на истина става особено ценно по време на критични събития или фатални събития за приложението. В такива случаи регистърът на ML се синхронизира с Git, което ни позволява да възстановим и изградим отново системата от надеждно и последователно състояние. Когато се правят актуализации чрез API или заявка за сливане (MR), Git винаги се актуализира първо, за да се гарантира, че никога няма да срещнем несъответствия в данните. Тази синхронизация на Git с Redis осигурява еднакъв, бърз и лесен достъп до най-актуалните метаданни за всички потребители в компанията, като дава възможност на екипите да управляват ефективно своите артефакти, гарантирайки целостта и последователността на данните. Използвайки Git, ние също така гарантираме стабилна версия и история на промените. Можем да видим, че регистърът на ML ефективно се справя с общия проблем с организацията на данните, свързани с артефактите на машинното обучение.

Лесно потребление: Овластяване на ML Pipelines и други потребители

За да осигурим широко разпространена използваемост, ние използвахме OpenAPI Generator, автоматично генерирайки клиенти за всяка нова версия на приложението. Нашите OAS3 API спецификации са лесно достъпни чрез автоматично генерирания Swagger UI. Освен това ние синхронизирахме ML регистъра с опашка SQS, позволявайки на всяка заинтересована услуга да слуша за събития на промяна. Тази интеграция дава възможност на ML тръбопроводите и задачите, задействайки автоматизацията безпроблемно.

Гъвкавост на изпълнението

Както споменахме по-рано, ние сме приели подход, базиран на Git. Redis служи като наш бекенд кеш за незабавно извличане на метаданни, а S3 действа като нашето решение за съхранение на обекти с данни. Въпреки че потребителите с отворен код могат да се възползват от нашите подробности за внедряването, те също могат да създадат своя собствена функционалност чрез внедряване на интерфейси, които абстрахират цялата функционалност на регистъра на ML.

Опитай го!

Насърчаваме ви да опитате нашия ML регистър и да изпитате неговите възможности от първа ръка. За да започнете, просто:

  1. Клонирайте хранилище на проекта.
  2. Актуализирайте файла properties с вашите собствени ключове или ги инжектирайте по начин, който е подходящ за вашето приложение.

След като го настроите, можете да изследвате функциите на ML Registry с помощта на нашия автоматично генериран потребителски интерфейс на Swagger, който ще ви позволи да взаимодействате безпроблемно с API на вашия локален хост, преди да го внедрите. Ако работите с бекенд технологии, различни от нашия стек, не се притеснявайте. Регистърът на ML предоставя интерфейси, които можете да приложите, за да приспособите към вашите специфични изисквания. Опитайте го и ни кажете какво мислите!

Благодарности

Специално признание отива на Малати Санкар, инженерен директор за машинно обучение в Glassdoor, който е визионерът зад цялата платформа Glassmind. И на нашия архитект Ванс Торнтън, който проектира целия ML регистър от нулата. И двамата, чийто изключителен принос и експертен опит са допринесли за успеха на нашия ML-Engineering екип и развитието на ML Registry.