Как да добавите AI функции към приложението си

За да добавите AI функции към приложението си, извикайте API на голям езиков модел (LLM) от сървъра си: изпратете му ясни инструкции плюс нужните данни и използвайте това, което се връща. Повечето полезни функции са един от четири модела — обобщаване, чат, извличане на структурирани данни и класификация — и всеки е от няколко десетки реда код, които AI платформа може да напише вместо вас. Работата, която решава дали функцията е добра, е около самото извикване: ключът остава на сървъра, разходът се контролира за всеки потребител и резултатът се проверява, преди да му се довери.

Четирите модела зад повечето 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 и никога не го изпълнявайте като код или заявка към базата.
• Дръжте човек в цикъла за всичко с последствия — изпращане на имейл, промяна на запис, възстановяване на плащане. Моделът изготвя; човек потвърждава.
• Защитавайте се от prompt injection. Документ или съобщение може да съдържа текст като „игнорирай инструкциите си“. Ограничавайте какво вижда моделът до това, което може да види текущият потребител, и не му давайте инструменти, които могат да извършат чувствителни действия, без вашият код първо да провери правата.
• Маркирайте AI съдържанието, за да знаят потребителите, че обобщението или предложението е генерирано и могат да го проверят.
• Обработвайте грешките спокойно. Доставчиците имат прекъсвания и лимити. Задайте таймаут, покажете ясно съобщение и оставете останалата част от приложението да работи.
• Следете какво изпращат потребителите. За свободни текстови полета помислете за стъпка за модериране и бъдете ясни в политиката за поверителност, че съдържанието се обработва от трета страна — AI доставчик.

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

Чести грешки

• Започване с общ чатбот, когато един бутон „Обобщи“ или „Категоризирай“ би помогнал на повече хора.
• Ключът във фронтенд кода или в публично хранилище.
• Изпращане на цялата база данни като контекст, което е бавно, скъпо и излага данните на други потребители.
• Доверие на свободния текст там, където схема или фиксиран набор етикети би направили резултата проверим.
• Без лимити за потребител, открити когато дойде първата фактура.

Добавяне на AI функции с Mythex

В Mythex добавяте AI в собственото си приложение, като поискате в чата и използвате собствения си ключ от доставчика. Запазете ключа като тайна на проекта — когато агентът има нужда от него, Mythex показва карта с тайни в чата, така че не поставяте ключа в разговора — а агентът пише серверния маршрут, промптовете и интерфейса. AI използването на приложението ви се таксува от доставчика ви, отделно от кредитите на Mythex, които харчите за създаване. Документацията има стартов промпт в добавяне на AI функции със собствени API ключове.

Въпроси