Како да додадете AI функции во вашата апликација

За да додадете AI функции во вашата апликација, повикајте API за голем јазичен модел (LLM) од вашиот сервер: испратете му јасни упатства плус релевантните податоци и искористете го она што се враќа. Повеќето корисни функции спаѓаат во еден од четири обрасци — сумирање, разговор, извлекување структурирани податоци и класификација — а секој е неколку десетици линии код што AI алатка за изградба може да ги напише за вас. Работата што одлучува дали функцијата вреди е околу самиот повик: клучот за API да остане на серверот, контролата на трошоците по корисник и проверката на излезот пред да му верувате.

Четирите обрасци зад повеќето AI функции

Извлекувањето и класификацијата често се највредните и најневидливите. Тие тивко му заштедуваат на некој неколку минути на секој запис, а бидејќи излезот има фиксна форма, може автоматски да се провери. Разговорот е највидлив, но најтешко се поставува правилно и има свој водич: како да изградите AI чатбот апликација.

Како се вклопува во вашата апликација

Секој образец има иста форма:

1. Корисникот дејствува — кликнува „Сумирај“, прикачува датотека, испраќа порака.
2. Фронтендот го повикува вашиот сопствен сервер, не AI даваточот.
3. Серверот го гради барањето: системски упатства, внесот на корисникот и податоците што моделот ги треба од вашата база — само податоци што овој корисник смее да ги види.
4. Серверот го повикува LLM API со клуч зачуван во променлива на околината.
5. Серверот го проверува одговорот — валиден JSON, позната ознака, разумна должина — и го зачувува или враќа.
6. Фронтендот го прикажува, со текст што тече за подолги одговори.

Клучот е на серверот во чекор 4 и никогаш не стигнува до прелистувачот. Ако концептот API ви е нов, што е API е кратко објаснување, а како да користите LLM API ги опфаќа токените, моделите и клучевите подетално.

Избор на даварател и модел

Главните даватели — OpenAI, Anthropic, Google и други — нудат текстуални API со слична структура. Корисни прашања при изборот:

• Квалитет за вашата задача. Пробајте неколку вистински примери од вашата апликација на два или три модела. Разликите често се појаснуваат на вашите податоци, а не на општите мерења.
• Големина наспроти цена. Даваточите нудат поголеми, поспособни модели и помали, поевтини и побрзи. Класификацијата и едноставното извлекување често добро функционираат на мал модел; долгото расудување или нијансираното пишување може да бараат поголем.
• Структуриран излез. За извлекување и класификација, претпочитајте функција на API што го натера моделот да врати JSON според шема што ја давате, наместо да парсирате слободен текст.
• Ракување со податоци. Прочитајте ги условите на даваточот дали влезните податоци од API се чуваат или се користат за обука, и дали тоа одговара на податоците што ви ги даваат корисниците.
• Лимити. Новите сметки често имаат пониски лимити на брзина; проверете ги пред лансирање.

Имињата на моделите и цените често се менуваат, па кодот треба името на моделот да го чита од конфигурација, а не да го впишува на многу места.

Додавање функција, чекор по чекор

Земете конкретен пример: мал CRM каде секој контакт има долга историја на белешки.

1. Зачувајте го клучот. Создајте клуч во контролната табла на даваточот и зачувајте го како серверска тајна, на пример OPENAI_API_KEY или ANTHROPIC_API_KEY.

2. Побарајте една тесна функција:

Додај копче „Сумирај“ на страницата со контакти. На серверот, испрати ги последните 20 белешки на контактот до [PROVIDER] со тајната [ENV_NAME], со упатство да напише три точки: моментален статус, отворени прашања и следен чекор. Вклучи само белешки што најавениот корисник смее да ги види. Прикажи состојба на вчитување и покажи „Не можеме да сумираме во моментов“ ако повикот не успее. Зачувај го резимето со време и никогаш не ја испраќај клучот до прелистувачот.

3. Додајте извлекување таму каде штеди куцање:

Кога корисникот ќе залепи потпис од е-пошта во полето „Брзо додавање“, повикај го [PROVIDER] на серверот и врати JSON со име, компанија, работна позиција, е-пошта и телефон, користејќи ја функцијата за структуриран излез на даваточот. Провери го JSON-от на серверот, пополни ја формата за нов контакт со него и дозволи корисникот да уреди пред зачувување. Остави полињата празни наместо да погодуваш.

Важно е „дозволи му на корисникот да уреди пред зачувување“: моделот предлага, а човекот одлучува.

4. Класифицирајте во позадина:

Кога ќе пристигне нов билет за поддршка, класифицирај го точно во една од категориите: наплата, грешка, барање за функција, пристап до сметка, друго. Користи мал, јефтин модел. Ако одговорот не е една од тие ознаки, зачувај „друго“. Прикажи ја ознаката како уредлива ознака.

