람다Ontology Engineer (FDE)
2.8 (72)람다256
경력근거: 이를 온톨로지 기반 개념 모델과 지식그래프로 구조화하여 분석·탐색·추론·AI 활용 시스템으로 연결
35일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
람다256 FDE(온톨로지·지식그래프 스페셜리스트)는 도메인 데이터를 온톨로지 개념 모델과 지식그래프로 구조화하고, 실제 데이터의 모델 매핑·적재·정합성 검증을 PoC 단계부터 수행하며 LLM/RAG 와 지식그래프를 결합합니다. 트리플을 온톨로지 스키마로 검증해 적재하는 이 게이트는 그 핵심(온톨로지 모델링·정합성 검증·LLM+그래프 결합) 기술을 정면으로 보여줍니다. 블록체인·금융·AML 같은 우대 도메인 전문성은 포트폴리오로 증명되지 않으므로 일반 도메인 온톨로지로 기술만 보이고, 그 깊이는 면접에서 솔직히 다룹니다. 트리플 추출을 온톨로지 규칙·근거 검사로 잇는 사슬은 단순 LLM 추출 맥락으로는 그대로 만들 수 없습니다.
도메인 데이터를 온톨로지 기반 개념 모델과 지식그래프로 구조화합니다. 스키마 검증 적재가 직접 정렬됩니다.
실제 데이터의 모델 매핑·적재와 정합성 검증을 수행합니다. 트리플 정합성 게이트가 환경과 정렬됩니다.
LLM/RAG 와 지식그래프를 결합한 시스템 설계를 다룹니다. LLM 추출 + 그래프 적재가 결합과 정렬됩니다.
도메인 텍스트에서 LLM 이 뽑은 트리플(주어·관계·목적어·근거)을 받아, 규칙(허용 타입·관계 위반·원문 미근거·양끝 노드 미존재·결측)으로 적재할지 검토할지 막을지 정합니다. 정답 여부는 온톨로지 스키마와 원문 근거로 결정하고, LLM 은 추출·근거 인용 보조만 맡습니다. 온톨로지 자체의 옳고 그름 판정이 아니라 스키마 정합성 게이트입니다.
람다256 FDE(온톨로지·지식그래프 스페셜리스트). LLM 추출 트리플을 온톨로지에 맞는지 일일이 대조해 적재할지 거를지 판단하던 일을, 한 게이트에서 추출·근거·정합성 결과를 함께 보고 싶은 사람입니다.
추출 트리플을 한 스키마로 묶고 온톨로지(허용 타입·관계)를 붙이면, (a) 스키마 위반·원문 미근거·끊긴 노드를 규칙으로 거르고, (b) 적재 근거를 원문 인용으로 풀며, (c) 여러 도메인 텍스트를 끊김 없이 그래프로 적재합니다.
도메인 텍스트에서 트리플을 추출하고 온톨로지 스키마·원문 근거·노드 정합성을 검사해 통과만 적재하는 동작하는 게이트입니다. 텍스트·온톨로지는 일반 도메인 더미로 시작합니다.
적재 판정을 심은 정답 트리플·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
도메인·관계 타입별 적재 정합성과 거름 사유 분포를 누적 집계해 약한 매핑을 보여주는 화면입니다.
추출 시나리오 12종(정상·미근거·스키마 위반)을 넣으면, 추출·근거·정합성 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(노드 결측·미등록 관계 타입·엔티티 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 트리플 40건 중 적재/거름 판정이 일치한 게 35건(약 88%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 람다256 의 실 도메인 데이터와 실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
이 포트폴리오는 온톨로지 스키마로 제약한 LLM 트리플 추출 + 근거·정합성 검증 + 그래프 적재 기술을 보여줍니다. 블록체인·금융·AML·온체인 데이터 같은 람다256 의 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 일반 도메인 온톨로지로 기술만 보여줍니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 끊긴 노드·미등록 관계 타입·엔티티 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 추출만 통과시키는 게 아님을 보여줍니다
LLM 이 뽑은 관계는 그럴듯해도 원문에 없을 수 있습니다. 트리플마다 원문 인용을 달게 하고, 근거가 없으면 '미근거'로 걸러 그래프에 적재하지 않습니다
엔티티·관계 표기가 제각각입니다. 정규화로 같은 노드로 묶고, 못 묶은 건 추측하지 말고 '미해결 노드'로 알립니다. 실제 도입 시 온톨로지·관계 정의가 더미와 다르므로 스키마를 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
온톨로지 기반 트리플 추출·적재 로그. 정합성 규칙이 가장 먼저 질의하는 테이블입니다. 노드 결측·미등록 관계 타입·엔티티 표기 흔들림을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| triple_id | domain_raw | domain_id | subj_type | rel | obj_type | rel_in_ontology | grounded | nodes_exist | label | ts |
|---|---|---|---|---|---|---|---|---|---|---|
| kg_001 | 조직 | org | Person | worksFor | Company | true | true | true | load | 2026-03-04T09:00 |
| kg_002 | 조직 | org | Person | marriedTo | Company | false | true | true | reject | 2026-03-04T10:00 |
| kg_003 | 제품 | product | Product | madeBy | Company | true | false | true | reject | 2026-03-04T11:00 |
| kg_004 | 제 품 | product | Product | partOf | Product | true | true | false | review | 2026-03-04T12:00 |
| kg_005 | 신규도메인X | — | Entity | relatedTo | Entity | true | true | true | review | 2026-03-04T13:00 |
아래 Zod 스키마에 맞는 트리플 추출 60행 JSON 배열로 생성합니다. 도메인 2~3개, 관계 타입 분포, 정상 위주에 거름·검토를 섞습니다. label 규칙: rel_in_ontology=false 또는 grounded=false → reject, nodes_exist=false 또는 domain_id=null → review, 그 외(타입·관계·근거·노드 모두 정상) → load.
{"type":"object","properties":{"triple_id":{"type":"string"},"domain_raw":{"type":"string"},"domain_id":{"type":["string","null"]},"subj_type":{"type":"string"},"rel":{"type":"string"},"obj_type":{"type":"string"},"rel_in_ontology":{"type":"boolean"},"grounded":{"type":"boolean"},"nodes_exist":{"type":"boolean"},"label":{"type":"string","enum":["load","review","reject"]},"ts":{"type":"string"}},"required":["triple_id","domain_raw","domain_id","subj_type","rel","obj_type","rel_in_ontology","grounded","nodes_exist","label","ts"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 추출만 통과시키는 함정 회피): (1) 같은 도메인의 표기 별칭('조직'/'조 직', '제품'/'제 품'처럼 domain_master 로 정규화돼야 함) 3건 이상, (2) 미등록 도메인(domain_id=null) 2건, (3) 결측: nodes_exist=false 인 끊긴 노드 행 1~2건, (4) 경계값 — 온톨로지에 없는 관계(rel_in_ontology=false)·원문 미근거(grounded=false) 각 2건, (5) 노드 일부만 존재하는 review 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"triple_id":{"type":"string"},"domain_raw":{"type":"string"},"domain_id":{"type":["string","null"]},"subj_type":{"type":"string"},"rel":{"type":"string"},"obj_type":{"type":"string"},"rel_in_ontology":{"type":"boolean"},"grounded":{"type":"boolean"},"nodes_exist":{"type":"boolean"},"label":{"type":"string","enum":["load","review","reject"]},"ts":{"type":"string"}},"required":["triple_id","domain_raw","domain_id","subj_type","rel","obj_type","rel_in_ontology","grounded","nodes_exist","label","ts"]}| LLM | 도메인 텍스트에서 엔티티·관계 트리플을 추출하고 근거를 인용하는 핵심 엔진입니다 |
| RAG | 온톨로지 정의·유사 엔티티를 검색해 매핑 정확도를 높이는 보조입니다 |
| 지식그래프 | 통과한 트리플을 적재하는 그래프(노드·엣지) 저장소입니다 |
| TypeScript | 추출 파서·온톨로지 검증 규칙·출력 스키마(Zod)의 구현 언어입니다 |
| Zod | 온톨로지 스키마(허용 타입·관계)와 LLM 출력의 런타임 형식 검증입니다 |
| Claude | 트리플 추출·근거 인용 LLM 입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(적재가 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(도메인별 적재 정합성 추이)로 진행합니다.
트리플 1건의 적재 결정 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 온톨로지 옳고 그름이 아니라 스키마 정합성 게이트입니다.
{"type":"object","properties":{"triple_id":{"type":"string"},"domain_id":{"type":["string","null"]},"decision":{"type":"string","enum":["load","review","reject"]},"factors":{"type":"array","items":{"type":"string","enum":["relation_not_in_ontology","ungrounded","missing_node","unmapped_domain","missing_metric"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["triple_id","domain_id","decision","factors","reason","evidence","hedge"]}[
{
"input_ref": "kg_002 (온톨로지에 없는 관계)",
"output": {
"triple_id": "kg_002",
"domain_id": "org",
"decision": "reject",
"factors": [
"relation_not_in_ontology"
],
"reason": "Person→marriedTo→Company 는 온톨로지에 정의되지 않은 관계라 그래프 정합성을 깨뜨립니다. 적재하지 않고 거릅니다.",
"evidence": "rel=marriedTo, rel_in_ontology=false",
"hedge": "온톨로지에 없는 관계라 적재하지 않습니다"
}
},
{
"input_ref": "kg_003 (원문 미근거)",
"output": {
"triple_id": "kg_003",
"domain_id": "product",
"decision": "reject",
"factors": [
"ungrounded"
],
"reason": "madeBy 관계가 원문에 근거가 없어 LLM 이 지어냈을 수 있습니다. 근거 없는 관계는 그래프에 적재하지 않습니다.",
"evidence": "grounded=false",
"hedge": "원문 근거가 없어 적재하지 않습니다"
}
},
{
"input_ref": "kg_004 (끝 노드 미존재)",
"output": {
"triple_id": "kg_004",
"domain_id": "product",
"decision": "review",
"factors": [
"missing_node"
],
"reason": "관계·근거는 정상이나 목적어 노드가 그래프에 아직 없어 바로 잇지 않습니다. 노드 생성 후 재평가가 필요해 검토로 돌립니다.",
"evidence": "nodes_exist=false, grounded=true",
"hedge": "끝 노드가 없어 적재하지 않고 검토로 둡니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 정합성 규칙(관계 미정의/미근거→reject·끊긴 노드/미등록 도메인→review·통과→load)과 일치하는지 봅니다. 3. evidence 가 입력 트리플의 실제 값 인용인지 토큰 매칭으로 확인하고, grounded=false 면 load 가 되지 않게 강제합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 적재를 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.