AI 앱의 온톨로지와 역량 모델링
온톨로지는 AI 애플리케이션에서 도메인 용어와 관계를 명시하는 의미 모델이고, 역량 모델은 업무 수행 능력을 행동 기준과 증거로 구조화한다. 이 구조는 RAG 검색, LLM-as-judge 평가, 권한 정책, SJT 설계에서 같은 기준을 공유하게 만든다.
Script Companion
오디오와 함께 스크립트 보기
- 01
AI 애플리케이션에서 온톨로지는 도메인 용어와 관계를 명시하는 의미 모델이다. 직책, 역량, 평가 항목, 증거 같은 관계가 없으면 RAG는 chunk 유사도만 보고 비슷해 보이는 문장을 가져오게 된다. 역량 모델은 여기에 업무 수행 능력을 행동 기준과 증거로 붙인다. 그래서 검색 결과가 단순히 관련 있어 보이는 문장이 아니라, 어떤 개념에 대한 어떤 증거인지 추적될 수 있다. 이 구조는 평가 rubric, 권한 정책, SJT 설계까지 이어진다.
- 02
LLM 앱에서 온톨로지를 시작할 때 꼭 RDF나 OWL부터 갈 필요는 없다. JSON Schema, TypeScript type, graph DB schema처럼 더 작은 형태로도 시작할 수 있다. 판단 기준은 두 가지다. 추론이 필요한가, 그리고 관계 변경이 평가 결과를 바꾸는가다. 닫힌 용어 목록, 1~2단계 metadata filter, judge output 검증 정도가 목적이면 JSON Schema와 ontology_version metadata로 충분하다. 반대로 다중 hop 관계를 따라 권한, 선수지식, 역량 충족 여부를 계산해야 한다면 더 명시적인 제약 모델을 검토해야 한다.
- 03
온톨로지 설계는 용어 목록부터 시작하기보다 competency question에서 시작해야 한다. Competency question은 이 모델이 답할 수 있어야 하는 질문이다. 예를 들어 어떤 업무 성공 기준을 확인해야 하는지, 어떤 증거가 있어야 역량을 인정할 수 있는지부터 잡는 방식이다. 역량 모델은 보통 competency, behavior, evidence, score_anchor, failure_mode 같은 구조를 가진다. LLM judge는 이 구조를 rubric으로 사용하고, 단순 점수가 아니라 판단 기준과 근거를 함께 남기게 된다.
- 04
RAG pipeline에서 ontology는 세부 기능이 아니라 schema contract에 가깝다. Query expansion은 ownership 같은 검색어를 관련 행동이나 동의어로 확장하고, metadata filter는 role=backend, competency=incident_response 같은 조건으로 검색 범위를 좁힌다. Answer grounding은 답변 claim을 ontology concept과 evidence chunk에 연결한다. Retrieval contract는 chunk가 어떤 concept, task, risk, policy에 속하는지 명시해 검색 결과를 후속 평가와 같은 schema로 넘긴다.
- 05
실무에서는 ontology를 별도 지식 그래프 제품으로만 생각하지 않는 것이 중요하다. 문서 chunk metadata에 concept_id, competency_id, evidence_type, risk_level을 넣으면 retriever, reranker, answer generator, evaluator가 같은 필드를 공유한다. GraphRAG나 knowledge graph RAG는 이 방향의 확장이다. 핵심은 검색 결과가 문장 유사도에서 끝나지 않고, 같은 도메인 개념과 같은 증거 구조 안에서 평가까지 이어지는 것이다.
- 06
LLM-as-judge에서는 구조화된 rubric이 특히 중요하다. judge prompt가 일반 문장으로만 되어 있고 score anchor가 없으면 judge는 숫자를 일관되게 쓰기 어렵다. competency model은 여기서 LLM eval의 schema 역할을 한다. competency, behavior, evidence, score_anchor, failure_mode를 분리하면 평가 결과가 감사 가능해진다. 이 구조가 없으면 평균 3.7점 같은 숫자만 남고, 어떤 역량 정의가 흔들렸는지, 어떤 증거가 부족했는지, rubric drift가 어디서 시작됐는지 추적하기 어렵다.
- 07
온톨로지와 rubric도 버전 관리 대상이다. concept 추가와 삭제 이력, synonym merge 규칙, deprecated term, owner와 review 주기, 평가 데이터와 rubric 버전 연결을 관리해야 한다. 모델 버전이 바뀌면 과거 평가 결과와 비교할 때 rubric drift를 고려해야 한다. 오래된 기준으로 평가되는 문제는 ontology와 rubric versioning이 없을 때 생긴다. prompt마다 용어가 달라지는 문제도 shared vocabulary가 없을 때 발생하므로 glossary나 ontology를 단일 원본으로 두어야 한다.
- 08
대표적인 silent failure는 증상만 보면 모델 품질 문제처럼 보이지만, 실제 원인은 구조 부재인 경우가 많다. judge 점수 일관성이 낮으면 역량 정의와 score anchor가 부족한 것이 원인일 수 있고, 복구 실마리는 competency model과 anchor 보강이다. RAG가 비슷하지만 틀린 문서를 검색하면 개념 관계나 metadata가 없는 것이 원인일 수 있으며, ontology 기반 filter와 query expansion을 적용한다. 평가 로그를 분석하기 어렵다면 점수만 저장하고 concept과 evidence를 남기지 않은 구조를 의심해야 한다.
- 09
이 개념은 HR/채용 SJT, 인터뷰 평가, 성과 리뷰 자동 보조, 사내 정책 Q&A, 보안/컴플라이언스 agent, 교육 플랫폼, 고객지원 챗봇에 쓰인다. 이 저장소의 layer, prerequisites, lineage_oneliner도 작은 온톨로지다. 문서를 단순 목록이 아니라 어떤 토픽이 어떤 토픽을 선행하는가로 모델링했기 때문에 validate-topology가 가능하다. 정리하면 RAG와 LLM eval을 따로 설계하지 말고, ontology를 retriever metadata, prompt context, judge rubric, 분석 대시보드가 공유하는 단일 계약으로 두는 것이 핵심이다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- 에이전트 오케스트레이션 운영 기준 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 에이전틱 LLM의 컨텍스트 파이프라인 길이 미정
- 상태 머신으로 LLM 워크플로를 다루기 길이 미정
- AI 워크플로를 위한 Temporal Durable Execution 길이 미정
- Human-in-the-loop AI 워크플로 설계 길이 미정
- 심리측정으로 설계하는 SJT와 LLM 평가 길이 미정