Når du har brug for dette
Manuel madregistrering er der, hvor gode ernæringsvaner dør ud. For at registrere en tallerken chicken curry på den gamle måde, søger en bruger på "chicken curry," ruller ned ad en liste, gætter en portionsstørrelse og gentager for hvert element på tallerkenen. Det er præcist i teorien og opgivet i praksis — friktionen overstiger motivationen.
Kameraet forenkler det hele. Peg en telefon mod et måltid, og få sekunder senere er matchende opskrifter med fuld ernæringsindhold klar til at blive logget. Dette mønster er berettiget, når dataindsamling er barrieren mellem brugere og dit produkts værdi — når "bare tag et billede" kan erstatte en manuel indtastning i flere trin. Det er den slags problem, der passer perfekt ind i det område, hvor MicrocosmWorks' AI-udviklingstjenester opererer: at omdanne en teknisk kapabel model til en pipeline, der fjerner reel friktion.
Mønsteroversigt
Et billede bliver til et logget, kvantificeret måltid i fire trin:
- Indfangning — fotografer eller vælg et billede; optimer det på enheden før upload.
- Se — en visionmodel identificerer retten, udtrykt som rangordnede søgetermer frem for rå etiketter.
- Match — disse termer driver en opskriftssøgning, hvis rangering arver modellens tillid.
- Log — brugeren vælger en opskrift, ser ingredienser og ernæring, vælger en mængde og gemmer den.
Hovedideen: vision og søgning er ikke separate systemer skruet sammen. Visionmodellen prompts til at producere præcis det, søgemaskinen ønsker, og søgemaskinen stoler på den rækkefølge, modellen producerer. Forskellen mellem "hvad vi viser" og "hvad der er på billedet" forsvinder.
Referencearkitektur
Indfangning, optimeret på enheden. Billeder ændres til ~512px bredde og komprimeres til ~40% JPEG-kvalitet før upload — vision API'er har stramme størrelsesgrænser, og et råt telefonfoto overskrider dem let. Serveren håndhæver en 2MB grænse som sikkerhedsforanstaltning.
Se: modellen skriver søgningen. Billedet sendes til GPT-4o. Prompten beder om fem søgbare opskriftsnavne, arrangeret fra mest sikre til bredeste fallback – navngivning af retten som helhed, ikke dens toppings – i stedet for "hvad er dette for mad?" En burger returnerer som:
["cheeseburger", "beef burger", "cheese burger", "hamburger", "burger"]Match: tillid bliver relevans. De fem navne køres som én "match-any" søgning mod et Elasticsearch-opskriftsindeks, hver med et positionsvægtet boost (50× ned til 5×). En opskrift med titlen Cheeseburger rangerer højere end en generisk Burger, ikke på grund af tekststatistik, men fordi modellen var mere sikker. Fem OR-matchede termer betyder, at brugeren næsten altid ser noget; boosts skubber det bedste gæt til toppen.
Log: opskriftskort til kvantificeret måltid. Ingredienser – lagret som almindelig tekst, kuraterede referencer og eksterne FatSecret-referencer – normaliseres til én ren liste. Brugeren vælger en enhed og mængde; kalorier og makroer beregnes med det samme, og måltidet gemmes i deres log.
Et andet spor for rå ingredienser. Når der ikke er nogen ret at søge efter, returnerer en dedikeret madgenkendelses API ernæringsindhold direkte — billigere og bedre egnet end en generel visionmodel. Appen ruter baseret på intention.
Designbeslutninger og afvejninger
Prompt modellen til det næste systems inputformat. Rangordnede, søgbare navne – ikke fritekstetiketter – gør overleveringen ren. Prompten er en del af kontrakten; vi behandler den som kode, ikke som tekst.
Et bredt net slår et enkelt bedste gæt. Fem OR-matchede termer reducerer "ingen resultater fundet" dramatisk, på bekostning af lejlighedsvise løst relaterede resultater længere nede på listen.
Optimer billedet, hvor det er. Enhedskompression sparer uploadtid og undgår API-grænser, på bekostning af en lille klient-side afhængighed — det værd for pålidelighed i den virkelige verden på mobilen.
Rigtig model, rigtigt job. En generel visionmodel udmærker sig ved "hvad er dette for en ret?" og er overkill for "hvor mange kalorier er der i dette æble." To spor styrer omkostningerne og forbedrer resultaterne.
Degrader ærligt. Ingen genkendelse, intet match — siger appen det tydeligt og tilbyder manuel søgning i stedet for at foregive eller afbryde flowet.
Beskyttelsesforanstaltninger som rate limiting, upload-grænser og elegant fejlhåndtering holder kun, når den underliggende infrastruktur er bygget til det — den slags fundament, som MicrocosmWorks' cloud-infrastrukturtjenester er bygget til at levere.
Hvornår det skal bruges – og hvornår det skal undgås
Brug dette mønster, når manuel registrering er den virkelige barriere, et billede kan erstatte indtastning i flere trin, du har et katalog at matche imod, og "godt nok, med det samme" slår "perfekt, til sidst." Undgå det, når domænet kræver laboratoriekvalitetsnøjagtighed, der ikke er et katalog at matche imod, vision API-omkostninger opvejer den opnåede engagement, eller input er for visuelt tvetydige til at identificere pålideligt.
Vores tilgang
Instinktet med Computer Vision er at jagte en model, der navngiver maden perfekt. Den virkelige fordel ligger et andet sted: i hvordan visionoutputtet forbinder sig til alt nedstrøms. Prompt modellen til at tale søgemaskinens sprog, lad dens tillid blive rangeringen, normaliser rodet bag kulisserne — og det hele falder sammen i et par tryk. Sejren er ikke en smartere klassificator; det er en pipeline uden sømme.
Bygger du noget lignende? Udforsk MicrocosmWorks' AI-agentløsninger eller kontakt os for at drøfte din pipelinearkitektur.
Andre blogs
1. Personaliseret opskriftssøgning: Genfinding der ved, hvad du skal spise næste gang
2. Skalering af en digital sundhedsplatform med Microservices
3. Synkronisering af Apple Health & Health Connect
