Если эти три проблемы не решить, коммерческая посадка больших моделей – пустой звук!

Источник статьи: Data Ape

Автор: Дождь из дыма и дождя

Источник изображения: Сгенерировано Unbounded AI

В настоящее время большие модели стали горячей темой в деловом мире благодаря передовым исследованиям в академических кругах. В настоящее время отечественные технологические гиганты и начинающие стартапы активно изучают коммерческое применение большой модели, пытаясь использовать ее для привнесения инноваций и роста в существующие бизнесы.

Этот «стремительный марш» проявляется в двух аспектах: во-первых, большая модель глубоко интегрируется с традиционными основными бизнес-системами, такими как ERP, CRM, BI, финансы, маркетинг, эксплуатация и обслуживание клиентов, чтобы сделать ее более интеллектуальной и автоматизированной; Во-вторых, большие модели начали широко использоваться во многих отраслях, таких как финансы, производство, розничная торговля, энергетика и развлечения, способствуя инновациям и трансформации отрасли.

По результатам испытаний сетевого режима ChatGPT, Microsoft Bing, Baidu Wenxin Yiyan, Taobao Wenwen и других продуктов, автор обнаружил, что в коммерческом использовании больших моделей все еще есть очевидные проблемы.

В частности, для того, чтобы добиться коммерческой посадки, необходимо решить следующие три проблемы:

Стыковка системы

По мере того, как большие модели постепенно интегрируются в повседневные бизнес-операции, их функции выходят за рамки простой обработки данных и вычислений. Этот новый тип интеллектуальной модели должен иметь возможность взаимодействовать с широким спектром бизнес-систем в режиме реального времени и реагировать на различные бизнес-потребности. Теоретически это ключ к истинной ценности больших моделей, но на практике это также является серьезной технической проблемой.

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

Например, ранняя ERP-система, возможно, родилась в эпоху ограниченных вычислительных ресурсов и незрелых сетей, а ее концепция дизайна, структура данных и функциональные характеристики были тесно связаны с технической и бизнес-средой того времени. Они могут быть основаны на традиционных реляционных базах данных и сервис-ориентированных архитектурах, а не на современных микросервисах или контейнерных технологиях.

Современные платформы автоматизации маркетинга, напротив, выросли в эпоху облачных вычислений и больших данных и, естественно, обладают мощными возможностями обработки данных, динамической масштабируемостью и богатыми API-интерфейсами.

Эта разница в технологиях в корне определяет направление стратегии интеграции между большой моделью и этими системами. Попытка унифицировать все системы под единым стандартом, несомненно, непрактична.

Поэтому стратегия интеграции с большой моделью должна быть разнообразной, и она должна учитывать особенности и потребности каждой системы. В частности, для систем, основанных на устаревших технологиях, может потребоваться внедрение некоторых «адаптеров» или «промежуточных уровней» для преобразования данных и бизнес-логики таким образом, чтобы они могли плавно взаимодействовать с большими моделями. Для систем, которые уже внедрили современные технологии, интеграция может быть более простой и понятной, но согласованность и целостность данных все равно должны быть обеспечены.

Кроме того, в широком применении информационных технологий интерфейсы играют роль «мостов», отвечающих за передачу и коммуникацию информации между различными системами. Стандартизация интерфейсов ведется в IT-сфере уже давно, но в связи с развитием технологий и накоплением истории разнообразие интерфейсов стало неизбежным.

Такое разнообразие интерфейсов представляет собой серьезную проблему для интеграции больших моделей, и за каждым стандартом интерфейса или протоколом стоят специфические структуры данных, методы вызова и механизмы безопасности. Для того, чтобы большие модели могли беспрепятственно взаимодействовать с этими системами, для каждого интерфейса разрабатывается адаптер. Это означает, что в дополнение к обслуживанию самой большой модели, эти адаптеры также необходимо часто обновлять и оптимизировать, чтобы справляться с итерациями бизнес-систем и изменениями в интерфейсах.

Как решить эти проблемы? Управление API и микросервисная архитектура — это хороший путь развития, внедряя инструменты управления API и микросервисную архитектуру, предприятия могут модульизировать взаимодействие между большими моделями и другими системами, делая их более гибкими и масштабируемыми.

Основная идея микросервисной архитектуры состоит в том, чтобы разложить большую сложную систему на множество независимых небольших сервисов, которые работают независимо друг от друга и взаимодействуют через четко определенные API. Такая архитектура дает существенные преимущества при интеграции больших моделей, делая взаимодействие между отдельными частями и большой моделью более гибким за счет разделения функциональности всей системы на множество микросервисов.

