핸드오프 문제 - 사람이 사람에게 보낼 만한 결과물을 어떻게 얻고 계신가요?

그 마지막 30%가 진짜 업무지, 다른 도구로 패치할 수 있는 버그가 아님. 고객들이 돈을 내는 건 바로 그 고객 맞춤형 작업 때문인데, 회의록을 아무리 많이 넣어도 '이 사람은 추천 내용이 접힌 부분 아래에 있으면 화낸다'는 걸 봇이 매번 완벽하게 지키게 할 순 없음.

난 그냥 마지막에 사람을 두고, 그 사람의 업무를 딱 그 네 가지 수정 사항으로만 좁혔음. 그게 작업자한테도 빠르고 나한테도 덜 짜증 나며, 고객은 여전히 자신을 잘 아는 사람이 쓴 것 같은 결과물을 받게 됨.

마지막 문서를 서식 출력물로 취급하는 게 실패의 원인임. 핸드오프를 두 개의 레이어를 가진 아티팩트로 모델링해야 함:

1. 출처와 단위가 포함된 사실 및 주장;
2. 고객별 프레젠테이션 계약: 타겟 독자, 추천 위치, 숫자 및 날짜 규칙, 필수 섹션, 금지된 표현, 그리고 승인된 결과물의 예시.

회의 녹취록이 선호도를 추출하는 데 도움은 되지만, 노이즈가 많은 증거임. 모든 걸 다 집어넣기보다는 반복되는 선호도를 명시적인 '계약'으로 승격시켜야 함.

마지막 1마일은 항상 맥락 문제지 ㅋㅋ. 템플릿은 고객이 아무도 적어두지 않은 14가지 사소한 규칙을 꺼내기 전까지만 도움이 됨. 난 과거에 승인받았던 작업물과 좋은 대화 내용을 진실의 원천으로 활용하는 게 더 효과적이었음. 그러면 최종 검토는 모든 걸 기억하려는 거대한 프롬프트가 아니라, 그 고객이 실제로 어떻게 일하는지에 기반하게 됨.

네가 말하는 30%는 서식 문제가 아니라 맥락 문제임. 우리한테 도움이 된 건 검색 레이어와 프레젠테이션 계약을 분리하는 거였음. 고객 선호도(섹션 순서, 숫자 서식, 추천 위치 등)를 문서와 함께 구조화된 메타데이터로 저장하고, 마지막 단계에서 렌더링하기 전에 그 계약에 따라 검증하게 하는 방식임. Elasticsearch의 하이브리드 필터링을 활용한 벡터 검색이 여기서 잘 작동하는데, 콘텐츠와 고객별 규칙을 모두 검색할 수 있기 때문임...

스키마를 써보는 건 어때?