화산엔진 지식엔진 VeKnow의 3층 재구성과 업무 적용 사례
바이트댄스 데이터플랫폼이 에이전트가 업무 지식을 이해하는 시대에 기업 온톨로지를 어떻게 구축하고 지속적으로 진화시킬지 VeKnow의 구축 방식과 업무 실천을 정리했다.
중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.
이제 비즈니스 지식을 이해하고 사용하는 주체가 Agent가 되면서, 기업 온톨로지(기업 본체)는 어떻게 구축하고 어떻게 지속적으로 진화해야 하는가? 이 글은 구축 방식과 비즈니스 실천에서 출발해 이를 펼쳐본다.
기업 온톨로지가 해야 할 일은 바로 비즈니스 속 객체, 관계, 제약을 통일적으로 표현하여 사람과 Agent가 모두 일관된 비즈니스 의미 체계 아래에서 그것들을 사용할 수 있게 하는 것이다.
Agent 시대의 기업 온톨로지는 지속적으로 운용 가능한 비즈니스 표현 시스템이어야 한다. 즉 비즈니스가 이해할 수 있고, Agent의 행동을 조직할 수 있으며, 비즈니스에 따라 끊임없이 진화할 수 있고, 거버넌스와 검증이 가능해야 한다.
이 시스템의 운용을 뒷받침하려면 기업 온톨로지 구축은 제품 형태, 반복 메커니즘, 엔지니어링 인프라라는 세 가지 차원에서 동시에 재구성을 이루어야 한다.
화산엔진(火山引擎) 지식 엔진 VeKnow는 「기업급 지능형 Agent 시나리오를 겨냥해 구축한 지식 통합 관리 및 지능형 검색 플랫폼」으로, 선진적인 대규모 모델과 빅데이터 기술에 힘입어 구조화 및 비구조화 데이터 지식에 대해 데이터 접속, 정제·가공, 지식 모델링, 지능형 마이닝부터 응용 서비스에 이르는 전 링크 데이터 자산 관리 역량을 제공한다.
1. 제품 형태 재구성: 고정 프로세스에서 역량 조합으로
첫 번째 차원은 제품 형태의 재구성이다. 전통적인 방식은 보통 기능 동선을 중심으로 제품을 설계한다. 먼저 사용자가 어떻게 조작할지를 미리 상정한 뒤, 각 단계를 고정 프로세스로 만들어 사용자가 페이지 안내에 따라 단계별로 작업을 완수하도록 하고, 시스템은 각 노드에서 대응하는 기능을 제공한다.
그러나 기업 온톨로지 구축은 정반대다. 동일한 배치의 비즈니스 자료를 앞에 두고도 검색 질의응답에는 인덱스가 필요하고, 관계 추론에는 지식 그래프가 필요하며, 항목별 열람에는 지식 백과(Wiki)가 필요하다. 서로 다른 시나리오는 서로 다른 형태의 지식 자산을 요구한다. 만약 모든 요구가 하나의 고정 프로세스에 대응된다면, 시나리오가 많아질수록 진입점과 경로는 더 복잡해지고 유지보수 비용은 점점 더 높아질 것이다.
지식 엔진 VeKnow는 이런 과제에 더 부합하는 "Agent Harness + 역량 공급" 패러다임을 제공한다. 읽기, 추출, 검색, 연관, 평가 같은 기저 역량을 Agent가 호출할 수 있는 일련의 오퍼레이터와 CLI로 캡슐화하고, 사람은 목표를 정의하고 핵심 노드에서 판단을 확인하며, Agent는 목표와 현재 상태, 피드백에 따라 어떤 역량을 어떤 순서로 조합해 호출할지를 스스로 결정한다.
이 패러다임의 장점은 동일한 역량 조합으로 완전히 다른 비즈니스 해법을 만들어낼 수 있다는 데 있다. 요구가 변화할 때 전체 프로세스를 다시 만들 필요 없이 Agent가 역량 조합을 다시 편성하게 하면 된다. 동시에 이러한 조합은 통제 가능해야 한다. 사람의 수정은 컨텍스트에 들어가야 하고, 핵심 노드에서는 확인을 유지해야 하며, 중단된 작업은 이어서 할 수 있어야 하고, 실패한 단계는 부분적으로 재시도할 수 있어야 한다. 유연성과 통제 가능성을 동시에 갖추어야 Agent가 "시연 가능"에서 "납품 가능"으로 나아갈 수 있다.
2. 반복 메커니즘 재구성: 수정도 보고, 퇴화도 점검한다
두 번째 차원은 반복 메커니즘의 재구성이다. 산출물이 갱신되었다고 해서 품질이 반드시 향상되는 것은 아니다. 새로운 반복 버전이 엔티티 명칭을 바로잡았지만 원래 정확하게 추출되었던 관계를 놓쳤을 수 있다. 이번에 무엇을 고쳤는지만 보아서는 다른 곳을 망가뜨렸는지 판단할 수 없다. 더 곤란한 점은 사람이 하나하나 재검토하는 방식으로는 지속적이고 대규모의 온톨로지 구축을 도저히 감당할 수 없다는 것이다.
어려움은 세 가지에 집중된다. 첫째는 규모 문제다. 엔티티와 관계는 계속 늘어나므로 하나하나 대조하는 일은 인력을 계속 소모한다. 둘째는 기준 문제다. 명확한 표준이 없으면 동일한 관계가 서로 다른 시나리오에서 서로 다른 판단을 받을 수 있다. 셋째는 잠재적 오류다. 산출물이 형식상 올바르고 노드가 완전해 보인다고 해서 비즈니스 사실이 정말 정확하다는 것을 의미하지는 않는다.
이러한 문제를 해결하려면 반복 메커니즘은 반드시 재검증 가능한 폐루프가 되어야 한다. 지식 엔진 VeKnow는 「협업 가능한 온톨로지 구축」과 「지속적으로 최적화 가능한 평가 폐루프」라는 두 가지 역량을 제공한다.
전자는 시스템이 권한 범위 내의 기업 지식을 자동으로 읽어 객체, 속성, 관계, 제약을 식별하고 Schema 제안을 생성하며 나아가 인스턴스 추출과 온톨로지 구축을 완료하게 한다. 비즈니스 전문가는 Schema, 핵심 관계, 충돌 항목 등의 노드에서 검토하고, Agent는 수정 의견에 따라 컨텍스트를 갱신해 계속 실행하며, 모든 결과 항목은 원본 자료와의 대응 관계를 보존하여 재검토와 추적이 용이하도록 한다.
후자는 평가를 폐루프에 내장하여, 비즈니스 목표를 중심으로 평가 세트, 표준 답안, 평가 차원을 정하고, 산출물을 표준과 대조해 격차를 파악하며, 수정한 뒤 동일한 기준으로 재측정하고, 수정도 보고 퇴화도 점검함으로써 기업 온톨로지가 이러한 반복 속에서 지속적으로 진화할 수 있게 한다.
3. 엔지니어링 인프라 재구성: 나눌 수 있고, 조정할 수 있고, 담아낼 수 있게
세 번째 차원은 엔지니어링 인프라의 재구성이다. 주문 한 건에서 상품 몇 개의 귀속을 정리하는 일과, 천만 건의 주문에서 완전하고 일관된 "상품—매장—사용자—거래" 관계망을 구축하는 일은 난이도가 전혀 다른 두 가지 작업이다. 문서가 많아지면 엔티티 중복 제거, 문서 간 관계 정렬, 장문 처리, 실패 복구 같은 문제가 동시에 튀어나온다.
예를 들어 Excel로도 데이터 분석을 할 수 있지만, 진정한 대량의 데이터를 앞에 두면 필요한 것은 Spark, Flink 같은 병렬 컴퓨팅 체계다. 지식 컴파일은 같은 규모의 문제를 마주하며, 기업의 방대한 자료 위에서 안정적이고 지속적으로 돌아가게 하려면 지식 엔진 VeKnow의 엔지니어링 기반은 세 가지를 반드시 잘 해내야 한다.
- 나눌 수 있게: 방대한 자료를 앞에 두고 먼저 비즈니스 모듈과 문서 유형에 따라 작업을 적절한 크기의 처리 단위로 쪼개어, 각 조각이 Agent에 의해 안정적으로 소화되고 한 번에 너무 많이 삼켜서 오류가 나지 않도록 한다.
- 조정할 수 있게: 수천 수만 개의 작업이 동시에 돌 때 시스템이 스스로 대기열을 만들고, 자원을 할당하고, 상호 대기를 해소하여 연산능력과 대규모 모델 할당량이 비즈니스에서 가장 긴요한 부분에 안정적으로 쓰이도록 한다.
- 담아낼 수 있게: 실행이 끝난 결과는 병합할 수 있고, 정렬할 수 있으며, 원문의 구체적 위치까지 추적할 수 있어야 한다. 오류가 발생하면 문제가 된 구간만 따로 보충 실행할 수 있어, 앞서 완료한 성과가 헛되지 않는다.
이런 일들을 제대로 해내면 효과는 눈에 보인다. 실제 시나리오 테스트에서 기저에서 동일한 모델을 사용해 같은 배치의 자료를 처리할 때, VeKnow 지식 컴파일은 범용 Agent 프레임워크에 비해 소요 시간이 더 적고 Token 소모도 더 적었으며, 핵심 정보 식별 정확도도 더 안정적이었다. 기저 역량이 탄탄해야 온톨로지 구축이 더 빠르고 더 안정적으로 비즈니스에 안착할 수 있다.
4. 비즈니스로의 안착: 온톨로지 구축을 더 빠르고 비즈니스에 더 밀착되게
지식 컴파일이 방법론에서 제품 역량으로 자리 잡으면, 성과는 최종적으로 두 가지 차원에서 드러난다. 하나는 효율성으로, 중복 정리와 수작업 입력을 줄여 온톨로지 구축 주기를 단축한다. 다른 하나는 효과로, Agent가 더 완전한 기업 지식 컨텍스트에서 전역 추론을 수행하도록 하여 리스크, 내용 누락, 잠재적 관계를 능동적으로 식별하고 Schema 제안의 완전성과 일관성을 높인다.
먼저 효율성 측면을 보자. 한 선두 제조사의 애프터서비스 온톨로지 구축을 예로 들면, 여기에는 설비 모델, 부품, 수리 작업 지시, 과거 고장, 엔지니어 숙련도 등 여러 유형의 객체와 관계가 관련된다. 전통적인 방식에서 이 같은 온톨로지는 보통 두 유형의 역할이 협업해야 한다. 비즈니스 전문가는 애프터서비스와 보증의 의미 규칙을 설명하고, 온톨로지 모델링 엔지니어는 구조 설계, 수작업 채우기, 반복 검증을 담당하며, 작업이 서로 다른 역할 사이를 직렬로 흐르면서 협업 비용을 늘리고 납품 주기도 늘어난다.
지식 컴파일을 도입한 후, 시스템은 서비스 매뉴얼, 정비 작업 지시서, BOM 목록, 보증 정책 등의 자료를 직접 읽고, 스키마 제안(Schema proposal)을 자동 생성하고, 인스턴스를 추출하고, 온톨로지를 구축하며, 평가 세트를 기반으로 지속적으로 검증한다. 업무 전문가는 더 이상 항목별로 콘텐츠를 생산할 필요 없이 핵심 구조와 예외 항목만 검토하면 되며, 자료가 비교적 완전하고 업무 경계가 명확하며 검토가 신속하게 이루어지는 조건하에서 이 온톨로지의 납품 역할은 두 부류에서 한 부류로 줄어들고, 주기는 4주에서 최대 1주로 단축된다.
효과 측면도 살펴보자. 한 유통 그룹을 예로 들면, 기업 온톨로지 모델링은 상품 마스터 데이터, 프로모션 규칙, 재고 흐름, 매장과 채널 등 여러 출처를 포괄한다. 수작업 모델링은 흔히 개인이 읽고 기억할 수 있는 정보 범위에 의해 제한되며, 제도 규범, 업무 문서, 데이터 정의, 과거 사례, 운영 기록에 흩어져 있는 지식을 마주할 때 이를 하나하나 이해하고 연관성을 구축해야 하므로, 국부적 관점의 영향을 받기 쉬워 도메인 간 제약, 잠재적 리스크, 명시적으로 표현되지 않은 업무 관계를 놓치기 쉽다. 예를 들어 특정 프로모션 규칙과 특정 채널의 재고 기준 사이의 암묵적 충돌 같은 것이다.
Agent Native의 모델링 방식은 다르다. 권한 범위 내의 관련 기업 지식을 통독할 수 있으며, 통일된 컨텍스트에서 객체, 속성, 관계와 규칙을 이해한다. 전역적 시야를 갖추게 되면 AI는 구조를 생성할 수 있을 뿐 아니라 도메인 간 충돌과 잠재적 리스크를 능동적으로 예측하고, 보충해야 할 객체, 속성과 제약을 식별하며, 서로 다른 자료에 흩어져 있는 암묵적 관계를 발굴할 수 있다. 원천 자료의 품질과 수작업 검토 메커니즘이 보장되는 전제하에서 스키마 제안은 더 완전하고 더 일관되며, 검토와 지속적 반복에 더 용이하다.
제품 형태, 반복 메커니즘에서 엔지니어링 인프라에 이르기까지, 세 층의 재구성은 결국 동일한 목표로 귀결된다. 바로 온톨로지 구축을 더 빠르게, 더 업무에 밀착시키는 것이다.
바이트댄스 데이터 플랫폼
482
글
595k
조회수
1.6k
팔로워