Традиционно ИТ адресира бизнес казуси чрез използване на софтуерно инженерство и заявки към бази данни. През последните десетилетия обектно-ориентираните езици като C++, Java и езикът за структурирани заявки (SQL) придобиха популярност. ИТ екипите използват тези езици, за да проектират обекти, да дефинират техните свойства, функции и методи и да управляват взаимоотношенията между обекти, за да адресират ефективно бизнес случаите.
Наскоро има две промени в ИТ света:
- Тъй като данните стават централни за почти всички аспекти на бизнеса, за да отговорят на различни изисквания, се появиха много различни видове хранилища на данни, схеми и заявки за ефективно извличане на прозрения от данните. В резултат на това изчисленията, ориентирани към данни, привлякоха значително внимание и се превърнаха в модна дума.
- AI/ML технологиите напредват бързо. Тяхното използване и дискусии са преобладаващи в различни области. Публичното изпробване на ChatGPT допълнително ускори тази тенденция. Днес изглежда, че ML се е превърнал в неразделна част от почти всяко ИТ решение и хората се стремят да включат ML модели в своите приложения. Усещането е, че никое приложение не е пълно без интегрирането на ML модели.
Публикувах няколко блога за дизайн и архитектура на приложения или решения с безпроблемно интегрирани технологии, ориентирани към данни и ML:
- „Изчисления, ориентирани към данни – Архитектурни модели“
- Казус: Хибридна архитектура с Data Fabric и Data Mesh
- „Архитектурни съображения при създаване на софтуерни решения“
Въпреки това, въпросът дали винаги е по-добре да се използват ML модели вместо традиционната кодова логика е важна и провокираща размисъл тема, която си струва повече дискусия.
Какво казва ChatGPT
Е, просто за да се почувстваме готини, нека попитаме ChatGPT.
Така че, ако попитате най-добрите бизнес сценарии, ML моделите могат да се използват за разрешаване, ChatGPT може да изброи някои за вас:
И някои сценарии, които използват по-добре софтуерното инженерство:
При преглед на горните списъци, той не сравнява ябълка с ябълка, нито дава подробности. Някои специални случаи от първия списък (по-добре с ML моделите) могат да се поберат добре с помощта на подхода на софтуерното инженерство. Например приложение, което помага за рационализиране на проста верига за доставки с ограничени стъпки. Някои елементи във втория списък (по-добре със софтуерно инженерство) не са бизнес сценарии, а причини за използването на софтуерно инженерство, например „отстраняване на грешки и поддръжка“, „ефективност на разходите“, „ограничени хардуерни ресурси“.
За да обсъдим най-добре темата, нека първо проучим някои факти за заявки за данни, ML модели и софтуерно инженерство.
Някои факти за заявки за данни, ML модели и софтуерно инженерство
Относно бизнеса и случаите на употреба за разрешаване
Заявките за данни сами по себе си често имат ограничения. Език за заявки, например SQL, е създаден да работи върху конкретен вид хранилище или база данни, но не и за различни видове източници на данни. Така че заявките за данни обикновено се справят с бизнес случай, който просто трябва да работи върху един тип база данни или един файл с данни (таблици в Excel). В такива сценарии, където изискванията за данни са сравнително ясни и ограничени до един източник, заявките за данни могат да бъдат ефективни за извличане и манипулиране на необходимата информация.
Наскоро има някои нови технологии за съхранение на данни, които отговарят на нуждите от анализ и анализ на бизнес данни:
- Data lakehouse, съчетава предимствата на data lake и warehouse. Неговата заявка ще бъде по-мощна, за да помогне за разширяване на някои бизнес случаи.
- Графиката на знанието и нейният „език за заявки“, графата на знанието са много близки до връзките с данни в реалния свят, нейната заявка може да генерира по-полезни резултати за крайните потребители.
- Векторна база данни, която е тясно интегрирана с генеративни модели на ML. Ето някои добри въведения от точките „бизнес“ и „технологии“.
Софтуерното инженерство е мощно. С различни езици и инструменти за софтуерно инженерство можем да извършваме почти всички операции с данни от различни източници на данни, включително трансформиране на данни в желани формати и структури за анализ и генериране на визуализирани графики за крайни потребители. Софтуерното инженерство обаче има своите ограничения, поради зависимостта си от логиката, извлечена от компютърните езици.
Ако има неограничени (или огромно количество) вариации на данни, става невъзможно да се приложат единствено чрез логика на изчислителен код. В този случай ML моделите могат да дойдат на помощ.
Свързани с надеждността на бизнес резултатите:
Заявките за данни и софтуерното инженерство се основават на логика и могат да имат ясни, предвидими резултати.
Машинното обучение се корени в областта на статистиката и математическата оптимизация, а не в изрично програмирана логика. Въпреки че теорията за статистическото обучение е напреднала значително, включително концепции като компромис с отклонение, пренастройване, обобщаване и избор на модел, точността и надеждността на ML модела все още е обща грижа, което прави отговорния, прозрачен и обясним AI/ML задължителен за пазара.
Наскоро прочетох блог и думата на автора може да бъде пример за това, което имам предвид тук за разликата между заявките за данни и машинното обучение:
Относно жизнения цикъл и цената на решението:
Като цяло заявките за данни предлагат бърз подход за внедряване за генериране на бизнес резултати. Например, използване на SQL заявка за база данни или създаване на макроси за таблици в Excel за генериране на бизнес отчети.
Приложенията за софтуерно инженерство трябва да преминат през цикъл на издаване, който отнема повече време. Дори с приемането на гъвкава, CICD и автоматизация на DevOps в Cloud Native разработката, типичният цикъл на пускане на софтуер може да бъде от часове до дни или дори седмици.
ML моделите разчитат до голяма степен на висококачествени данни за обучение и трябва да преминат през цикъла на MLOps, включващ инженеринг на данни, обучение и оценка на модела преди внедряване и непрекъснат мониторинг за смекчаване на проблеми като изместване на данни или пристрастия. Този цикъл често отнема много време. Когато хората говорят за машинно обучение, те обикновено мислят за подход „добавяне на повече данни, увеличаване на размера на модела и обучение в продължение на месеци“. Докато непрекъснатото обучение може да помогне на ML моделите да се адаптират към продуктовата среда, не мисля, че тази технология може да узрее бързо с опасенията за надеждността и обяснимостта на ML технологията.
Някои правила, които трябва да имате предвид
Въз основа на горните факти, тук идвам с някои правила, които да ни помогнат:
- Ако прост бизнес казус може да бъде адресиран ефективно с помощта на заявки за данни, използвайте заявки за данни за решението.
- Ако точността и надеждността не са големи притеснения и/или вашият сценарий включва значителни вариации на данните, използването на ML модели може да бъде жизнеспособна опция.
- В противен случай, използвайки софтуерно инженерство.
- За сложни бизнес решения, общ подход е да се използват софтуерни кодове за интегриране на ML модели, заявки за данни и бизнес логика в цялостния бизнес поток. Тази интеграция позволява безпроблемна координация и взаимодействие между тези компоненти, позволявайки на решението да използва силните страни на всеки подход.
Интересувате ли се да опитате някои случаи?
Нека оценим някои реални бизнес сценарии, като използваме горните основни правила:
Случай 1:
Училището поддържа релационна база данни за съхраняване на информация за учениците. Има изискване за генериране на изчерпателен училищен отчет за всеки ученик, включително техния общ среден успех, подробности за техните семестриални часове и съответните оценки.
В този случай SQL заявките ще бъдат достатъчно бързи и добри.
Случай 2:
Една компания има множество наследени хранилища за данни и възнамерява да разработи виртуализиран слой върху тези хранилища за данни. Този виртуализиран слой ще осигури унифициран изглед на данните от тези различни магазини, ще позволи ефективни и ефективни процеси за анализ на данни.
В този случай софтуерното решение е най-доброто.
В повечето бизнес случаи трябва да мислим за използване на заявки за данни, софтуерно инженерство и ML модели заедно. Като този по-долу:
Случай 3:
Въз основа на пазара ИТ екип планира да създаде решение за автоматизиран гласов агент, за да помогне на клиентите да резервират хотелски стаи.
Архитектурата на решението може да бъде както следва:
При преглед на горния поток изглежда, че за прости сценарии, включващи ограничени текстови съобщения, Модел 2 може да бъде заменен с логика за софтуерно инженерство. Ако е така, включването на обработка на размито търсене за картографиране на текста на крайния потребител към конкретни обекти на базата данни или заявки става от съществено значение.
Използването на ML модели за размито търсене е било предмет на дискусия, както е посочено тук и тук. По мое мнение, когато се работи с бизнес казуси с широк спектър от входни данни и вариации, използването на ML модели за размито търсене вероятно би довело до по-добри резултати. ML моделите имат способността да обработват сложни модели и вариации в текстови данни, позволявайки по-точни и ефективни възможности за размито търсене.
Дискусии и заключения
Както обсъждах досега, общоприето е, че генеративни модели като ChatGPT могат да генерират заявки за данни или кодове. Това води до въпроса дали ML моделите в крайна сметка ще заменят изцяло заявките за данни и софтуерните кодове?
Мисля, че отговорът е не. Въпреки че ML моделите могат да помогнат на разработчиците да ускорят фазата на разработка чрез генериране на заявки за данни или софтуерни кодове, това не премахва необходимостта от използване на заявки за данни, софтуерни кодове или ML модели в действителното решение. Дискусията около тези компоненти остава от решаващо значение, тъй като крайното решение често включва безпроблемното им интегриране заедно за постигане на бизнес резултата.
Не съм против обмислянето на използването на AI/ML модели първо за бизнес решения, но искам да отбележа, че ML моделите не са магическа пръчка. Въпреки че машинното обучение предоставя мощни възможности за адресиране на сложни модели и вземане на решения, базирани на данни, то не е универсално решение. В някои случаи традиционните заявки за данни или софтуерното инженерство може да са по-подходящи за посрещане на бизнес изискванията. От съществено значение е внимателно да се преценят нуждите на всяка ситуация и да се избере най-подходящият подход.
Във всички случаи трябва да сме умни и иновативни, когато проектираме бизнес решение. Това включва разглеждане на всички ъгли и безпроблемно интегриране на множество технологии. Чрез използване на силните страни на различни технологии и внимателно оценяване на тяхната пригодност за конкретния проблем, бизнесът може да увеличи максимално своя потенциал за успех.
