사내 문서로 답하게 만들면 생기는 일
AX 과제 중 가장 자주 나오는 요청이 이겁니다. "우리 문서를 학습시켜서 질문하면 답해주게 해주세요."
기술적으로는 어렵지 않습니다. Dify 같은 도구를 쓰면 문서를 올리고 데이터셋을 만들고 응답 창구를 붙이는 데 하루면 됩니다. 문제는 그다음에 생깁니다.
답을 하기 시작하면, 그 답에 책임이 생깁니다.
무엇이 실제로 어려운가
만들기 전에 알아둘 것 세 가지입니다.
첫째, 문서가 틀려 있습니다
대부분의 조직에는 최신 규정과 3년 전 규정이 같은 폴더에 들어 있습니다. 사람은 "저건 옛날 거예요"라고 알고 넘기지만, 검색 기반 응답은 그 구분을 하지 못합니다. 가장 정확하게 답하는 시스템을 만들어도, 원본이 정리되지 않으면 틀린 답이 나옵니다.
둘째, 근거 없는 답이 가장 위험합니다
그럴듯한 문장으로 틀린 답을 하면, 사용자는 검증하지 않습니다. 근거 문서를 함께 보여주지 않는 응답 창구는 만들지 않는 편이 낫습니다.
셋째, 권한이 섞입니다
인사 문서와 일반 규정이 같은 데이터셋에 들어가면, 누구나 급여 정책 상세를 물어볼 수 있게 됩니다. 사고는 대개 여기서 납니다.
Dify 같은 도구가 실제로 해결해 주는 것
이런 위험을 감안하고도 LLMOps 도구를 쓰는 이유는, 운영에 필요한 것들이 이미 갖춰져 있기 때문입니다. Dify가 GitHub 스타 10만을 빠르게 넘긴 배경도 도구라기보다 제품에 가깝게 만들어졌다는 점에 있습니다.
직접 구현하면 다음을 전부 만들어야 합니다.
- 문서 수집과 청크 분할, 임베딩, 재색인
- 프롬프트 버전 관리
- 응답 로그와 사용량 추적
- 근거 문서 표시
- 비개발자용 편집 화면
마지막 항목이 실무에서 가장 큰 차이를 만듭니다. 데이터셋과 프롬프트를 담당자가 직접 고칠 수 있으면 시스템이 살아남고, 개발자를 거쳐야 하면 3개월 뒤 방치됩니다.
경계선을 먼저 긋는다
만들기 전에 정해야 할 네 가지입니다.
1. 어떤 문서를 넣지 않을 것인가
넣을 문서 목록보다 제외 목록을 먼저 만드세요. 개인정보 포함 문서, 계약 원문, 인사 기록, 미확정 초안. 나중에 빼는 것보다 처음부터 안 넣는 게 훨씬 쉽습니다.
2. 누가 물어볼 수 있는가
전사 공개인지, 특정 팀인지. 데이터셋을 권한 단위로 나누는 게 정공법입니다. 하나의 데이터셋에 넣고 프롬프트로 "인사 관련은 답하지 마세요"라고 지시하는 방식은 경계가 아니라 부탁입니다.
3. 모르면 어떻게 답할 것인가
"관련 문서를 찾지 못했습니다"라고 말하게 만드는 것이 생각보다 중요합니다. 근거가 약할 때 답을 지어내지 않고 멈추도록 지시하고, 실제로 그렇게 동작하는지 시험해 보세요.
4. 답이 틀렸을 때 누구에게 가는가
신고 경로가 없으면 틀린 답은 조용히 반복됩니다. 응답 화면에 "이 답이 잘못됐습니다" 버튼 하나만 있어도 문서 정리의 우선순위가 생깁니다.
만드는 순서
1단계 — 좁게 시작합니다
문서 전체가 아니라 한 업무 영역, 문서 20~50건. 앞선 글의 우선순위 기준과 같습니다. 자주 묻고, 틀려도 복구 가능한 영역.
2단계 — 실제 질문을 모읍니다
상상한 질문이 아니라 그동안 담당자에게 실제로 들어온 질문. 이게 평가 세트가 됩니다.
3단계 — 답을 사람이 채점합니다
20~30개 질문에 대해 정답/부분정답/오답을 직접 매깁니다. 이 작업 없이 "잘 되는 것 같다"로 넘어가면 나중에 개선 여부를 알 수 없습니다.
4단계 — 근거 표시를 켠 채로 공개합니다
사용자가 원문을 클릭해 확인할 수 있어야 합니다.
사내 지식으로 답하게 만드는 일에서 어려운 건 검색도 모델도 아니었습니다.
무엇에 답하지 않을지를 정하는 일이었습니다. 경계를 긋지 않으면 시스템은 모르는 것에도 답하고, 한 번 그런 답이 나가면 이후 모든 답을 의심받습니다.
먼저 그어야 하는 건 답변 범위가 아니라 침묵의 범위입니다.
