Създаване на продукт с генеративна изкуствена интелигентност: какво трябва да знаете на първо място

Въведение

Генеративната ИИ е лесна за изпробване, но значително по-трудна за превръщане в продукт, на който хората могат да разчитат. Един екип може да свърже езиков модел с чат интерфейс за няколко дни. Да се накара този интерфейс да обработва реални заявки от клиенти, да спазва разрешенията за достъп, да работи с фирмени данни и да се възстановява след грешни отговори е съвсем друго нещо.

За фирмите, които обмислят използването на генеративна ИИ за бизнес приложения, първото решение не е кои модели да използват. То е дали проблемът изобщо изисква нов продукт. Готовите ИИ инструменти може да покрият по-голямата част от нуждите, докато персонализираната реализация има повече смисъл, когато съществуващият софтуер не може да се приспособи към необходимия работен поток. Фирмите, които обмислят втория вариант, могат да се консултират с инженерите по генеративна ИИ на SysGears, за да проучат техническите изисквания на продукт, създаден специално за техния конкретен случай на употреба.

Един продукт с генеративна ИИ включва значително повече от просто поставянето на модел зад интерфейс с фирмената марка. Моделът може да се справя с езика, но останалата част от приложението определя от каква информация може да черпи, дали може да взаимодейства с друг софтуер и какво се случва, когато отговорът му не е точен. Тези решения влияят върху полезността на продукта точно толкова, колкото и самият избор на модел.

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

Това не са детайли, които могат да се поправят след пускането на пазара. Те оказват влияние върху архитектурата, необходимите инженерни усилия и разходите за разработка на ИИ, включително и върху това, което е необходимо, за да се поддържа работата на продукта. Бизнесът трябва да ги обмисли, преди да се ангажира с разработката, докато все още има възможност да се стесни обхватът или да се реши, че съществуващ инструмент би свършил работата.

Започнете с проблем, който изисква генеративен ИИ

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

Разграничението е важно още от самото начало. Генеративната ИИ си заслужава разходите, когато софтуерът трябва да разбере хаотичен, неструктуриран материал или да изготви нещо, което зависи от контекста. За задача, подчинена на фиксирани правила, обаче, обикновен скрипт често е по-евтин за изпълнение и по-лесен за доверие.

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

Това разделение на труда си заслужава да се запази ясно: нека моделът работи с езика, а предвидимите операции да се оставят на конвенционалния софтуер, където това е възможно.

Преди да започне каквато и да е разработка, определете какво всъщност трябва да се подобри. Може би на търговците ще им трябват по-малко минути, за да изготвят оферта; може би клиентите ще получават отговор, без да чакат оператор от отдела за поддръжка. В двата случая запишете как работи процесът в момента. В противен случай екипът може да се окаже в ситуация, в която празнува въвеждането на новия си ИИ интерфейс, без да знае дали той е улеснил работата.

Разработване или закупуване: колко контрол всъщност ви е необходим?

Решението „да се създаде или да се купи“ често се представя като избор между пълна собственост и удобство. На практика има няколко варианта между двете крайности.

Готовите ИИ инструменти са разумна отправна точка, когато даден бизнес се нуждае от познати функции като помощ при писане, обобщения на срещи, анализ на документи или изследвания с общо предназначение. Тези продукти обикновено изискват по-малко инженерна работа, а доставчиците им се грижат за голяма част от основната инфраструктура. Компанията може да провери дали служителите намират дадена функция за полезна, без първо да финансира специален проект за разработка.

Проблемите започват, когато един универсален инструмент трябва да се приспособи към процес, за който не е проектиран. Той може например да не комуникира с наследена база данни или да не прилага правилните разрешения за достъп, когато служителите имат различни роли. Резултатите от него може също да се наложи да бъдат преобразувани, преди друга бизнес система да може да ги използва. API-та и опциите за конфигуриране могат да помогнат за преодоляването на тези пропуски, но те не винаги ще покрият особеностите на вече установения работен поток.

Персонализиран AI продукт става по-обоснован, когато самият работен поток представлява конкурентно предимство, когато съществуващите продукти не могат да отговорят на съществено изискване или когато приложението се нуждае от тясна интеграция със собствени данни и вътрешни системи.

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

Последната разлика заслужава внимание. Разработването на персонализирано приложение за изкуствен интелект и разработването на нов модел за изкуствен интелект са различни начинания. Обучението на базов модел изисква значителни изчислителни ресурси, специализирана експертиза, подходящи данни и непрекъснати експерименти. Повечето компании нямат нужда да поемат тази тежест. Съществуващ модел, допълнен с извличане на информация от фирмени документи или внимателно проектиран достъп до инструменти, може да се окаже достатъчен.

Изберете архитектурата според работния процес

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

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

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

Извличането се нуждае от тестване само по себе си. Начинът, по който документите се разделят на части, може да повлияе на това, което системата намира, и дори един добър резултат от търсенето е безполезен, ако идва от източник, който потребителят не би трябвало да вижда. Правата за достъп на служителя трябва да се спазват и в процеса на извличане, вместо да бъдат пренебрегнати, защото търсенето случайно е извадило на повърхността материал с ограничен достъп. Самото приложение трябва да налага авторизацията. Не трябва да се разчита на модела да вземе това решение.

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

Един промпт и API на модела може да са всичко, от което се нуждае приложение с тесен обхват, поне в началото. Това зависи от това колко предсказуеми са входните данни и какво се очаква системата да направи с изходните си данни. Ако всеки отговор трябва да бъде сравняван с голям обем вътрешна документация, извличането може да стане необходимо; за по-проста задача то би могло просто да добави допълнителна натовареност.

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