기본적으로 스튜디오 내부에서는 세팅된 것을 가져다 쓰는 식
아키텍쳐는
DU Server - Orchestrator - Assistant(혹은 Studio)
형태라고 함
DU Server는 리눅스 OS에서 세팅되며 설치된 곳은 스펙이 좋아야 함. 아니면 부팅 중 멈추거나 제대로 동작하지 않는 현상이 많았다고 함(2021.04 버전 기준) => 2021.10부터는 그나마 안정적으로 작동한다는 말이 있음. [다만 표본이 부족하기 때문에 프로젝트 케이스가 더 생겨야 한다고 봄]
https://docs.uipath.com/document-understanding
관련 영상
1. https://youtu.be/U11il47YLqk
데이터매니저에서 학습용 영수증을 레이블링한 후 그 결과를 데이터셋으로 내보냄.
2. https://youtu.be/w6tUly5cxzM
AI Center에서 영수증 데이터셋을 임포트하여 ML 모델을 학습시켜서 로봇이 사용할 수 있는 ML 스킬을 생성함.
3. https://youtu.be/ommhluQ2FkY
로봇이 ML 스킬을 이용하여 영수증을 인식하고 그 결과를 concur에 입력함.
**** 어떤 과제가 '비싼' DU를 써야 하는가?
1. 기술적 측면
DU를 쓰는 과제는 일반적으로 Input이 불안정한 경우이다.
사내 Guide 정도로 끝낼 수 있는 과제라면 굳이 DU를 쓸 필요가 없으나,
고객으로부터 문서를 제출받아 특정 정책대상으로 분류하는 경우 등에는 쓸 수 있다.
가령 항공사에서 가족관계증명서, 주민등록등본 등을 통해 고객정보를 DB에 집어넣어야 하는 경우
폰 카메라로 마구잡이로 찍어 올리는 케이스가 많기 때문에 DU를 적용시킬 수 있다.
[실제 케이스이긴 하나 PI가 잘못된 경우라 생각된다. PI가 제대로 됐다면 이미 찍는 시점에서 스캔인식이 안 될 경우
업로드가 되지 않도록 input단에서 제한을 두어야 훨씬 깔끔하다.]
다만 이 경우도 학습을 굉장히 많이 시켜야 90% 가까운 확률에 도달할 수 있다.
특히 잘못 OCR 되는 케이스에 대해선 직접적으로 케이스를 잡아 replace를 시켜줘야 했다고 한다.
이런 보정까지 생각하면 아직은 기술적으로 학습에 대한 공수가 많이 들어간다고 볼 수 있다.
보통 대안으로 Abbyy의 Flexible Capture가 많이 거론되는데
Flexible Capture는 해상도를 맞추고 그에 대해 대략적인 좌표를 템플릿화 시켜놓는 개념이라
Input이 어느 정도는 정형화 되어야 한다. 내부 가이드 정도로 이를 해결할 수 있다면 Flexible Capture가 더 정답이다.
2. 영업적 측면
어떤 판매든 영업적, 정치적 측면이 있지만 DU는 특성이 두드러진다.
어쨌든 Flexible Capture 같은 방식보다 비싸기 때문에 '명분'이 필요하다.
그 명분은 대개 '4차 산업 혁명', 'AI 기술 도입' 같은 키워드이다.
직접적인 이해 관계자를 보면 Uipath 관계자 / 하청업체 수행사 / 고객사 관리자이다.
- uipath 관계자 : DU 기술이 아직 초기 시점이긴 하지만, 프로덕트로 나온 이상 일단 최대한 많이 팔아야 함.
- 하청업체 수행사 : 어디든 들어가면 좋음(개발자 입장은 다르겠으나 영업쪽에선 고려되지 않음)
- 고객사 관리자 혹은 의사결정자 : AI기술 도입 및 ROI 잡아서 실적 쌓기 좋겠다는 생각을 함
다만 고객사 관리자가 드물게 '우리 회사에 실질적인 도움이 돼야 한다'라고 하면서 직접 알아보는 경우
증빙 등을 고객으로부터 받아 보내주는 과제들이 많은지를 체크해볼 필요가 있다.
