만들어 끝내지 않기: 의사결정 RAG를 업데이트하고 평가하기

EP-001 validity=superseded
▲
│ EP-005가 대체함
...

python3 csv_to_markdown.py episodes.csv data/episodes.md

python3 rag.py --compare 

기술적인 평가만으로는 '이 사람이 이렇게 말할 것 같다'는 것을 측정할 수 없다. 본인과, 그 사람의 판단을 잘 아는 여러 관계자들에게도 답변을 받아봐야 한다.

평가표에 다음 열(column)을 추가한다.

| 열 | 확인할 내용 |
|---|---|
`likeness_score` | 본인다운 판단으로 보이는가. 1~5점 |
`priority_match` | 본인이 중요하게 생각하는 것과 일치하는가 |
`exception_match` | 신중해지는 조건이나 예외가 일치하는가 |
`action_match` | '언제・무엇을 할지'의 구체성이 일치하는가 |
`why_it_feels_like_them` | 어디를 보고 본인답다고 느꼈는가 |
`why_it_feels_wrong` | 어디에 위화감이 있었는가 |

여기서 중요한 것은 점수만으로 끝내지 않는 것이다.

'4점. 고객에게 미치는 영향에서 생각하는 부분은 본인다운 것 같다. 다만, 이 상황이라면 먼저 현장 책임자에게 물어볼 것이다'와 같이 이유를 남긴다.

그 한 문장이 다음에 수집해야 할 에피소드가 된다.

어조(口調)의 평가를 마지막에 두는 데는 이유가 있다.

본인과 같은 말투라도 우선순위가 다르면 위험할 정도로 설득력 있는 가짜가 될 수 있다. 반대로, 말투가 조금 다르더라도 무엇을 보고, 어디서 망설이고, 어떤 조건에서 예외를 두었는지가 일치한다면 판단의 계승에 도움이 된다.

## Step 5: '모른다'는 질문도 시도하기

정답 사례만으로는 RAG의 안전성을 확인할 수 없다.

- 수집 대상이 아닌 인사 평가를 듣는다
- 이용 범위가 `restricted`인 에피소드와 유사한 질문을 한다
- 근거가 하나도 없는 주제를 묻는다
- 오래된 `EP-001`을 전제로 질문한다
- 본인의 설명과 제3자의 해석이 충돌하는 질문을 한다

기대하는 것은, 무엇에나 본인답게 답변하는 것이 아니다.

근거가 없으면 보류할 수도 있는 것도 품질이다.

## Step 6: 업데이트의 계기를 정하기

업데이트에는 적어도 3가지 종류의 계기가 있다.

| 계기 | 예시 | 대응 |
|---|---|---|
정기 확인 | 분기별 리뷰일이 왔다 | `next_review_date` 행을 확인한다 |
사건 | 방침 변경, 실패, 새로운 예외, 역할 변경 | 새로운 에피소드를 추가한다 |
이용 결과 | 원하는 사례가 검색되지 않는다, 답변이 다르다 | 로그를 확인하여 부족한 데이터를 수집한다 |

운영 담당자가 멋대로 '본인다운 답'을 추가하는 것이 아니다. 입력자, 확인자, 이용 범위를 정하고 변경 이력을 남긴다.

## 판단 데이터의 품질을 확인할 7가지 항목

업데이트 시에는 다음 7개 항목을 본다.

- **구체성**: 어떤 상황에서, 무엇을 허용했고, 무엇을 요구했는가 -
- **출전(出典)**: 누구의 기억인가, 어느 기록인가, 언제의 사건인가 -
- **신선도(鮮度)**: 과거 발언과 현재 방침이 분리되어 있는가 -
- **예외**: '반드시', '절대로'가 정말 모든 상황에 적용되는가 -
- **반증(反証)**: 같은 생각이 성공하지 못한 사례도 있는가 -
- **시점(視点)**: 본인, 제3자, 공식 기록을 구별하고 있는가 -
- **업데이트 가능성**: 누가, 언제, 무엇을 계기로 재검토할 것인가

성공담만으로 만들면 RAG는 상담 상대가 아니라 표어 생성기가 되어버린다. 판단을 바꾼 사례나, 예외를 둔 사례도 마찬가지로 중요하다.

## 판단하는 사람이 교체된 후에는 두 가지를 분리한다

본인이 판단의 장을 떠난 후에는 다음 두 가지를 구별한다.

- **과거 본인이 어떻게 생각했는지**를 보여주는 기록 -
- **현재 조직으로서 어떻게 판단할지**를 보여주는 방침

이것들을 섞으면, 과거 발언이 현재의 공식 판단인 것처럼 보이게 된다.

승계 후에는 다음을 정해둔다.

- 본인의 기록을 어느 정도까지 동결하여 남길 것인가
- 현재의 방침을 누가 승인할 것인가
- 양자가 다를 경우, 답변 화면에서 어떻게 분리해서 보여줄 것인가
- 중요한 판단을 누구에게 인계할 것인가

'본인 같은 답변'은 과거의 사상을 추적하는 데 도움은 된다. 하지만 현재의 책임을 지는 것은 아니다.

## 발주자와 벤더는 어디를 함께 만들 것인가

| 조직 측이 주로 결정하는 것 | 벤더가 지원할 수 있는 것 |
|---|---|
어떤 상담에 사용할지 | 유스케이스를 질문 모음으로 분해한다 |
... |

조직 측이 데이터의 의미와 평가·갱신의 책임을 지고, 벤더가 안전하게 수집·검색·비교할 수 있는 시스템을 만드는 것. 여기가 역할 분담의 핵심이 됩니다.

## 10일간의 작은 실험으로 만들기

| 시기 | 할 일 | 결과물 |
|---|---|---|
| 1~2일차 | 대상 테마와 상황별 질문 10개 결정 | 질문지 |
| ... | 
첫 번째 성과는 높은 정답률이 아닙니다.

**어떤 질문에 답하고 싶은데, 어떤 판단 데이터가 부족한지를 구체적으로 말할 수 있는 것**입니다.

## Digital MATSUMOTO와의 연결고리

Digital MATSUMOTO의 공개 리포지토리에는 RAG용 CSV, Markdown 형식 페이지 데이터, ChromaDB, RAG 데이터 업데이트, 피드백 저장 등이 포함되어 있습니다.

3편의 기사에서 다룬 것은, 그 데이터 운영을 이해하기 위한 최소화된 경험이었습니다.

## 이번 완성 조건

- 오래된 판단을 지우지 않고 `superseded` 처리함 - 새로운 판단으로 대체 관계를 부여함
- Markdown을 재(再)생성하고, 검색 대상이 변경되었음을 확인함
- 검색·상황·신선도·답변을 나누어 평가함
- 본인과 여러 이해관계자가 '본인스러움'과 그 이유를 기록함
- 근거가 없는 질문에서는 답변을 보류할 수 있는지 시도함
- 정기/사건/활용 결과의 업데이트 담당자를 결정함

여기까지 시도해 보면, RAG는 모델을 선택해서 끝내는 시스템이 아니라, **그 사람의 판단을 모으고, 비슷한 상황에 적용하며, 사람이 확인하고, 변화에 맞춰 계속 업데이트하는 운영**이라는 것을 알게 됩니다.

그 순환이 돌아가야만 '본인스러움'이라는 감각이, 사상이나 판단 기준을 다음 사람에게 전달하기 위한 구체적인 시스템이 될 수 있습니다.

## 참고 자료

### Discussion

![](https://static.zenn.studio/images/drawing/discussion.png)