5. Тестирајте со неуреден вистински материјал — долги белешки, празни белешки, други јазици, потпис без телефонски број — и погледнете дваесет излези еден до друг пред објавување.

Како да пишете упатства што функционираат

Упатствата што ги испраќате со секое барање (често наречени системски промпт) се местото каде доаѓа квалитетот.

• Кажете за кого е и што е добро. „Резимеата ги чита продавач за 10 секунди пред повик“ му дава на моделот цел.
• Фиксирајте го форматот. Точен број точки, ограничување на должината, полиња, ознаки.
• Кажете што да прави кога не е сигурен. „Ако белешките не спомнуваат следен чекор, напиши „Нема евидентиран следен чекор““. Ова ги намалува измислените одговори.
• Дајте два-три примери на добар влез и излез за извлекување и класификација.
• Чувајте ги упатствата одвоено од содржината на корисникот и јасно означете ја содржината на корисникот, за моделот да може да ги разликува.

Чувајте ги промптите во датотеки во вашата кодна база, за да се верзионираат и да се прегледуваат како и секој друг код.

Контрола на трошоците

LLM API наплаќаат по токени — мали парчиња текст — и за она што го испраќате и за она што се враќа. Трошокот расте со количината на контекст по барање, помножена со тоа колку често се извршува. Практични контроли:

• Испраќајте само она што е потребно. Последните 20 белешки, а не целата историја. Скратете или поделете долги документи.
• Користете најмалиот модел што ја работи работата. Тестирајте пред да го земете најголемиот како стандарден.
• Ограничете ја должината на излезот со поставката за максимален број токени на API-то.
• Кеширајте резултати. Зачувајте резиме и регенерирајте го само кога ќе се промени изворот, наместо при секое отворање на страница.
• Ограничете по корисник. Дневен лимит по сметка или план ќе спречи еден тежок корисник или една скрипта да ја зголеми сметката.
• Ограничете ја брзината на крајната точка како и секоја друга скапа рута.
• Поставете буџет или известување во контролната табла на даваточот и проверувајте ја употребата неделно по лансирањето.
• Следете ја потрошувачката на токени по функција за да знаете која функција колку чини.

Ако AI функциите се срце на вашиот производ, вклучете го нивниот тековен трошок во цената, наместо да го апсорбирате.

Безбедност и доверба

Излезот на AI е веројатносен. Може да биде погрешен, а да звучи сигурно, и може да биде насочен од текстот што го чита. Градете со тоа на ум:

• Третирајте го излезот како непроверен влез. Проверете ја структурата, избегнете ја содржината пред прикажување како HTML и никогаш не ја извршувајте како код или како database прашање.
• Задржете човек во процесот за сè што има последици — испраќање е-пошта, менување запис, враќање пари. Моделот пишува нацрт; една личност потврдува.
• Заштитете се од prompt injection. Документ или порака може да содржи текст како „игнорирај ги твоите упатства“. Ограничете што може да види моделот на она што тековниот корисник смее да го види и не му давајте алатки што можат да извршат чувствителни дејства без вашиот код прво да ги провери дозволите.
• Означете ја AI содржината за корисниците да знаат дека резимето или предлогот е генериран и да можат да го проверат.
• Ракувајте со неуспеси елегантно. Даваточите имаат прекини и ограничувања на брзината. Поставете време на чекање, прикажете јасна порака и нека остатокот од апликацијата продолжи да работи.
• Следете што испраќаат корисниците. За отворени текстуални полиња, размислете за чекор на модерирање и јасно напишете во политиката за приватност дека содржината ја обработува трета страна, AI давател.

Пошироката листа проверки е во безбедносната листа за апликации направени со AI.

Чести грешки

• Почнување со општ чатбот кога едно копче „Сумирај“ или „Категоризирај“ би им помогнало на повеќе луѓе.
• Клучот во фронтенд кодот или во јавен репозиториум.
• Испраќање на целата база како контекст, што е бавно, скапо и ризикува да ги изложи податоците на други корисници.
• Верување во слободен текстуален излез таму каде шема или фиксен сет ознаки би го направиле проверлив.
• Нема лимити по корисник, откриени кога ќе стигне првата фактура.

Додавање AI функции со Mythex

Во Mythex, AI во вашата апликација го додавате со барање во разговорот, користејќи го вашиот сопствен клуч од даваточот. Зачувајте го клучот како тајна на проектот — кога агентот ќе ни треба, Mythex прикажува картичка со тајни во разговорот, така што не го лепите клучот во разговорот — а агентот ја пишува серверската рута, промптите и интерфејсот. AI употребата на вашата апликација ја наплаќа вашиот даватель, одвоено од Mythex кредитите што ги трошите при градење. Во документацијата има стартен промпт во додавање AI функции со свои API клучеви.

Прашања