3주 · 5인 팀 프로젝트 · 데이터 담당
AI가 받은 점수는, 누가 매겼을까?
공공기관 입찰 공고서를 AI가 대신 읽고 답해주는 챗봇 RFPilot을 5명이 함께 만들었습니다. 저는 그중 AI를 채점할 ‘정답지’와 문서에 붙이는 ‘이름표’를 맡았습니다.
이런 제품입니다
공공기관 입찰 공고서는 수백 쪽짜리 한글 파일입니다. 제안서를 쓰려면 사람이 전부 읽어야 했죠. 아래는 팀이 만든 실제 챗봇 화면입니다. “내 데이터 표시”를 켜면 이 화면의 어느 부분이 제 손을 거쳤는지 보입니다.
RFPilot
RFP 문서에서 핵심 요구조건·대상기관·예산·제출방식을 빠르게 찾아드립니다.
데이터가 흘러가는 길
“성능 0.940” ― 이 점수는 어디서 나왔나
시험 점수를 매기려면 정답지가 있어야 합니다. AI도 똑같습니다. 사람이 미리 “정답은 이 문서 이 부분”이라고 정해둔 목록이 없으면 성능은 측정이 안 되는 게 아니라 계산식 자체가 성립하지 않습니다.
정답지 1: 평가 질문 63개를 어떻게 짰나
golden_dataset · 실측“거절” 13개는 일부러 넣었습니다 ― 챗봇이 모르는 걸 지어내지 않는지 보려고.
예산·마감일처럼 계산으로 정답이 나오는 건 자동 생성, 서술형 10개는 손으로 썼습니다. 정답 위치까지 달린 건 50개(거절 13개는 정답 문서가 없는 게 정답).
이 63개가 검색·생성 점수 전부의 분모입니다. 0.940도 0.905도 0.608도 여기서 나옵니다.
이름표 붙이기 ― 흩어진 표기를 하나로
문서마다 발주 기관 이름이 제각각 적혀 있습니다. 사람은 같은 곳인 줄 알지만 AI는 글자가 다르면 다른 곳으로 봅니다. 100건 전부의 기관명·사업명·예산·마감일을 하나의 표기로 정리해 문서 조각 14,606개에 붙였습니다.
붙인 이름표가 실제로 몇 칸이나 채워졌나
enriched 청크 14,606개 · 실측조인 실패는 0건입니다. 빈 칸은 붙이기에 실패한 게 아니라 원본 공고에 그 값이 없던 경우입니다 ― 예산 미공개 7건이 그대로 드러납니다. 별칭 33%는 약칭이 생기는 기관(대학 등)에만 붙였기 때문입니다.
공고 예산은 이렇게 흩어져 있다
100건 · 실측중앙값 1.96억, 최대 141억. “예산 10억 이상인 사업” 같은 질문의 정답이 이 분포에서 계산됩니다. 1원짜리 이상치 1건은 발견해서 비교·최저 질문에서 뺐습니다.
공고서는 문장이 아니라 표였다
조각 14,606개 · 실측조각의 3분의 2가 표입니다. 그래서 배점·자격 같은 질문의 정답을 “표 조각”으로 라벨링해야 했고, 자동 검사에도 그 규칙을 넣었습니다.
솔직한 단서 하나 ― 정리 전후로 기관 고유 수는 87개 그대로였습니다.
정규화의 목적은 문서끼리 합치는 게 아니라, 사용자가 입력한 표기를 문서의 표기에 맞추는 것이었으니까요.
11개 기관이 2건 이상 발주했고, 그게 “같은 기관 사업 다 보여줘” 질문의 정답 근거가 됩니다.
경계 이름표를 사용하는 3단계 검색 필터는 검색 담당자가 구현했습니다. 제 몫은 필터가 먹는 재료입니다.
정답지 만들기 ― 954개를 직접 판정했다
앞의 체크리스트 화면이 잘 뽑았는지 채점하려면 항목 단위 정답지가 필요합니다. 공고서 8건을 처음부터 끝까지 읽으며 하나하나 판정했습니다. 기준은 하나 ― “입찰에 참여하는 회사가 알고 대비해야 할 일인가?”
직접 해보세요. 네 항목 중 채점 대상은 몇 개일까요? 예시 · 가명
공고서 8건, 954개 항목의 실제 구성
v5_gold_labels · 실측같은 “공공 입찰 공고서”인데 항목 수가 75개에서 183개까지 2.4배 차이 납니다. 그래서 한 문서만 보고 “이 정도면 되겠지” 하면 안 되고, 8건을 전수로 읽어야 했습니다.
954개를 무엇으로 갈랐나
실측판정 근거를 원문에 그대로 적힌 것 790개와 맥락으로 읽어낸 것 147개로 나눠 기록했습니다 ― 나중에 다투게 될 항목을 미리 표시해두려고.
갈릴 만한 62개는 두 사람이 따로 판정
두 사람 일치율 · 실측채점에 실제로 쓰는 축은 완전 일치라 점수를 믿을 수 있습니다. 반면 중요도는 일치율이 낮아 점수에서 빼고 기록용으로만 남겼습니다. 공동 작업
정답지가 조용히 망가지는 순간
정답지는 “몇 번째 문서 조각”으로 정답 위치를 가리킵니다. 팀이 문서 자르는 방식을 바꾸면 그 번호가 통째로 어긋납니다. 정답지는 멀쩡해 보이는데 엉뚱한 곳을 가리키게 되죠. 눈으로는 못 잡습니다. 그래서 자동 검사를 만들었습니다.
자동 검사 12가지 전체 보기
참고용 검사 1가지를 더해 13가지. 하나라도 걸리면 스크립트가 실패를 반환하고 그 아래 채점 작업을 아예 돌리지 않습니다.
결과
각 칸에 마우스를 올리면 그 점수를 매기는 데 쓰인 정답지가 선명해집니다. 전부 제가 만든 정답지 위에서 나온 숫자입니다.
거절 질문 13개는 위 점수의 분모에서 빠지고, “제대로 거절했는가”를 따로 채점하는 데 쓰입니다. 의무항목 추출의 문서별 성적은 0.831~0.922 범위로 안정적이었습니다(개별 문서 수치는 비공개).
숨기지 않는 숫자
정확도가 낮아 보이는 이유
챗봇은 문서 하나에서 480~1,706개 항목을 뽑습니다. 제 정답지는 같은 문서를 75~183개로 묶어 정리했고요. 잘게 쪼갠 쪽을 묶어 센 쪽으로 나눈 값이라 낮게 나옵니다. 틀린 게 아니라 세는 단위가 다른 것이고, 그걸 숫자로 확인한 게 이번 정답지의 성과입니다.
기준을 늦게 정했다
중요도 6단계는 두 사람의 판정이 충분히 모이지 않았습니다. 그래서 점수에서 뺐습니다. 다시 한다면 판정을 시작하기 전에 기준 예시를 더 많이 고정해두겠습니다.
정답지는 8건뿐
100건을 전부 채점하려면 약 18시간이 걸려 8건을 골라 썼습니다. “공고서 전반에서 89%를 찾아낸다”고 말할 수 있는 근거는 여기까지입니다.
3주 동안 배운 것
- 측정할 수 없으면 개선했는지도 모른다. 정답지가 늦으면 팀 전체가 감으로 일하게 된다.
- 기준 데이터는 하나로 고정해야 한다. 원본이 여러 개면 정답이 조용히 어긋난다.
- 검사는 사람이 아니라 스크립트가 해야 한다. 눈으로 하는 검수는 세 번째부터 안 하게 된다.
역할
직접 만든 것
- 정답지 빌더 ― 평가 질문 63개 자동 생성
- 정답지 954개 판정 (공고서 8건 전수)
- 무결성 자동 검사 12가지
- 문서 이름표 14종 + 조각 14,606개 조인
- 개인정보 가리기 (연락처·주민번호 등)
같이 한 것
- 갈리는 항목 62건 이중 판정·일치율 ― 다른 DE와
- 의무항목 채점 ― 정답지는 본인, 실행 코드는 팀원
- 이름표 붙인 문서 조각 ― 조각내기는 팀원
팀원이 만든 것
- 문서 쪼개기 · 품질 검사 · 마스킹 검증 테스트
- 검색 엔진과 기관명 3단계 필터 구현
- 챗봇 파이프라인 · 답변 생성 · 웹 화면