노타
4.0 (35)노타
경력근거: AI 최적화 기술을 통해 AI의 일상화를 선도하는 기업
수집일 없음
※ 실제 산출물이 아닌 AI 예측 시안입니다.
노타 넷츠프레소 Forward Deployed Engineer 는 고객사의 실제 모델과 타깃 하드웨어 환경을 마주하며 정확도와 지연시간과 메모리 제약을 분석해 가장 적합한 최적화 전략을 실행하는 자리라서, 실험을 한 번 더 돌리는 일보다 이미 쌓인 기록을 고객이 정한 기준과 맞춰 대는 일이 현장에서 먼저 막힙니다. 고객사 담당자가 남기는 벤치마크 CSV 와 컴파일 로그는 지연이 초와 밀리초로 섞여 적히고 캘리브레이션 데이터셋이 비어 있는 실험이 끼어 있는 실제 업무 파일이라, 잘 정리된 표를 가정한 도구는 첫날에 멈춥니다. 이 포트폴리오는 화면을 만들지 않고 담당자가 터미널에서 바로 돌려 보는 명령줄 도구로 기능을 검증하며, 반복되는 판정 과정을 규칙 파일로 떼어 내 다음 고객사에 갈아끼우는 자산화까지 이어 둡니다. 이 포트폴리오는 흩어진 기록의 단위 정규화와 규칙 판정과 인용 검증과 문서 생성 기술을 보여주며, NPU 백엔드 컴파일러 내부나 양자화 알고리즘 설계 같은 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
고객의 모델 구조와 제약 조건을 분석해 가장 적합한 최적화 전략을 실행하는 자리입니다. 기준 수치와 측정값을 단위까지 맞춰 대조하고 어느 조합이 조건을 만족하는지 가르는 일이 그 분석의 마지막 단계와 정확히 겹칩니다.
고객 현장에서 발견한 요구사항과 기술 이슈를 정리해 전달하는 것이 이 포지션의 핵심입니다. 컴파일 로그의 폴백 연산자를 근거로 인용하면서도 회의에 올릴 문장으로 옮겨 주는 보고서가 그 자리와 직접 닿습니다.
반복적으로 발생하는 최적화 워크플로우를 자동화 도구와 스크립트로 자산화하는 일이 주요 업무에 그대로 적혀 있습니다. 판정 규칙과 문서 생성 골격을 규칙 파일로 떼어 다음 고객사에 갈아끼우는 구조가 이와 맞습니다.
계약된 고객사의 온디바이스 제품팀이 이미 쌓아 둔 파일 두 종류, 즉 양자화 방식과 타깃 하드웨어를 바꿔 가며 돌린 최적화 실험 기록 묶음과 사내에서 정한 수용 기준표를 읽어 조합마다 수용 여부를 판정하는 명령줄 도구입니다. 터미널에서 optreport build 명령에 두 경로를 주면 기준 항목마다 충족과 미달과 조건부 수용과 판정 보류가 갈리고, 판정마다 기록의 값 인용과 회신 문장 초안이 붙은 최적화 결과 보고서 Markdown 파일이 생기며, 표준출력에는 조합별 판정 요약 표가 찍힙니다. 판정은 단위를 맞춘 뒤의 수치 비교와 재현 정보 존재 여부로 규칙이 내리고, 지연 기준은 넘겼지만 컴파일 로그에 CPU 폴백 연산자가 남은 조합은 조건부 수용으로 돌려 그 연산자 이름을 그대로 붙입니다.
양자화 방식과 타깃 하드웨어를 바꿔 가며 서른 번 넘게 돌린 결과가 사람마다 다른 CSV 와 컴파일 로그로 공유 폴더에 흩어져 있어, 양산 검토 회의 전날 밤에 어느 조합이 사내 수용 기준을 만족하는지 손으로 표를 맞춰 보던 고객사 온디바이스 제품팀 담당자입니다. 늘 남기던 벤치마크 CSV 와 로그 폴더와 기준표 엑셀을 그대로 건네고 터미널에서 명령 한 번을 쳐서, 충족과 미달과 판정 보류가 근거 값과 함께 갈린 보고서 초안을 받아 문장만 다듬어 회의에 올리고 싶은 사람입니다.
수용 기준의 목표 수치와 실험 기록의 측정값은 둘 다 표에 적힌 숫자라서, 어느 조합이 기준을 만족하는지를 담당자의 기억이 아니라 단위 정규화와 수치 비교 규칙으로 가르면 검토 회의 자료의 골격이 자동으로 서고, 담당자는 재현 정보가 빠진 실험과 연산자 폴백이 걸린 조합에만 시간을 쓰게 된다는 가정입니다.
고객사에서 받는 형태의 수용 기준표 엑셀과 실험 기록 CSV 더미를 놓고 터미널에서 optreport build 명령을 치면, 조합마다 충족과 미달과 조건부 수용과 판정 보류를 기록의 값 인용과 함께 가르고 재현 정보가 빠진 실험을 판정 보류 절로 모은 최적화 결과 보고서 Markdown 파일이 생기며 표준출력에 조합별 판정 요약 표가 찍히는 완결품입니다. 만드는 덩어리는 단위 정규화를 포함한 대조 판정 규칙과 Markdown 문서 생성 둘뿐이고 화면과 서버와 배포가 없어 평일 닷새에 혼자 끝나는 범위이며, 데이터는 실제 고객 자료 대신 작성자가 만든 더미를 씁니다.
담당자가 로그를 눈으로 훑어 폴백 연산자를 표에 적어 넣던 단계를 없애도 되는지 확인하는 계층입니다. scan 하위 명령이 컴파일 로그 원문에서 CPU 폴백 연산자와 변환 실패 원인을 뽑아 정해진 JSON 으로 정규화하고, 손으로 정리한 목록을 정답으로 두어 재현율과 정밀도를 계산하며, 놓친 연산자와 잘못 만들어낸 항목을 사례 목록으로 남깁니다.
기준 항목 어휘와 백엔드 표기를 규칙 파일로 분리해, 다른 고객사의 수용 기준표와 벤치마크 형식에도 같은 골격을 갈아끼워 돌려 보는 확장입니다. 두 번째 기준표로 실제 실행하고 교체에 든 시간을 기록해 재사용 블록의 설명서로 남깁니다.
수용 기준 11항목과 최적화 실험 기록 34건을 놓고 터미널에서 optreport build 명령을 치면, 조합마다 충족과 미달과 조건부 수용과 판정 보류가 근거 값 인용과 함께 갈린 최적화 결과 보고서 Markdown 파일이 생기고 표준출력에 조합별 판정 요약 표가 찍히는 흐름을 시연합니다.
지연이 초로 적힌 행과 메모리가 GB 로 적힌 행과 기준 단위가 비어 있는 항목과 캘리브레이션 데이터셋이 없는 실험과 run_id 가 겹치는 행을 섞은 입력 30종을 넣어도 도구가 멈추지 않고 판정 보류로 분리하는 것을 보입니다. 다만 입력과 정답을 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
같은 입력에서 두 번 실행하면 문자까지 같은 파일이 나오는 결정론을 테스트로 보이고, 필수 기준 가운데 미달이 하나라도 있으면 종료 코드로 알려 회의 자료로 올리기 전에 사람이 멈추게 합니다.
2주차에는 컴파일 로그 원문에서 뽑은 폴백 연산자를 담당자가 손으로 적어 둔 목록과 대조합니다. 정답 52건 가운데 45건을 그대로 찾아 재현율 약 87%, 잘못 만들어낸 항목 4건으로 정밀도 약 92% 입니다. 정답이 로그에 그대로 있는 문자열이라 대조가 규칙으로 끝납니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 보고서 품질은 고객사의 실제 벤치마크 기록과 컴파일 로그와 담당자의 검토가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 지연이 초로 적힌 행과 메모리가 GB 로 적힌 행과 기준선이 비어 있는 실험과 run_id 가 겹치는 행을 더미에 일부러 섞어 두었습니다.
판정이 틀리면 기준 미달인 조합이 충족으로 적힌 보고서가 양산 검토 회의에 올라갑니다. 단위를 확정할 수 없는 항목은 억지로 판정하지 않고 판정 보류로 돌리며, 폴백 연산자가 남은 조합은 조건부 수용으로 두고 그 연산자 이름을 그대로 붙입니다.
실제 고객사는 백엔드 이름과 기준 항목 표기가 저마다 달라 한 곳에서 맞춘 규칙이 다음 곳에서 그대로 돌지 않습니다. 규칙 파일 분리를 3주차 과제로 두었고, 그래도 남는 차이는 도입 단계에서 담당자와 맞춰야 합니다.
이 포트폴리오는 흩어진 기록의 단위 정규화와 규칙 판정과 인용 검증과 문서 생성 기술을 보여주며, NPU 백엔드 컴파일러 내부나 양자화 알고리즘 설계 같은 도메인 전문성은 주장하지 않습니다. 모르는 부분은 면접에서 모른다고 말합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 온디바이스 제품팀이 양산 검토 회의 제출 기준으로 정해 둔 수용 기준표 엑셀의 시트 추출본입니다. 명령줄 도구가 판정의 기준으로 삼는 표이고, 보고서의 절 구분도 여기 항목 순서를 따릅니다. 단위가 빠진 항목과 수치로 바꿀 수 없는 문구와 겹치는 항목 번호를 그대로 두어, 잘 정리된 기준표만 다루는 도구가 아님을 보입니다. 전부 작성자가 만든 더미입니다.
| criterion_id | row_kind | category | criterion_text | target_raw | comparator_raw | unit_raw | mandatory_raw | target_hw_raw |
|---|---|---|---|---|---|---|---|---|
| A | section_header | accuracy | A. 정확도 요구 | — | — | — | — | — |
| A-1 | criterion | accuracy | 표준 평가셋에서 원본 대비 top-1 정확도 하락 1.0%p 이내 | 1.0 | 이내 | %p | 필수 | NPU-A v2 |
| A-2 | criterion | accuracy | 저조도 평가셋에서 정확도 하락 1% 이내 | 1 | 이내 | — | M | NPU-A v2 |
| B | section_header | latency | B. 지연 요구 | — | — | — | — | — |
| B-1 | criterion | latency | 단일 프레임 추론 p95 지연 30ms 이하 | 30 | 이하 | ms | 필수 | NPU-A v2 |
아래 JSON Schema에 맞는 수용 기준표 행을 25건 더 만들어 주세요. {"type":"object","properties":{"criterion_id":{"type":"string"},"row_kind":{"type":"string","enum":["criterion","section_header","note"]},"category":{"type":["string","null"]},"criterion_text":{"type":"string"},"target_raw":{"type":["string","null"]},"comparator_raw":{"type":["string","null"]},"unit_raw":{"type":["string","null"]},"mandatory_raw":{"type":["string","null"]},"target_hw_raw":{"type":["string","null"]}},"required":["criterion_id","row_kind","criterion_text"]} 전부 가상 더미로 만들고, 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어 주세요. 첫째 unit_raw 가 null 이라 퍼센트인지 퍼센트포인트인지 가릴 수 없는 항목 3건, 둘째 target_raw 가 비어 있고 협의·범위 같은 말로만 적힌 항목 3건, 셋째 criterion_id 가 다른 행과 겹치는 항목 2쌍, 넷째 mandatory_raw 가 필수·M·권장·선택·빈 문자열·null 로 제각각인 행, 다섯째 unit_raw 가 MB 와 MiB 와 GB 로 섞인 메모리 항목 3건, 여섯째 target_hw_raw 의 표기가 NPU-A v2 와 npu a v2 와 NPU_A2 로 흔들리는 행 4건, 일곱째 row_kind 가 section_header 와 note 인 행이 기준 사이에 끼어 있는 경우 3건. JSON 배열만 내주세요.{"type":"object","properties":{"criterion_id":{"type":"string"},"row_kind":{"type":"string","enum":["criterion","section_header","note"]},"category":{"type":["string","null"]},"criterion_text":{"type":"string"},"target_raw":{"type":["string","null"]},"comparator_raw":{"type":["string","null"]},"unit_raw":{"type":["string","null"]},"mandatory_raw":{"type":["string","null"]},"target_hw_raw":{"type":["string","null"]}},"required":["criterion_id","row_kind","criterion_text"]}고객사 제품팀 여러 명이 양자화 방식과 타깃 하드웨어를 바꿔 가며 돌린 최적화 실험 기록을 공유 폴더에서 모은 병합본입니다. 벤치마크 CSV 의 수치 열과 컴파일 로그에서 잘라 온 줄이 한 행에 함께 들어 있어, 도구가 대조해야 하는 실제 입력의 모양을 그대로 담습니다. 지연이 초로 적힌 행과 캘리브레이션 데이터셋이 비어 재현할 수 없는 행을 남겨 두었습니다. 전부 작성자가 만든 더미입니다.
| run_id | model | precision_raw | backend_raw | accuracy_metric | accuracy_value | baseline_accuracy | latency_p95_raw | peak_mem_raw | toolchain_version | calib_dataset | log_excerpt | measured_at |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | vlm-caption-s | W8A8 | NPU-A v2.1 | top1 | 0.712 | 0.719 | 27.4ms | 486MB | npir-1.8.2 | calib_indoor_512 | [compile] 214/214 ops mapped to NPU | 2026-07-14T10:20:00 |
| R-002 | vlm-caption-s | W4A16 | NPU-A v2.1 | top1 | 0.688 | 0.719 | 19.8ms | 312MB | npir-1.8.2 | calib_indoor_512 | [warn] op Softmax_23 fell back to CPU | 2026-07-14T13:05:00 |
| R-003 | vlm-caption-s | w8a8-per-channel | npu_a v2.1 | top1 | 0.71 | 0.719 | 0.031s | 0.52GB | npir-1.8.2 | calib_mixed_1k | [warn] op LayerNorm_7 fell back to CPU… | 2026-07-15T09:41:00 |
| R-004 | vlm-caption-s | W8A8 | NPU-A v2.1 | — | — | 0.719 | 24.9ms | 470MB | npir-1.9.0-rc1 | — | [compile] 214/214 ops mapped to NPU | 2026-07-15T16:12:00 |
| R-005 | vlm-caption-s | FP16 | TensorRT 8.6 | top1 | 0.718 | 0.719 | 12.2ms | 1.1GB | trt-8.6.1 | — | [info] engine built with fp16 tactics | 2026-07-16T11:00:00 |
아래 JSON Schema에 맞는 최적화 실험 기록 행을 30건 더 만들어 주세요. {"type":"object","properties":{"run_id":{"type":"string"},"model":{"type":"string"},"precision_raw":{"type":"string"},"backend_raw":{"type":"string"},"accuracy_metric":{"type":["string","null"]},"accuracy_value":{"type":["number","null"]},"baseline_accuracy":{"type":["number","null"]},"latency_p95_raw":{"type":["string","null"]},"peak_mem_raw":{"type":["string","null"]},"toolchain_version":{"type":["string","null"]},"calib_dataset":{"type":["string","null"]},"log_excerpt":{"type":["string","null"]},"measured_at":{"type":["string","null"]}},"required":["run_id","model","precision_raw","backend_raw"]} 전부 가상 더미로 만들고, 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어 주세요. 첫째 latency_p95_raw 가 0.031s 처럼 초 단위로 적힌 행 4건, 둘째 peak_mem_raw 가 0.52GB 나 512MiB 처럼 단위가 다른 행 4건, 셋째 calib_dataset 이나 toolchain_version 이 null 이라 재현할 수 없는 행 4건, 넷째 baseline_accuracy 가 null 이라 하락 폭을 계산할 수 없는 행 3건, 다섯째 accuracy_value 가 null 인 미측정 행 2건, 여섯째 같은 run_id 를 쓰면서 값이 다른 행 2쌍, 일곱째 backend_raw 표기가 NPU-A v2.1 과 npu_a v2.1 과 NPU_A2 로 흔들리는 행 5건, 여덟째 log_excerpt 에 fell back to CPU 나 delegated to CPU kernel 같은 폴백 문구가 연산자 이름과 함께 들어간 행 6건과 error 로 시작하는 실패 행 2건. JSON 배열만 내주세요.{"type":"object","properties":{"run_id":{"type":"string"},"model":{"type":"string"},"precision_raw":{"type":"string"},"backend_raw":{"type":"string"},"accuracy_metric":{"type":["string","null"]},"accuracy_value":{"type":["number","null"]},"baseline_accuracy":{"type":["number","null"]},"latency_p95_raw":{"type":["string","null"]},"peak_mem_raw":{"type":["string","null"]},"toolchain_version":{"type":["string","null"]},"calib_dataset":{"type":["string","null"]},"log_excerpt":{"type":["string","null"]},"measured_at":{"type":["string","null"]}},"required":["run_id","model","precision_raw","backend_raw"]}| PyTorch | 더미 실험 기록의 뿌리가 되는 모델 변환·내보내기 스크립트를 PyTorch 로 만듭니다. 기록의 열 구성이 실제 도구가 남기는 값과 같은 모양이 되게 맞춥니다. |
| 딥러닝 | 양자화 방식과 정확도 하락과 연산자 폴백이 서로 어떻게 얽히는지를 판정 규칙으로 못박습니다. 하락 폭 계산의 기준선을 무엇으로 잡을지도 여기서 정합니다. |
| VLM | 실험 기록의 대상 모델을 생성형 비전 모델 계열로 두어, 정확도 지표가 평가셋마다 갈리고 기준선이 비어 있는 경우를 더미에 그대로 담습니다. |
| LLM | 컴파일 로그 원문에서 폴백 연산자와 변환 실패 원인을 정해진 JSON 으로 정규화하고, 판정에 붙일 고객 회신 문장 초안을 씁니다. |
| Docker | 툴체인 이미지 태그를 재현 정보의 필수 필드로 두어 태그가 빠진 실험을 판정 보류로 돌리고, 도구 자체도 컨테이너 한 개로 실행합니다. |
| Linux | 도구가 도는 환경이자 기록의 실행 환경 정보를 읽는 자리입니다. 로그 폴더를 훑는 하위 명령과 종료 코드 처리를 여기에 맞춥니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 컴파일 로그 원문 추출과 추출 정확도 측정을 붙입니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 3주차에서 규칙 파일을 분리해 다른 고객사 기준표로 갈아끼웁니다.
실험 한 건과 수용 기준 한 항목이 만나는 자리의 판정입니다. 어느 값과 어느 로그 줄을 근거로 어떤 규칙이 그 판정을 내렸는지 담아, 회의에서 이유를 물으면 담당자가 바로 근거를 답하게 합니다.
{"type":"object","properties":{"run_id":{"type":"string"},"criterion_id":{"type":"string"},"verdict":{"type":"string","enum":["meets","not_met","conditional","unverifiable","needs_review"]},"basis":{"type":"string","enum":["rule_value_compare","rule_op_fallback","repro_missing","unit_unresolved","measurement_missing"]},"normalized":{"type":["object","null"],"properties":{"measured":{"type":["number","null"]},"target":{"type":["number","null"]},"unit":{"type":["string","null"]}}},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"quote":{"type":"string"}},"required":["field","quote"]}},"draft_sentence":{"type":["string","null"]},"needs_human_review":{"type":"boolean"},"hedge":{"type":["string","null"]}},"required":["run_id","criterion_id","verdict","basis","evidence","needs_human_review"]}[
{
"run_id": "R-001",
"criterion_id": "B-1",
"verdict": "meets",
"basis": "rule_value_compare",
"normalized": {
"measured": 27.4,
"target": 30,
"unit": "ms"
},
"evidence": [
{
"field": "run.latency_p95_raw",
"quote": "27.4ms"
},
{
"field": "criterion.target_raw",
"quote": "30"
}
],
"draft_sentence": "W8A8 조합의 p95 지연은 27.4ms 로 측정되어 기준 30ms 이하를 충족합니다.",
"needs_human_review": false,
"hedge": null
},
{
"run_id": "R-003",
"criterion_id": "C-1",
"verdict": "not_met",
"basis": "rule_value_compare",
"normalized": {
"measured": 495.9,
"target": 512,
"unit": "MiB"
},
"evidence": [
{
"field": "run.peak_mem_raw",
"quote": "0.52GB"
},
{
"field": "criterion.criterion_text",
"quote": "추론 중 피크 메모리 512MiB 이하"
}
],
"draft_sentence": null,
"needs_human_review": true,
"hedge": "기록이 GB 로만 적혀 있어 MiB 로 환산했습니다. 소수 둘째 자리에서 기준선에 붙는 값이라 원본 벤치마크 로그의 바이트 값을 담당자가 확인해야 합니다."
},
{
"run_id": "R-008",
"criterion_id": "D-1",
"verdict": "conditional",
"basis": "rule_op_fallback",
"normalized": {
"measured": 1,
"target": 0,
"unit": "개"
},
"evidence": [
{
"field": "run.log_excerpt",
"quote": "[info] 1 op fell back to CPU: Softmax_23"
},
{
"field": "criterion.criterion_text",
"quote": "Softmax 계열에 한해 CPU 폴백 1개까지는 협의 후 허용"
}
],
"draft_sentence": "Softmax_23 연산자 한 개가 CPU 로 폴백되어 폴백 금지 기준에는 미달하나, Softmax 계열 1개까지 허용하는 예외 항목에 해당하여 협의 대상으로 올립니다.",
"needs_human_review": true,
"hedge": "필수 항목과 권장 항목이 서로 다른 답을 내는 자리라 예외 적용 여부는 담당자가 정해야 합니다."
},
{
"run_id": "R-004",
"criterion_id": "E-1",
"verdict": "unverifiable",
"basis": "repro_missing",
"normalized": null,
"evidence": [
{
"field": "run.calib_dataset",
"quote": ""
},
{
"field": "run.toolchain_version",
"quote": "npir-1.9.0-rc1"
}
],
"draft_sentence": null,
"needs_human_review": true,
"hedge": "캘리브레이션 데이터셋이 비어 있어 같은 결과를 다시 낼 수 없습니다. 재현 정보가 채워지기 전에는 이 실험의 다른 항목 판정도 제출본에 싣지 않습니다."
},
{
"run_id": "R-011",
"criterion_id": "A-2",
"verdict": "needs_review",
"basis": "unit_unresolved",
"normalized": {
"measured": 1.3,
"target": 1,
"unit": null
},
"evidence": [
{
"field": "criterion.criterion_text",
"quote": "저조도 평가셋에서 정확도 하락 1% 이내"
},
{
"field": "criterion.unit_raw",
"quote": ""
}
],
"draft_sentence": null,
"needs_human_review": true,
"hedge": "기준이 퍼센트인지 퍼센트포인트인지 적혀 있지 않습니다. 퍼센트포인트로 읽으면 미달이고 상대 퍼센트로 읽으면 충족이라 판정이 뒤집혀 담당자 확인이 필요합니다."
}
][자동 검증. 코드가 매 출력마다 자동으로 거릅니다] 1. 항목 JSON 이 위 스키마를 통과하는지 확인합니다. verdict 나 basis 가 정해진 값 밖이면 그 항목을 버립니다. 2. basis 가 rule_value_compare 인 항목은 evidence 의 quote 가 입력 표의 실제 셀 값과 문자 그대로 같은지 대조합니다. 수치 판정에 지어낸 근거가 붙으면 보고서 전체를 믿을 수 없기 때문입니다. 3. basis 가 rule_op_fallback 인 항목은 evidence 의 로그 인용이 원본 log_excerpt 안에 실제로 있는 줄인지, 인용에 적힌 연산자 이름이 그 줄에 등장하는지 확인합니다. 4. normalized 의 measured 와 target 이 같은 unit 으로 맞춰졌는지, 환산이 초와 밀리초 그리고 MB 와 MiB 규칙표대로 되었는지 재계산해 비교합니다. 5. run 의 calib_dataset 이나 toolchain_version 이 비어 있으면 그 실험의 모든 항목이 unverifiable 로 나갔는지 확인합니다. 6. 같은 입력으로 두 번 실행한 보고서 파일이 문자 그대로 같은지 비교합니다. 결정론이 깨지면 판정 규칙에 순서 의존 버그가 들어간 것입니다. [수동 검증. 사람이 일부만 확인합니다] 1. 생성된 보고서 한 부를 제품팀 담당자 관점에서 읽고, 양산 검토 회의에 그대로 올려도 되는 문장인지 봅니다. 2. 필수 기준에서 미달과 조건부 수용으로 갈린 항목을 원본 벤치마크 기록과 하나씩 대조합니다. 3. 판정 보류로 빠진 항목이 실제로는 규칙으로 가를 수 있었던 것인지 살펴, 과하게 사람에게 넘기는 규칙을 다듬습니다.
근거: AI 최적화 기술을 통해 AI의 일상화를 선도하는 기업