задний план
С быстрым развитием картографического бизнеса AutoNavi, в дополнение к самому алгоритмическому бизнесу навигации, другие малые и средние предприятия испытывают все больший спрос на стратегии алгоритмов, и некоторые новые проекты, в которых участвовали за последние два года, варьировались от исследования алгоритмов Запуск осуществляется на еженедельном уровне, например, различные сервисы алгоритмов, связанные с совместными поездками, потребности бизнеса в различных системах, таких как контроль рисков, планирование и маркетинг. Подобно зрелой архитектуре с длительным циклом, высоким трафиком и малой задержкой, а также методам разработки в традиционной навигации, они больше не могут удовлетворять потребности быстрых проб и ошибок, оптимизации и улучшения на ранних стадиях таких услуг, а также поиска подходящий алгоритмический метод обслуживания, расширяющий возможности бизнеса, изменится.
В процессе реализации принимается интегрированная структура. Так называемая интеграция относится к интеграции всего алгоритма и инженерии, включая открытие всех связей, таких как данные и системы, для реализации систематического потока данных; алгоритм бизнес-исследований учитывает развитие инженерных услуг, а процессы тестирования и проверки автоматизированы и интеллектуальны, замыкают бизнес-цикл и способствуют быстрой итерации бизнеса.
На ранней стадии проекта требуется быстрый метод проб и ошибок и оптимизация стратегии. В настоящее время QPS бизнес-требований часто невысок (
В этом процессе мы надеемся достичь цели исследования офлайн-стратегии как разработки логики сервиса и офлайн-исследования как завершения сервиса, что может значительно сократить время от исследования алгоритма до запуска стратегии. Поскольку нагрузка на производительность (QPS, RT) невысока, можно использовать Python для быстрой автономной разработки.
В долгосрочной перспективе, по мере постепенного развития бизнеса, быстрое сочетание алгоритмов, количество вызовов службы и производительность службы становятся важными критериями оценки для измерения алгоритмических услуг. В настоящее время следует продвигать разумную оптимизацию. Например, высокая производительность основной логики алгоритма станет важной работой.
Следовательно, процесс построения алгоритмической инженерной интеграции также является процессом удовлетворения итеративного процесса от стадии запуска до стадии зрелости бизнеса.
Общая логическая архитектура системы
Вся платформа аналогична той, что показана на рисунке выше, и в основном состоит из нескольких логических частей:- Служба единого шлюза доступа
- Служба раскрытия бизнес-алгоритмов
- Модель алгоритма и служба управления кодом
- Система обеспечения качества
Примечание. GBFC — это уровень службы данных, который в основном используется для получения данных и функций, требуемых различными алгоритмами, чтобы служба бизнес-алгоритмов могла достигать условий без сохранения состояния, а также удобна для совместного использования данных и совместного построения в различных бизнес-процессах. линии.
Единый шлюз доступа
Целью службы шлюза является изоляция различных API-интерфейсов алгоритмов и предоставление атомарных и составных служб. Когда бизнес-стороне необходимо вызвать различные алгоритмы, такие как оценочное суждение, оценка рисков и маркетинговые рекомендации, унифицированный шлюз предоставляет единый алгоритм API для каждого бизнеса, чтобы избежать повторных вызовов каждой службы. Шлюз алгоритмов выполняет унифицированный мониторинг алгоритмов, включая производительность службы, доступность интерфейса и т. д., и унифицированным образом собирает данные для облегчения управления данными и создания функций, проведения онлайн-обучения в режиме реального времени, улучшения взаимодействия с пользователем и обеспечения эффективности алгоритмов.С одной стороны, служба шлюза может выполнять некоторые общие операции предварительной обработки, такие как аутентификация, маршрутизация, ограничение тока, переход на более раннюю версию, объединение, оттенки серого, AB, запуск и т. д., чтобы обеспечить доступность и масштабируемость службы. В то же время он может выполнять комбинацию сервисов, таких как распознавание речи, обработка изображений и т. д., чтобы можно было органично комбинировать различные сервисы алгоритмов, так что уровню бизнес-алгоритмов нужно только поддерживать атомарные сервисы для выполнения сложной бизнес-обработки.
Следовательно, сервисы шлюза должны поддерживаться гибким, эластичным, легковесным бизнес-уровнем алгоритмов без сохранения состояния.С точки зрения выбора технологии, текущая горячая бессерверная архитектура вполне может удовлетворить вышеуказанные требования.
Служба бизнес-алгоритмов в бессерверной архитектуре
В 2009 году Беркли определил облачные вычисления с уникальной точки зрения.Особенно за последние четыре года эта статья цитировалась много, и ее точки зрения очень подходят для технических сценариев на ранней стадии бизнеса, таких как сокращение обслуживания. ориентированная на работу и связанная только с бизнес-логикой, или алгоритмическая логика для достижения быстрой итерации, вычислений по требованию и т. д. В 2019 году Беркли пошел дальше:
Интерфейс, предоставляемый Serverless, упрощает программирование облачных вычислений, что представляет собой еще одно изменение в производительности программиста, точно так же, как языки программирования развиваются из эпохи ассемблера в эпоху языков высокого уровня.
В текущем исследовании бессерверных технологий FaaS считается лучшим примером, что связано с его собственными характеристиками. FaaS очень легкий, не имеет состояния и работает быстро. Он особенно подходит для приложений без сохранения состояния. Хотя на уровне холодного запуска есть некоторые узкие места, эта архитектура по-прежнему решает многие проблемы. Быстрое внедрение алгоритмов на ранней стадии бизнеса. точно такой же, как Характеристики этой архитектуры совместимы.
Основываясь на бессерверной архитектуре, мы развертываем службу алгоритма, как показано на рисунке ниже.
Как показано на рисунке выше, после того, как локальная разработка сервиса алгоритма завершена, его можно напрямую выпустить как функцию, то есть завершение упомянутого ранее исследования офлайн-стратегии является завершением кода сервиса. Эта функция также решает проблему разрыва связи между студентами, изучающими алгоритмы, и бизнесом. Многие студенты, изучающие алгоритмы, не могут самостоятельно завершить разработку всей инженерной службы и должны предоставить код инженерам для интеграции, упаковки и выпуска. Однако этот метод совместной работы используется повсеместно. цепочка неразумная.С одной стороны, студенты-алгоритмы не могут самостоятельно выполнять бизнес-поддержку, с другой стороны, студенты-инженеры должны не только иметь дело с логическими вызовами, но и тратить время на понимание текущих методов реализации алгоритмов, принципов, необходимых данных, нештатных ситуаций. и другие вопросы, которые зачастую являются относительной проблемой.Большую часть времени занимают простые алгоритмические услуги, встречи и общение.Поэтому внедрение FaaS не только упрощает процесс развития бизнеса, но и делает развертывание алгоритма максимально атомарным, облегчая сборка и повторное использование между предприятиями.
На пути реализации мы сначала завершили создание среды выполнения Python, которая может напрямую обслуживать код Python и связанные с ним модели, а модели частично поддерживают PMML, TensorFlow и т. д., тем самым реализовав быструю итерацию, необходимую на ранней стадии. бизнеса, Призыв к сокращению затрат на пробы и ошибки.
После этого будет постепенно улучшаться среда выполнения на основе Golang, Java и т. д. Причина выбора Golang заключается в том, что он имеет хорошую поддержку параллелизма, что позволяет не только достичь требований к производительности, требуемых бизнесом, но и сохранить характеристики относительно простой разработки.
После того, как алгоритм атомизирован и функционализирован, студенты-алгоритмы получают возможность самостоятельно нести ответственность за онлайн-бизнес, но это также приносит несколько серьезных проблем: стабильность сервиса, качество проекта и корректность сервиса. Если эти алгоритмы просто перекинуты одноклассникам, то это будет лишь перенос рабочей нагрузки, а также может вызвать риск простоя всего бизнеса. Поэтому построение системы обеспечения качества стало важной частью.
Построение системы обеспечения качества
Многие думают, что обеспечение качества означает отправку тестировщикам для тестирования или регрессионного тестирования, но это не так. Затраты на рабочую силу, сэкономленные в первых двух частях, переносятся на испытуемых.Поскольку инженерные способности студентов-алгоритмистов относительно слабы, нужно ли привлекать больше испытуемых для проверки?
Если придерживаться такого мышления, то итеративная скорость бизнеса все равно не может быть быстрой. Поэтому необходимо рассмотреть: может ли этот контроль качества быть полностью автоматизирован? Ответ положительный.
В процессе исследования стратегии обычно выполняются следующие этапы: 1. Анализ данных 2. Разработка алгоритма 3. Проверка данных 4. Ручная/автоматическая оценка 5. Итерация стратегии и повторение шагов 1-4. В этот процесс просто включаются данные, наборы данных, тестовые наборы и проверочные наборы, требуемые системой обеспечения качества.
Алгоритмы Студенты могут использовать три набора для реализации процесса автоматического стресс-тестирования, вывода соответствующей информации, такой как QPS, RT, уровень согласованности и т. д., использовать набор данных для проведения теста на стабильность, использовать набор тестов для реализации логической проверки правильности ; проверка эффекта.
Конечно, вышеизложенное является лишь частью обеспечения качества. В процессе быстрой итерации общего бизнеса часто необходимо проводить проверку АБ, или полномасштабную проверку сопровождения.В процессе реализации, через дренажную и технологическую цепочку, мы реализовали процесс полномасштабного сопровождения, и алгоритм, который будет запущен, достиг полного диапазона качества.
резюме
Унифицированное построение алгоритмов и техники в основном реализовало требования быстрой итерации на ранней стадии бизнеса. В процессе разработки проекта задача для студентов-инженеров исходит не только от инженерной практики, но и требует четкого понимания стадии бизнеса.
В нынешних обстоятельствах причина, по которой алгоритмы и проекты могут выполняться независимо, заключается в необходимой предпосылке, что данные и алгоритмы разделены, то есть службы алгоритмов не имеют состояния и функциональны. Из-за этого также требуется много времени для создания слоя сервиса объектов. Точно так же построение уровня сервиса объектов также может следовать аналогичной логике для достижения совместного построения и совместного использования.
Наконец, необходимо повторить, что архитектура интеграции разработки алгоритмов может в основном удовлетворить требования бизнес-алгоритмов. Тем не менее, для некоторых проектов ИИ, которые требуют огромного объема вычислений, узкие места вычислительной мощности и энергопотребления, вызванные частым сбором данных, значительно ограничивают инновации алгоритмов. Отрасль интегрирует блок хранения данных и вычислительный блок, чтобы реализовать инновации аппаратной архитектуры для интеграции вычислений и хранения, преодолевая узкое место вычислительной мощности ИИ.