Каждую микрослужбу можно масштабировать, развертывать и обслуживать независимо, не влияя на другие службы. В то же время инструменты управления API предоставляют разработчикам единую платформу для взаимодействия с каждым микросервисом и большой моделью.

Доступ к данным

В сегодняшнюю эпоху, управляемую данными, большие модели подобны гигантскому интеллектуальному «сердцу», которое обрабатывает, анализирует и предоставляет интеллектуальные рекомендации и решения для различных бизнес-систем. Эти бизнес-системы, от CRM до ERP, финансов и маркетинга, подобны кровеносным сосудам и органам, переплетенным с большой моделью и дополняющим друг друга. И кровь, которая течет через эту систему, и есть данные.

В идеале каждая транзакция, каждое действие пользователя, каждый отзыв клиента будут генерировать данные. Эти данные передаются из бизнес-системы в большую модель, анализируются и обрабатываются, а затем возвращаются в соответствующую бизнес-систему для предоставления пользователям более точных услуг или решений.

Давайте рассмотрим пример.

Предположим, что есть мисс Ван, которая является постоянным пользователем известной платформы для онлайн-покупок. Каждый раз, когда пользователь просматривает продукт, добавляет товар в корзину или совершает покупку, панель мониторинга автоматически записывает данные об этом поведении. Когда данные о поведении г-жи Ван передаются в большую модель в режиме реального времени, модель немедленно проводит углубленный анализ в сочетании с ее прошлой историей покупок и историей просмотров. Крупная модель быстро поняла, что госпожа Ван в последнее время проявляет большой интерес к летней женской одежде и, возможно, ей понадобятся некоторые аксессуары, подходящие к ее недавно купленному платью.

Когда она использует приложение большой модели этой платформы электронной коммерции, она может взаимодействовать с приложением в режиме реального времени и просить большую модель порекомендовать некоторые продукты. В это время крупная модель может порекомендовать широкий ассортимент обуви, сумок и даже других летних аксессуаров в тон летним платьям.

Допустим, она нажимает на одну из рекомендованных туфель, просматривает детали и, наконец, решает их купить. На этот раз покупка также записывается, и данные передаются в большую модель. В этом процессе мы можем увидеть важность плавного потока данных между большой моделью и бизнес-системой для предоставления точных услуг и решений.

Однако вышеописанная ситуация является лишь идеальной, а в реальности могут возникнуть самые разнообразные проблемы. Во-первых, сложность заключается в том, чтобы связать данные между различными бизнес-системами и большими моделями.

Если взять в качестве примера Taobao Ask, то теперь Taobao Ask не подключен к системе Taobao, Taobao Ask не знает предпочтений пользователя, он как информационный остров, встроенный в Taobao, и он не органично интегрирован во всю информационную систему Taobao. **

Более того, даже если данные связаны между большой моделью и бизнес-системой, из-за различий в исторических предпосылках, технических архитектурах и стандартах данных каждой бизнес-системы, вполне вероятно, что в процессе циркуляции данных возникнут «блокировки» или «точки утечки». Это может привести не только к потере данных, но и к искажению результатов анализа больших моделей.

Если взять в качестве примера платформы электронной коммерции, когда пользователи просматривают товары и совершают покупки, эти поведенческие данные будут передаваться в большую модель для анализа, чтобы рекомендовать продукты, которые больше подходят для пользователей. Однако, если данные теряются при передаче или не соответствуют формату данных других систем, большая модель может не иметь возможности точно рекомендовать продукты, что может повлиять на взаимодействие с пользователем.

Обмен данными между большими моделями и различными бизнес-системами особенно важен не только из-за увеличения объема данных, но и потому, что роль данных в создании ценности для предприятия меняется. Однако добиться плавного и точного потока данных между большой моделью и различными системами непросто.

Мы должны понимать, что поток данных между большой моделью и бизнес-системой — это не просто миграция или передача данных, это сложный, двусторонний и непрерывный процесс. В этом процессе каждая бизнес-система может часто взаимодействовать с большой моделью, а сама большая модель постоянно обновляется, обучается и развивается.

За этим потоком данных стоит бесчисленное множество технических и бизнес-проблем, например, тот факт, что данные в большой модели могут не соответствовать данным в бизнес-системе в определенный момент времени из-за разной частоты и времени обновлений из разных систем. Более того, различные бизнес-системы могут использовать разные технические архитектуры, форматы данных и стандарты интерфейса, что приводит к частым преобразованиям и корректировкам в потоке данных.

Вопросы безопасности и конфиденциальности данных нельзя игнорировать, данные могут подвергаться различным угрозам в процессе передачи, хранения и обработки, как обеспечить целостность, конфиденциальность и неопровержимость данных, стало серьезной проблемой, с которой сталкиваются предприятия. Особенно в межрегиональных и межсетевых средах передача данных также может иметь задержки, что является фатальным для бизнес-систем, требующих реагирования в режиме реального времени.

