지식 갱신 (Knowledge Update)

문서 추가와 지식 갱신은 다르다

교육 안내문에는 ‘8주 과정’이라고 쓰여 있고, 새 미팅 메모에는 특정 고객에게 ‘5회 방문’을 제안했다고 해봅시다. 새 문서가 들어왔다고 모든 8주 설명을 5회로 바꾸면 안 됩니다. 일반 상품과 고객별 제안이 서로 다른 대상을 가리킬 수 있기 때문입니다. 이 예시는 갱신 판단을 설명하기 위한 가상 사례입니다.

BOAZ의 LLM 위키 운영에서는 새 자료가 기존 설명을 강화하는지, 범위를 좁히는지, 반박하는지, 대체하는지를 확인합니다. AI가 새 글을 작성한 수보다 기존 답에 무엇이 달라졌는지가 중요합니다.

반복해서 수행하는 네 단계

이는 BOAZ의 운영 절차를 설명하는 구분입니다. 공식적인 온톨로지 성숙도 등급과는 다릅니다. 운영을 잘한다고 곧바로 지식을 기계가 추론할 수 있는 수준에 도달하는 것은 아닙니다.

사람이 확인할 변경안을 만든다

사람에게 ‘전체 위키를 읽고 맞는지 봐주세요’라고 하면 검토 범위가 너무 큽니다. 대신 아래 내용을 한 주제에 모읍니다.

• 기존 문장과 제안 문장
• 그 변경을 뒷받침하는 원문 위치
• 원문에 직접 적힌 사실과 AI가 해석한 부분
• 바뀌는 페이지와 연결, 영향을 받는 업무
• 아직 확인하지 못한 점과 보류할 선택지

휴먼 인 더 루프는 이 변경안에 사람이 실제 판단을 남기는 자리입니다. 일반적인 ‘정리해줘’라는 요청과 특정 문장을 채택하는 결정은 구분합니다.

충돌이 생기면 날짜부터 덮어쓰지 않는다

‘예전에는 A, 이제는 B’인지, ‘팀 A는 A, 팀 B는 B’인지, ‘확정은 A, 제안은 B’인지에 따라 처리 방법이 달라집니다. 적용 시점과 대상을 먼저 확인합니다. 알 수 없으면 양쪽 근거를 보존하고 확인 필요로 남깁니다.

검토한 뒤 원문이나 초안이 바뀌었을 때도 주의해야 합니다. 사람은 이전 버전에 동의했을 수 있습니다. 무엇을 보고 판단했는지 버전과 함께 남겨야, 바뀐 내용을 예전 승인으로 처리하는 일을 막을 수 있습니다.

제약 검사와 사실 판단을 나눠 기록한다

가상 교육 기록에서 ‘실제 사용한 교안에는 회차, 교안 버전, 출처가 있어야 한다’는 조건을 둘 수 있습니다. 필수 값 누락과 존재하지 않는 식별자는 코드 검사로 찾을 수 있습니다.

하지만 출처가 제안서인데 실제 사용 기록으로 잘못 연결했다면 필수 칸이 모두 채워져도 뜻은 틀립니다. 원문이 무엇을 확인해 주는지는 별도로 검토해야 합니다. 형식 검사 결과, 사실 확인, 채택 결정을 하나의 ‘완료’ 표시로 합치지 않습니다.

이전 사실을 바꿀 때는 바뀐 이유와 적용 시점도 남깁니다. 지식 그래프의 현재 관계를 고치더라도 과거에 유효했던 관계와 검토 기록을 지우지 않아야 다음 질문에서 변경을 설명할 수 있습니다.

검색 인덱스도 별도로 갱신한다

문서를 고쳤어도 검색 시스템이 예전 사본을 읽으면 답은 바뀌지 않습니다. RAG를 사용한다면 인덱스와 캐시의 갱신까지 확인합니다. 위키의 의미를 고치는 일과 검색에 그 변경이 도달하는 일은 별도의 확인 항목입니다.

반영 후에는 실제 업무 질문을 다시 던져 봅니다. 답이 바뀌었는지, 출처가 새 근거를 가리키는지, 영향을 받지 않아야 할 기존 답이 유지되는지를 함께 확인합니다.