KnowledgeForge: mining gold from the ITSM ticket graveyard

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

KnowledgeForge는 해결된 ITSM 티켓을 지식 문서로 전환하고 기존 문서의 중복과 품질을 관리하며, 사람의 승인과 벡터 재사용으로 지식 기반의 순환 구조를 구현한다.

📌 핵심 요약

• KnowledgeForge는 관련 ITSM 티켓 묶음에서 지식 기반 문서와 근본 원인 분석 문서를 생성하고, 신규·기존 문서를 분류·중복 검사·품질 평가·개선한다.
• 생성은 Amazon Bedrock의 Anthropic Claude Sonnet 4.5와 AWS Fargate 기반 Amazon ECS에서 실행하며, 고객별로 최대 5개 주제를 동시에 처리하고 주제마다 유사한 기존 문서 5개를 참조한다.
• Amazon S3 Vectors는 Amazon Titan Text Embeddings V2의 1,024차원 임베딩을 저장하며, 중복 탐지는 코사인 거리 0.05와 상위 후보 5개를 시작 설정으로 사용한다.
• 정비는 AWS Step Functions의 2단계 분산 맵으로 실행한다. 고객별 Amazon SQS FIFO 순서 제어와 배치 내부의 순차 중복 검사를 적용하고, 품질 평가와 개선은 병렬로 처리한다.
• 완성된 문서는 ServiceNow에서 지식 관리자의 승인을 받고 승인 결정은 Amazon DynamoDB에 기록된다. 정비 과정에서 저장한 벡터는 다음 생성과 재실행에 재사용된다.

🧩 주요 포인트

1. 생성과 정비의 연결 → 기존 지식이 다음 문서 생성의 참조 자료로 돌아가며, 사람의 승인이 게시 책임을 유지한다.
2. Amazon S3 Vectors의 검색·중복 탐지 겸용 → 같은 임베딩을 여러 처리에 재사용하지만, 코사인 거리 0.05는 표본 검토로 조정한 시작 설정이다.
3. 장시간 생성과 배치 정비의 실행 환경 분리 → AWS Fargate는 생성 작업을 맡고, AWS Step Functions는 정비 상태와 재시도를 관리하며, 고객별 순서와 배치 내부 순서는 구분해 제어한다.

🧠 상세 정리

1. 티켓에 묻힌 해결 지식과 지식 기반의 품질 문제

기업 IT 지원팀은 매달 수천 건의 티켓을 해결하지만, 각 티켓에 담긴 증상과 근본 원인, 엔지니어가 적용한 해결책이 지식 기반 문서로 이어지지 않는 경우가 있다. 이 정보가 티켓 이력에만 남으면 같은 문제를 만난 다음 엔지니어가 필요한 지식을 찾기 어렵다. 기존 지식 기반에는 반대 방향의 문제가 있어, 문서는 늘어나지만 중복과 오래된 내용이 쌓이고 작성자와 작성 시점에 따라 품질도 달라진다. KnowledgeForge는 해결된 티켓에서 새 문서를 만드는 작업과 기존 문서를 분류하고 중복을 제거하며 품질을 개선하는 작업을 함께 수행하도록 설계됐다. 결과는 지식 관리자가 검토하고 승인하므로, 실제 게시되는 내용에 대한 책임은 사람이 맡는다.

2. 구성 요소와 배포 전제

원문은 KnowledgeForge의 주요 구성 요소로 생성과 내용 개선을 담당하는 Amazon Bedrock, 중복 탐지를 위한 Amazon S3 Vectors, 처리 조정을 맡는 AWS Step Functions를 설명한다. 배포하려면 Amazon Bedrock을 사용할 수 있는 AWS 계정과 Anthropic Claude Sonnet 4.5 및 Amazon Titan Text Embeddings V2 모델에 대한 접근이 필요하다. 또한 Amazon S3 버킷과 벡터 인덱스, 상태 머신, Lambda 함수, Fargate 기반 ECS 서비스, DynamoDB 테이블, SQS 큐를 생성할 권한이 요구된다. 사전 조건에는 Amazon Bedrock 가드레일과 AWS KMS 키를 생성할 권한, AWS CDK 설치, 관련 서비스와 벡터 임베딩에 대한 실무 이해도 포함된다. 구현 코드는 aws-samples/sample-knowledgeforge 저장소에서 제공되며, 글은 이 구성을 대규모 생성형 AI 문서 처리에 재사용할 수 있는 패턴으로 소개한다.

3. 생성과 정비가 연결되는 지식 수명주기

KnowledgeForge는 티켓에서 초안 문서를 만드는 생성 하위 시스템과 신규·기존 문서를 관리하는 정비 하위 시스템으로 구성된다. 해결된 티켓과 기존 문서가 Amazon S3에 들어오면 데이터 카탈로그가 이를 추적하고, 생성 단계는 관련 티켓 묶음을 지식 기반 문서와 근본 원인 분석 문서로 전환한다. 정비 단계는 각 문서의 유형을 분류하고 중복 여부를 검사한 다음 품질을 평가하고 부족한 내용을 개선한다. 정비된 문서는 ServiceNow로 전달되어 지식 관리자의 승인을 받으며, 승인 결정은 Amazon DynamoDB에 기록된다. 순환 구조를 완성하는 연결점은 정비 과정에서 모든 문서의 벡터를 Amazon S3 Vectors에 저장하고, 생성 과정이 다음 실행에서 그 벡터를 다시 읽어 기존 지식을 참조한다는 점이다.

4. 고객별 티켓 묶음에서 두 종류의 문서 생성

생성에 앞선 상위 처리 과정은 해결된 사건을 문제별로 묶어 고객 한 곳을 범위로 하는 JSON 파일을 Amazon S3에 저장하며, 각 주제에는 키워드와 문서 범위, 티켓 설명 및 작업 기록의 표본이 포함된다. 새 파일 이벤트가 Amazon SQS로 전달되면 Fargate 기반 ECS 컨테이너가 큐에서 작업을 가져와 고객별로 최대 5개 주제를 동시에 처리한다. 문서를 쓰기 전에는 고객의 벡터 인덱스에서 가장 유사한 기존 문서 5개를 검색해 모델에 제공하고, 검색 증강 생성으로 용어의 일관성을 유지하며 근거 없는 절차 생성을 줄인다. 참조 문서가 없으면 티켓 데이터만으로 생성하고 절차를 검토 대상으로 표시한다. Anthropic Claude Sonnet 4.5는 제목·증상·원인·해결 단계·예방 등을 갖춘 지식 기반 문서와 고객 영향·다섯 번의 왜 분석·시정 및 예방 조치·주요 사건 시간표 등을 포함한 근본 원인 분석 문서를 각각 생성한다. Amazon Bedrock 응답은 스트리밍으로 받아 토큰이 도착하는 동안 문서를 조립한다.

5. 장시간·집중 유입 작업에 맞춘 컨테이너 실행

원문은 생성 작업의 지속 시간과 유입 형태를 이유로 함수 대신 AWS Fargate 기반 Amazon ECS를 선택했다고 설명한다. 한 주제에서 완성된 문서 두 개를 만드는 데 수분이 걸릴 수 있고, 주제가 많이 포함된 파일 하나는 전체 처리 시간이 길어질 수 있다. 또한 작업이 한동안 없다가 큰 배치로 몰리는 형태이므로, 큐의 깊이에 따라 태스크 수를 늘리고 큐가 비면 줄이는 장시간 실행 컨테이너 서비스가 이 패턴에 맞는다. AWS Fargate는 서버리스 방식으로 컨테이너를 실행하므로 팀이 컴퓨팅 용량 관리보다 생성 로직에 집중하도록 한다. 생성된 각 문서는 Amazon S3에 JSON으로 저장되어 이후 정비 단계의 입력이 되며, 생성과 정비에 서로 다른 실행 환경을 사용하는 이유도 이처럼 작업 특성이 다르기 때문이다.

6. 의미 기반 중복 탐지와 임계값 조정

중복 문서는 같은 해결책을 다른 표현으로 설명하거나, 새 문서가 이전 문서를 대체하거나, 기존 문서 일부만 수정해 새로 저장하는 형태로 나타나므로 키워드 일치만으로는 충분히 잡아내기 어렵다. KnowledgeForge는 Amazon Titan Text Embeddings V2로 문서마다 1,024차원 임베딩을 만들고 고객별 Amazon S3 Vectors 인덱스에 저장해 의미를 비교한다. 중복 탐지는 코사인 거리 0.05, 즉 유사도 0.95 이상과 상위 후보 5개를 시작 설정으로 삼으며, 표시된 문서 쌍을 표본 검토해 단순히 관련된 문서를 중복으로 오인하지 않도록 거리를 조정했다. 임계값을 느슨하게 하면 오탐이 늘고 지나치게 엄격하게 하면 표현만 바꾼 복사본을 놓치는 문제가 있었다. 검색은 현재 고객과 UNIQUE 또는 PENDING 상태의 문서로 제한하고, 자기 자신과의 일치를 고려해 후보를 하나 더 요청한 뒤 해당 문서 식별자를 제외한다. 이 인덱스는 생성 시 참조 검색에도 쓰이므로 검색과 중복 탐지가 같은 벡터 저장소를 공유한다.

7. 최신 문서 보존과 벡터 재사용의 비용 구조

중복 쌍을 발견했을 때 KnowledgeForge는 새로 들어온 문서를 무조건 버리지 않고 더 최신인 문서를 남기며 오래된 문서를 퇴역시킨다. 원문은 이 정책이 지원 엔지니어에게 필요한 최신의 정확한 버전을 우선하는 동작이라고 설명하지만, 최신성 판단의 세부 구현이나 정확성 검증 방법까지 제시하지는 않는다. Amazon S3 Vectors를 선택한 이유는 벡터를 Amazon S3에 직접 저장해 독립적인 벡터 데이터베이스를 피하고, 벡터와 함께 저장한 메타데이터로 고객별 필터링을 적용할 수 있기 때문이다. 비용은 실행 중인 노드가 아니라 쿼리와 저장 용량을 기준으로 부과되므로 전체 문서에 대한 벡터를 유지하는 데 적합하다고 설명한다. 배치를 재실행할 때도 저장된 벡터를 읽어 임베딩 모델 호출을 반복하지 않으므로 처리 시간과 Amazon Bedrock 비용을 줄일 수 있다.

8. 정비 워크플로의 병렬화와 순서 제어

정비는 매일 Amazon EventBridge 일정으로 시작하며, Lambda가 신규·변경 문서가 있는 고객을 찾아 배치로 묶고 고객 ID를 메시지 그룹 키로 쓰는 Amazon SQS FIFO 큐에 넣는다. 디스패처는 배치를 하나씩 가져와 AWS Step Functions 실행을 시작하고, 상태 머신은 분류·임베딩 생성과 중복 검사·품질 평가·개선이라는 두 단계의 분산 맵으로 작업을 조정한다. 문서별 Amazon Bedrock 호출이 EXPRESS의 5분 제한을 넘기 때문에 STANDARD를 선택하며, 전체 실행 이력을 디버깅에 활용하고 Amazon S3 매니페스트를 ItemReader로 읽어 상태 크기를 줄인다. FIFO는 실행 간 고객별 배치 순서를 관리하지만, 한 실행의 두 번째 단계에서는 최대 40개 배치가 동시에 처리될 수 있어 서로 다른 배치의 중복 문서 경합까지 단독으로 막지는 못한다고 원문은 명시한다. 원문은 배치 내부 중복 검사를 순차 처리하고 품질 평가와 개선을 병렬화하는 구성을 일관성 유지 방식으로 설명하지만, 배치 간 경합 방지의 구체적인 구현은 제공된 본문에 나타나지 않는다. 도해 설명에는 문서 본문 대신 Amazon S3 포인터를 전달하고 회로 차단기와 데드 레터 큐로 장애 배치의 영향을 제한한다고 나오며, 이후 포인터 전달 절의 본문은 중간에서 끊겨 있다.

🧾 핵심 주장 / 시사점

• 생성 품질은 생성 모델뿐 아니라 기존 지식의 정비와도 연결된다. 정비한 문서의 벡터가 다음 생성의 참조 자료로 돌아가기 때문이다.
• 중복 탐지에는 유사성 판단과 보존 정책이 함께 필요하다. 원문은 임계값을 표본으로 조정하는 과정과 오래된 문서 대신 최신 문서를 남기는 정책을 모두 설명한다.
• 고객별 실행 순서와 실행 내부의 병렬 처리는 서로 다른 제어 범위다. FIFO만으로 배치 간 중복 경합까지 해결된다고 해석해서는 안 된다.

✅ 액션 아이템

• KnowledgeForge의 티켓 기반 생성과 신규·기존 문서 정비를 연결하고, ServiceNow의 지식 관리자 승인 절차를 적용 대상으로 검토.
• Amazon S3 Vectors의 중복 탐지에서 코사인 거리 0.05를 시작 설정으로 삼아 표본 검토로 적합성을 확인.
• AWS Fargate의 생성 처리와 AWS Step Functions의 정비 처리를 구분하고, 고객별 순서와 배치 내부 순차 중복 검사의 적용 범위를 확인.

❓ 열린 질문

• KnowledgeForge가 생성한 지식 기반 문서와 근본 원인 분석 문서는 ServiceNow에서 어떤 승인 기준으로 검토할 것인가?
• Amazon S3 Vectors의 코사인 거리 0.05는 적용할 문서 집합의 표본 검토에서도 적합한가?
• AWS Step Functions에서 고객별 순서와 배치 내부 순차 중복 검사는 각각 어느 범위의 처리 순서를 보장하는가?