Конвергенция бизнеса

Большие модели постепенно проникли в различные отрасли и области, став важным стимулом для корпоративной аналитики. Однако для того, чтобы технологии действительно приносили пользу бизнесу, необходимо не только их внедрение, но, что более важно, тесная интеграция технологий и бизнеса. Для этого большая модель должна углубляться в детали бизнеса, понимать бизнес-логику и быть полностью интегрированной во всю бизнес-систему. **

Представьте себе крупную компанию электронной коммерции, которая хочет оптимизировать свою систему товарных рекомендаций с помощью большой модели. Для этого модели недостаточно распознавать историю покупок пользователя, ей также нужно понимать покупательские привычки пользователя, его интересы, предпочтения, историю поиска и многие другие детали. Кроме того, модель должна понимать бизнес-стратегии, такие как сезонные мероприятия, фестивали и рекламные акции, чтобы гарантировать, что создаваемый контент действительно ценен.

В связи с этим возникает ключевой вопрос: как сделать так, чтобы большая модель понимала и включала эти бизнес-детали? В частности, вы можете отталкиваться от следующих аспектов:

**1. Передача бизнес-знаний разрушает ограничения данных. **

Данные, несомненно, являются основными входными данными для большой модели, но для достижения истинного понимания бизнеса недостаточно полагаться на данные. Большая часть бизнес-знаний является неявной и неструктурированной, что затрудняет их предоставление с помощью традиционных средств обработки данных. Например, основные ценности компании, ее долгосрочные отношения с клиентами и незначительные изменения в отрасли могут не отражаться напрямую в данных. Эти знания, если их игнорировать, могут привести к тому, что модель будет принимать решения, отклоняющиеся от реального бизнес-сценария.

Поэтому необходимо тесное сотрудничество с бизнес-единицами. Бизнес-подразделения обладают большим опытом и глубоким пониманием бизнеса, и они могут предоставить детали, которые не могут быть охвачены данными. Речь идет не только о знаниях внутри компании, но и о том, что происходит с партнерами, конкурентами и даже отраслью в целом.

Одним из подходов, который стоит рассмотреть, является создание специальной команды бизнес-знаний, которая может состоять из бизнес-экспертов, специалистов по обработке и анализу данных и инженеров моделей, которые работают вместе, чтобы гарантировать, что большие модели получат всестороннюю и углубленную бизнес-подготовку.

**2. Адаптация к сложной бизнес-логике и индивидуальная разработка больших моделей. **

Разнообразие отраслей привело к усложнению бизнес-логики, и большая модель для финансовой индустрии вряд ли будет напрямую применима к розничной торговле или здравоохранению, поскольку эти отрасли имеют свои уникальные бизнес-правила и логику, что требует высокой степени кастомизации при проектировании и разработке большой модели.

Архитектуру, параметры и даже алгоритмы большой модели может потребоваться адаптировать под конкретные сервисы. Например, некоторые отрасли могут уделять больше внимания производительности в реальном времени, в то время как другие могут уделять больше внимания долгосрочным стратегиям, что может привести к тому, что моделям придется искать компромисс между скоростью вычислений и глубоким анализом.

  1. Адаптация к изменениям в бизнесе, гибкость и возможность итераций больших моделей. **

Бизнес не статичен, он меняется со временем, рынками и технологиями. Когда бизнес-логика и правила меняются, большая модель должна быть соответствующим образом скорректирована.

Это требует не только гибкости в проектировании модели, но и способности быстро выполнять итерации и оптимизацию на более позднем этапе. Непрерывное обучение модели, обратная связь с бизнесом в режиме реального времени и возможность онлайн-обучения модели — все это является ключом к тому, чтобы обеспечить синхронизацию большой модели с бизнесом.

В будущем мы прогнозируем, что большая модель будет и дальше интегрирована в бизнес, перестав быть просто инструментом для обработки и анализа данных, а станет ядром всего бизнес-процесса. Речь идет не только о технологическом прогрессе, но и о полной трансформации бизнес-моделей, организационных структур и методов работы.

Однако такая трансформация не происходит в одночасье и требует объединения усилий и сотрудничества бизнес-лидеров, бизнес-команд и технических команд. Требуется постоянное обучение, эксперименты и оптимизация, чтобы гарантировать, что большие модели действительно могут принести пользу бизнесу. В процессе могут возникать проблемы и трудности, но именно этот опыт позволит предприятиям получить ценные знания и возможности, которые помогут им выделиться среди конкурентов.

Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
  • Награда
  • комментарий
  • Поделиться
комментарий
0/400
Нет комментариев
  • Закрепить