Pirms sešiem mēnešiem es saņēmu Tas bija no mūsu CTO, spīdot ar tādu steidzamību, kas padara jūsu visu dienu mainīgu. Tā "Team, we need an AI strategy! Let's get a smart summarizer on the dashboard. What's the fastest we can get an MVP out with GPT-4o-mini?" Un jūs zināt ko? Tas bija aizraujoši. Mandāts bija vienkāršs: "AI par visu. Tagad." Kā izstrādātājs, mans prāts jau bija sacīkstes. Es zināju, ka līdz dienas beigām es varētu hack kopā prototipu. Sešos mēnešos, kas sekoja, mana komanda un es kļuva par funkciju rūpnīcu. Mēs piegādājām gudru meklēšanu, klientu apkalpošanas čatbotu, rīku, lai analizētu lietotāju atsauksmes, ģeneratoru mārketinga fluff... 15 funkcijas kopumā. Bet mēs neesam novatoriski.Mēs likām lamatas mūsu nākotnes pašiem. Mēs darījām to, ko viņi lūdza, bet ātrums radīja neredzamu tehnoloģiju parādu kalnu, kas gandrīz apturēja visu mūsu attīstības komandu. I daļa: Kā mēs apglabājām sevi tehnoloģiju parādā Šis jaunais tehnoloģiju parāds ir viltīgs. Tas neizskatās kā neskaidrs kods. Tas izskatās tīrs, vienkāršs un moderns. Bet tas bija laika bumbas sērija, katra no tām, pateicoties trim klusiem slepkaviem. Kļūda # 1: "Shiny New Toy" sindroms Mad rush, mēs paņēma jebkuru rīku, kas bija jaunākais vai vieglākais. par kopsavilkumu, mēs devāmies ar OpenAI, jo visi runāja par to. par chatbot, cita komanda jau bija spēlējis ar Anthropic, tāpēc mēs izmantojām to. par vienkāršu tulkošanas funkciju, kāds atrada kādu neskaidru API, kas bija netīrs lēti. Mums nebija plāna, nebija stratēģijas - tikai vēlme pēc ātruma. Atsevišķi katras funkcijas kods izskatījās labi. Bet, kad jūs palielinājāt, tas bija tīrs haoss. Mēs cīnījāmies ar dažādu API taustiņu, dažādu SDK un dažādu rēķinu, kas jāmaksā.Kad lietotājs sūdzējās, ka kopsavilkumi bija lēni, visa izmeklēšana sākās, lai noskaidrotu, kurš no mūsu pusotras desmit piegādātājiem nometa bumbu. Īstās sāpes skāra trīs mēnešus, kad viens no mūsu galvenajiem piegādātājiem nolēma divkāršot savas cenas naktī. Kļūda # 2: Fragile Prompts un spēle "Who Do We Blame?" Mēs izturējāmies pret mūsu uzaicinājumiem, it kā tie būtu tikai vēl viena līnija konfigurācijas failā. Tie nebija. Tie bija trausli, šūpojoši ieteikumi mašīnai, kuru mēs nesaprata. Tas darbojās kā šarms. Summarize the following user feedback into a single, positive-sounding sentence. Līdz vienam otrdienam tas nenotika. API piegādātājs bija nospiedis klusu atjauninājumu savam modelim. Bez brīdinājuma mūsu "pozitīvi skanīgie" kopsavilkumi sāka izklausīties... sarkastiski. Visa mūsu funkcijas loģika bija salauzta, bet ne viena mūsu koda līnija nebija mainījusies. Bez lintera, bez statiskās analīzes, nekas nevarēja mūs brīdināt. Klients sūdzētos par dīvainu, ārpuszīmju kopsavilkumu. Ko man vajadzēja darīt? Jūs nevarat piestiprināt pārtraukuma punktu slēgtā avota LLM. Jūs nevarat redzēt, kas notiek. Mana ikdienas rutīna kļuva par neapmierinošu aizdomu loku: 
 
 
 
 Vai tas ir ātri? labi, mēģināsim to atkārtot desmito reizi... Vai tas ir lietotāja ievads?Varbūt viņi ierakstīja kaut ko dīvainu... Edge gadījumu? Vai API ir tikai slikta diena? Laiks pārbaudīt savu statusa lapu vēlreiz... Tas nav inženierzinātne.Tas ir mūsdienu iedomāšanās.Es biju uz āķa par funkciju, kuras smadzenes bija pilnīga melnā kaste. Kļūda # 3: Izmantojiet Nuke, lai nogalinātu lidmašīnu Šis vienkāršais API zvanījums bija tukša pārbaude, un mēs tos rakstījām kā traki. Vienam no mūsu iekšējiem rīkiem - tikai atbalsta biļešu klasifikācijai - mēs izmantojām vienu no lielajiem, vispārējiem modeļiem. Mēs beidzot sapratu, ka mēs izmantojam super inteliģentu kodolu, lai nogalinātu muti. apgalvojumi — būtu bijuši desmit reizes ātrāki un simts reizes lētāki. bet "Funkcijas rūpnīcā" viss, kas bija svarīgi, bija izkļūt no durvīm. if/else 2. daļa: Mūsu ceļš ārā Aptuveni sešus mēnešus, lietas sāka sabrukt. Piespiest jaunu funkciju, lai izjauktu veco. Mūsu izmaksas bija visur. Un godīgi, komanda tika sadedzināts no cīņas ugunsgrēku. Mums bija apstāties, ieelpot, un faktiski sākt inženierijas risinājumu. 1. solis: Mēs vadījām “Tech Debt Triage” Mēs rezervējām sanāksmju telpu uz visu pēcpusdienu, uzstādījām visas 15 AI funkcijas uz tabulas un izklāstījām tās uz vienkārša 2x2 tīkla. (Nopietni, zīmējiet to uz balta plāksnes. tas ir spēļu mainītājs. es iesaku izveidot vienkāršu 2x2 režģa attēlu, lai to ievietotu šeit) 
 
 
 X-Axis: Cik daudz tas nozīmē biznesam? (Zems līdz augsts) Y-Axis: Cik daudz tehnisko neskaidrību tas ir? (Zems līdz augsts) Pēcpusdienā bija tik daudz skaidrības. 
 
 
 
 Top-Right (Augsta ietekme, augsts parāds): Piemēram, klientu tērzēšanas robots. Bottom-Right (Zema ietekme, augsts parāds): ka muļķīgs "smieklīgs fakts" ģenerators pieteikšanās ekrānā. Pārējie divi kvadranti: Mēs nolēmām tos atstāt vienatnē. 2. solis: Mēs izveidojam centralizētu "AI vārti" Mūsu pirmais lielais projekts bija novērst "pārāk daudz API" problēmu. Mēs izveidojām vienu, vienkāršu iekšējo pakalpojumu, ar kuru runā visas mūsu citas lietotnes. . (Vienkārša diagramma šeit ir ideāla: [Mūsu lietotne] -> [Mūsu AI vārtejs] -> [OpenAI, Anthropic utt.]) Tas nekavējoties atdeva mums spēku. 
 
 
 
 Kontrole: Mēs varam apmainīties ar pakalpojumu sniedzējiem vienā vietā, nezinot nevienu no citām lietotnēm. Ietaupījumi: Mēs izveidojām vienkāršu kešatmiņas sistēmu tieši vārtiņā. Sanity: Visi mūsu ieraksti, uzraudzība un brīdinājumi tagad ir vienā, pārvaldāmā vietā. 3. solis: Mēs izveidojām "Prompt bibliotēku" Mēs izveidojām viņiem vienkāršu bibliotēku - tā patiešām ir tikai tabula datubāzē, ar vēsturi, kas izsekota Git - kas uzglabā katru ieteikumu, ko izmantojam. Tagad mūsu lietojumprogrammas pirms zvanīšanas vienkārši lūdz bibliotēku par pareizo ielūgumu.Tas beidzot atdala "ko teikt" no "kā to teikt."Mūsu produktu vadītāji tagad var pielāgot un pārbaudīt ielūgumus savam sirds saturam, un viņiem nav nepieciešams iesniegt inženiertehnisko biļeti, lai to izdarītu. Tas ir par garo spēli Redziet, spiediens "pievienot AI" visam nepazūd, bet mums ir izvēle.Mēs varam turēt slapping funkcijas kopā virs API, ko mēs nekontrolējam, veidojot nākotni produktus, kas ir dārgi un neiespējami uzturēt. Vai arī mēs varam veikt reālu, dažreiz lēnāku, darbu. Mūsu jaunais noteikums ir vienkāršs: mēs novērtējam katru jauno funkciju ne tikai pēc tā, ko tā spēj darīt, bet arī pēc tās īpašībām. Risinot mūsu parādu un veidojot šos kontroles slāņus, mēs esam pārtraukuši būt pasūtītājiem funkciju rūpnīcā. long-term cost of ownership. Spēle nav tikai par A. Tas ir par Pārtrauciet barot rūpnīcu un sāciet veidot lietas, kas ilgst. Izmantojot Īpašums So, what's the worst AI tech debt you've stumbled into? I want to hear your war stories in the comments.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Contact Us Today at sales@saigontechnology.com

Drop me a message at 

Read My Stories

Šis audio ir izveidots stāsta oriģinālvalodā!

Pārāk ilgi; Lasīt

Get Free Unlimited IP Geo Data With IPinfo Lite

Es iznīcināju 15 AI funkcijas 6 mēnešos un tas gandrīz mūs salauza.

About Author

KOMENTĀRI

PAKARINĀT TAGUS

ŠIS RAKSTS TIKS PĀRSTRĀDĀTS

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps