접시를 찍고, 식사를 기록하다: 컴퓨터 비전 영양 파이프라인

이 솔루션이 필요한 경우

수동 음식 기록은 좋은 영양 습관이 사라지는 지점입니다. 옛 방식대로 치킨 카레 한 접시를 기록하려면, 사용자는 "치킨 카레"를 검색하고, 목록을 스크롤하고, 1인분 크기를 추측하며, 접시 위의 모든 항목에 대해 이 과정을 반복합니다. 이론상으로는 정확하지만 실제로는 포기되기 쉽습니다. 그 이유는 마찰이 동기 부여보다 크기 때문입니다.

카메라는 이 모든 과정을 단축시켜 줍니다. 휴대폰을 식사에 비추면 몇 초 후에 완전한 영양 정보가 포함된 일치하는 레시피를 기록할 준비가 됩니다. 이 패턴은 데이터 캡처가 사용자와 제품 가치 사이의 장벽이 될 때, 즉 "그냥 사진을 찍으세요"가 여러 단계의 수동 입력을 대체할 수 있을 때 그 가치를 발합니다. 이는 MicrocosmWorks의 AI 개발 서비스가 운영되는 영역에 정확히 들어맞는 문제입니다. 즉, 기술적으로 유능한 모델을 실제 마찰을 제거하는 파이프라인으로 전환하는 것입니다.

패턴 개요

사진은 네 단계를 거쳐 기록되고 정량화된 식사가 됩니다:

1. 캡처(Capture) — 사진 촬영 또는 이미지 선택; 업로드 전 기기에서 최적화.
2. 인식(See) — 비전 모델이 요리를 식별하며, 원시 레이블 대신 순위가 매겨진 검색어로 표현합니다.
3. 매칭(Match) — 이 검색어는 모델의 신뢰도를 상속받는 레시피 검색을 구동합니다.
4. 기록(Log) — 사용자가 레시피를 선택하고, 재료 및 영양 정보를 확인하고, 수량을 선택한 후 저장합니다.

핵심 아이디어: 비전과 검색은 서로 분리된 시스템이 아닙니다. 비전 모델은 검색 엔진이 원하는 것을 정확히 생성하도록 프롬프트되고, 검색 엔진은 모델이 생성하는 순서를 신뢰합니다. "우리가 보여주는 것"과 "사진에 있는 것"의 구별은 사라집니다.

참조 아키텍처

기기에서 최적화된 캡처. 이미지는 업로드 전 너비 약 512px로 크기 조정되고 JPEG 품질 약 40%로 압축됩니다. 비전 API에는 엄격한 크기 제한이 있으며, 원본 휴대폰 사진은 이 제한을 초과합니다. 서버는 최종 방어선으로 2MB 제한을 적용합니다.

인식(See): 모델이 검색어를 작성합니다. 이미지는 GPT-4o로 전송됩니다. 프롬프트는 "이것은 무슨 음식입니까?" 대신, 가장 신뢰할 수 있는 것부터 가장 넓은 범위의 대체 항목까지 순서대로 정렬된 다섯 가지 검색 가능한 레시피 이름을 요청합니다. 이때 토핑이 아닌 요리 전체의 이름을 지정합니다. 버거는 다음과 같이 반환됩니다:

["cheeseburger", "beef burger", "cheese burger", "hamburger", "burger"]

매칭(Match): 신뢰도가 관련성이 됩니다. 다섯 가지 이름은 Elasticsearch 레시피 인덱스를 대상으로 하는 하나의 "match-any" 검색으로 실행되며, 각 이름은 위치 가중치 부스트(50배에서 5배까지)를 가집니다. Cheeseburger라는 제목의 레시피는 일반적인 Burger보다 텍스트 통계가 아닌 모델의 더 높은 신뢰도 때문에 더 높은 순위를 차지합니다. 다섯 개의 OR-매치된 용어는 사용자가 거의 항상 무언가를 볼 수 있도록 하며, 부스트는 가장 적절한 추측을 맨 위로 올립니다.

