- • 내용을 얹는건 제조사, 디자인은 이마트에서
- • 디자인 파일과 품족제조보고서, 원산지증명서, 셀링포인트 증빙과 관련된 파일들을 전달
- 받고 품목제조보고서와 작성된 식품유형이나 영업소의 소재지, 품목보고번호 등을 비교
- 함
- • 상품 하나 당 해당하는 파일들이 전부 있음
- • 원재료명이 제대로 작성되어있는지, 또한 순서도 동일하게 작성되어있는지 확인
- • 괄호 안의 원산지 내용에 대한 증명서도 따로 받아야 함(e.g. 양파(국내산))
- • 품목제조보고번호 --> Key값 ('요청하는 품목제조보고번호' = (포장지) '품목보고번호')
- ㄴ DEX: RPA와 OCR 인식에는 문제가 없음. DB로 저장해야함. 뒤에서 매칭하는데 매칭
- 이 되지 않는 부분을 관리하시는 분이 체크를 해야함. 품질 관리하는 분의 역할을 전부 대
- 체할 수는 없으나, 데이터를 꺼내서 DB로 집어 넣고 이를 비교해서 사람이 체크해야 하는
- 부분들만 보는 건 가능하다. 단, 원산지 증명서를 따로 확인해야하는 품목의 경우는 설계
- 가 까다로울 수 있음
- • 또한, 볶음춘장과 같은 혼합 소스 --> 간혹 이름이 다르게 들어가 있는 경우도 있고 별도
- 의 재조업체에서 제조시 만든 원료의 표시사항도 확인이 필요하고 상위 5개의 품목만 골
- 라서 작성함
- ㄴ DEX: 괄호와 대괄호와 같은 표현들은 따로 시스템 프롬프트로 따줘야 한다. 그냥 LLM
- 에 넣게 되면 일반적인 RAG나 AI로 하면 인식이 잘 되지 않음. 가능하나 설계 고려 요소
- 가 많음
- • 근거 자료를 계속 보관할 의무는 없고, 신상품을 개발 할 때 기준에 제대로 얹혔는지만
- 봐야하는거기 때문에, 모든 자료를 저장해두고 유지관리 할 필요 없음
- • 표시관로에 위반하는 것들은 금방 찾을 수 있음 -> 대부분 눈에 금방 띄기 때문
- ㄴ DEX : 인쇄 후 스캔한 PDF의 경우, 원본이 흐리면 OCR에서 읽는데 오류가 발생할 것
- 같음 -> 자료 해상도도 중요한 문제
- • 고추간짜장 같은 까다로운 케이스(복합원재료 포함) 비율은 7/ 쉬운 케이스 3 정도의 비
- 율을 가지고 있음
- • power apps+Power builder/ RPA Apps
- DEX : OCR로 key data 끌고 오는건 99%가 다되고, 단어가 같고 틀리고를 판단하는건 커스
- 터마이징 개발이 되어야 함 + 칠레 vs (영문) 칠레의 비교도 가능함 -> 번역API 사용