기록(Log): 레시피 카드에서 정량화된 식사로. 일반 텍스트, 선별된 참조, 외부 FatSecret 참조로 저장된 재료는 하나의 깔끔한 목록으로 정규화됩니다. 사용자가 단위와 수량을 선택하면 칼로리와 매크로가 즉석에서 계산되고 식사는 로그에 저장됩니다.

원재료를 위한 두 번째 트랙. 검색할 요리가 없을 때, 전용 음식 인식 API는 영양 정보를 직접 반환합니다. 이는 일반 비전 모델보다 저렴하고 더 적합합니다. 앱은 의도에 따라 라우팅됩니다.

설계 결정 & 절충점

모델에게 다음 시스템의 입력 형식에 맞춰 프롬프트합니다. 자유 형식의 레이블이 아닌, 순위가 매겨진 검색 가능한 이름은 깔끔한 전달을 가능하게 합니다. 프롬프트는 계약의 일부이며, 우리는 이를 코드처럼 취급하고 텍스트처럼 취급하지 않습니다.

넓은 범위의 검색이 하나의 최적 추측보다 낫습니다. 다섯 개의 OR-매치된 용어는 "결과 없음"을 극적으로 줄여주지만, 목록 아래쪽에 가끔 느슨하게 관련된 결과가 나올 수 있습니다.

이미지를 있는 곳에서 최적화합니다. 기기 내 압축은 업로드 시간을 절약하고 API 제한을 피하며, 작은 클라이언트 측 종속성이라는 비용을 감수하지만 실제 모바일 환경의 안정성을 위해 가치가 있습니다.

적합한 모델을 적합한 작업에. 일반 비전 모델은 "이것은 무슨 요리입니까?"와 같은 질문에는 탁월하지만, "이 사과에 몇 칼로리가 있습니까?"에는 과도합니다. 두 가지 트랙은 비용을 제어하고 결과를 개선합니다.

솔직하게 기능 저하를 알립니다. 감지되지 않거나 일치하는 것이 없을 경우, 앱은 거짓말을 하거나 흐름을 끊는 대신 이를 명확히 알리고 수동 검색을 제공합니다.

속도 제한, 업로드 제한, 우아한 실패와 같은 안전장치들은 하부 인프라가 이를 위해 구축되었을 때만 유효합니다. 이는 MicrocosmWorks의 클라우드 인프라 서비스가 제공하도록 구축된 종류의 기반입니다.

사용 시기 — 및 피해야 할 시기

수동 캡처가 진정한 장벽이고, 사진이 다단계 입력을 대체할 수 있으며, 일치시킬 카탈로그가 있고, "즉시 충분히 좋은" 것이 "결국 완벽한" 것보다 나을 때 이 패턴을 사용하십시오. 이 패턴을 피해야 할 때는 도메인에 실험실 수준의 정확도가 필요하거나, 일치시킬 카탈로그가 없거나, 비전 API 비용이 얻을 수 있는 참여도보다 크거나, 입력이 시각적으로 너무 모호하여 안정적으로 식별할 수 없을 때입니다.

우리의 접근 방식

컴퓨터 비전에서 본능은 음식을 완벽하게 명명하는 모델을 쫓는 것입니다. 진정한 레버리지는 다른 곳에 있습니다. 즉, 비전 출력이 모든 하위 시스템과 어떻게 연결되는지에 있습니다. 모델이 검색 엔진의 언어를 말하도록 프롬프트하고, 모델의 신뢰도가 순위가 되도록 하며, 뒤에서 복잡한 것들을 정규화하면 이 모든 것이 몇 번의 탭으로 간소화됩니다. 승리는 더 똑똑한 분류기가 아니라, 이음새 없는 파이프라인입니다.

비슷한 것을 구축 중이신가요? MicrocosmWorks의 AI 에이전트 솔루션을 살펴보시거나 문의하여 파이프라인 아키텍처에 대해 논의해 보세요.

다른 블로그

1. 개인 맞춤형 레시피 검색: 다음에 무엇을 먹어야 할지 아는 검색 시스템

2. 마이크로서비스로 디지털 헬스 플랫폼 확장하기 

3. Apple Health 및 Health Connect 동기화하기