람다256
경력근거: 온톨로지 기반 개념 모델과 지식그래프로 구조화
※ 실제 산출물이 아닌 AI 예측 시안입니다.
람다256 은 루니버스·Nodit 으로 온체인 데이터를 다루고, 이 채용은 온체인 데이터를 '온톨로지 기반 개념 모델과 지식그래프로 구조화' 해 분석·탐색·추론으로 잇는 역할입니다. 주소·트랜잭션·토큰·라벨이 얽힌 복잡한 관계형 데이터를 그래프로 모델링해 자연어로 묻는 이 콘솔은, 그런 온체인 관계 데이터 도메인이 있어야 의미가 있습니다. 다만 이 포트폴리오는 온톨로지 설계·지식그래프·GraphRAG 라는 기술 역량을 보여주며, 블록체인·온체인·AML·컴플라이언스 도메인 전문성은 주장하지 않습니다. same_entity 클러스터링을 실제 자금세탁 판정처럼 확대 해석하지 않고, 정답은 그래프 탐색과 인용 청크 일치로 객관 채점하며 모르는 도메인 깊이는 면접에서 모른다고 말합니다.
이 포지션의 본질은 복잡한 도메인 데이터를 온톨로지 기반 개념 모델과 지식그래프로 구조화하는 것입니다. 그래서 제품의 뼈대도 노드 클래스·관계를 먼저 설계하는 온톨로지 모델링입니다.
우대사항에 LLM/RAG 와 지식그래프를 결합한 시스템 설계 경험이 명시됩니다. 자연어 질문을 그래프 쿼리로 번역하고 서브그래프만 인용해 답하는 GraphRAG 가 정확히 그 축입니다.
블록체인·온체인 데이터처럼 복잡한 관계형 데이터 이해가 우대됩니다. 주소·트랜잭션·토큰이 얽힌 관계를 그래프로 모델링하는 데 자연스럽게 닿되, 도메인 자체는 테마로만 가볍게 씁니다.
온체인 데이터(주소·트랜잭션·토큰·라벨)를 온톨로지 개념 모델과 지식그래프로 구조화하고, "이 주소에서 3-hop 안에 거래소 입금주소에 자금이 닿나요?" 같은 자연어 질문을 그래프 쿼리로 번역해 근거 경로와 인용 노드를 붙여 답하는 관리자 페이지입니다. 정답 판정은 그래프 탐색이라는 결정론이 맡고 LLM 은 번역·요약만 맡아 환각이 답을 통과하지 못합니다. 1주차만으로 동작하는 완성품이고, 답이 맞았는지 객관 검증(2주차)·다중 홉 추론과 정합성 검증(3주차)으로 키웁니다. (근거는 채용공고 정렬이고, 데이터는 작성자가 만든 더미입니다.)
람다256 온톨로지·지식그래프 FDE. 온체인 데이터의 복잡한 관계를 매번 손으로 쿼리를 짜 뒤지던 상황을 끝내고, 자연어로 묻고 근거 경로까지 함께 받고 싶은 사람입니다.
온체인 데이터를 온톨로지(클래스·관계)로 모델링해 지식그래프로 적재하면, 자연어 질문을 (a) 그래프 쿼리로 번역하고 (b) 3-hop 이내 서브그래프를 탐색해 (c) 그 서브그래프 안의 노드·트랜잭션만 인용해 답하며, 정답 여부는 그래프 탐색 결과와 인용 일치로 객관 채점됩니다.
합성 온체인 지식그래프(노드·엣지 더미)를 그래프 저장소에 적재하고, 자연어 질문을 그래프 쿼리로 번역해 서브그래프 경로와 인용 노드를 붙여 답하는 GraphRAG 콘솔입니다. 질문 유형 5종으로 도는 완성품입니다. 온체인 데이터는 실제 노드 접속 대신 작성자가 만든 합성 그래프 더미로 시작합니다.
답의 근거 경로를 그래프 탐색 결정론 결과와 대조하고, 인용한 노드·트랜잭션이 서브그래프에 실제 존재하는지(grounding) 자동 검사하며, 온톨로지 클래스 매핑을 검토자 2명이 라벨링해 일치도를 보여주는 대시보드입니다.
홉 깊이를 넓힌 다중 홉 추론과, 실데이터 매핑·적재 시 미매핑 orphan·표기흔들림을 잡는 정합성 검증 규칙, 확신도 보정까지 더해 온톨로지 커버리지를 키우는 단계입니다.
질문 30개(경로 존재·토큰 흐름·클러스터·라벨·경로 없음)를 넣으면, 자연어 질문이 그래프 쿼리로 번역되고 서브그래프 경로와 인용 노드가 붙은 답이 몇 초 안에 나오는 걸 시연합니다
답이 인용한 트랜잭션·노드가 실제 탐색 서브그래프에 100% 존재하는지 자동 대조합니다(서브그래프에 없는 tx 를 인용하는 환각을 형식 검증에서 차단). 단, 정답과 그래프를 모두 작성자가 만든 합성 기준이므로 '성능 검증' 이 아니라 '데모 조건에서의 동작' 입니다
일부러 만든 미매핑 주소·표기흔들림·0값 전송·끊긴 외래키 등 하드 케이스 20종을 넣어도 출력 스키마가 한 번도 안 깨지고, 억지 답 대신 '온톨로지 미등록' '3-hop 내 경로 없음' 으로 정직하게 답합니다
위 수치는 전부 작성자가 만든 합성 온체인 그래프 자가채점이며, 실제 정확도는 람다256 의 실 온체인 데이터 + 실 도메인 검수자가 있어야 측정 가능합니다. 이 콘솔은 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오라 모든 수치는 합성 그래프 자가채점이고 '성능 증명' 이 아닙니다. 면접에서 '데모 조건 동작 + 실검증 준비 상태' 로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 미매핑 주소·표기흔들림·0값 전송·끊긴 외래키·경로 없음 질문을 더미에 일부러 섞어, 쉬운 문제만 푸는 게 아님을 보여줍니다
이 포트폴리오는 온톨로지 설계·지식그래프·GraphRAG 라는 기술 역량을 보여주며, 블록체인·온체인·AML·컴플라이언스 도메인 전문성은 주장하지 않습니다. same_entity 클러스터링을 실제 자금세탁 판정으로 확대 해석하지 않고, 모르는 도메인 깊이는 면접에서 모른다고 말하는 편이 낫습니다
추론과 관측은 다릅니다. same_entity·라벨은 추론이라 관측된 transfer 와 구분해 표기하고, 답변이 추론을 관측으로 단정하지 못하게 grounding 검사로 거릅니다. 상관을 인과로 비약하는 표현도 별도 judge 로 잡습니다
실제 도입 시 달라지는 것을 명시합니다. 실 온체인 데이터는 규모·노이즈가 크고 주소 라벨은 외부 인텔리전스가 필요하므로, 그래프 저장·탐색 성능과 라벨 소스를 실제 환경 기준으로 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
지식그래프의 노드(주소·컨트랙트·토큰)와 각 노드의 온톨로지 클래스·라벨·별칭. GraphRAG 가 시작 노드를 찾고 클래스를 답할 때 가장 먼저 조회하는 테이블입니다. 주소 표기가 제각각(체크섬/소문자)이고 라벨이 없거나 정규화가 실패하는 현실을 그대로 담아, 쉬운 데이터만 푸는 게 아님을 보여줍니다.
| node_id | address_raw | address_norm | onto_class | label | aliases | first_seen |
|---|---|---|---|---|---|---|
| n_a1 | 0xA1f3C0dE0000000000000000000000000000… | 0xa1f3c0de0000000000000000000000000000… | EOA | 관찰 지갑 A | ["0xa1f3c0de00000000000000000000000000000a1","0xA1F3C0DE00000000000000000000000000000A1"] | 2026-02-03T09:12:00Z |
| n_h1 | 0xh10000000000000000000000000000000000… | 0x110000000000000000000000000000000000… | EOA | — | [] | 2026-02-04T11:40:00Z |
| n_h2 | 0x220000000000000000000000000000000000… | 0x220000000000000000000000000000000000… | EOA | — | [] | — |
| n_h3 | 0x330000000000000000000000000000000000… | 0x330000000000000000000000000000000000… | EOA | — | [] | 2026-02-05T08:05:00Z |
| n_ex1 | 0xExDEP0000000000000000000000000000000e1 | 0xexdep0000000000000000000000000000000e1 | ExchangeDeposit | 거래소 입금주소(가상) | ["0xEXDEP0000000000000000000000000000000E1"] | 2026-01-20T00:00:00Z |
아래 JSON Schema 에 맞는 온체인 지식그래프 노드 40행을 JSON 배열로 생성. node_id 는 n_ 접두, address_raw 는 0x 40자리 형태(가상), onto_class 분포 자연스럽게.
{"type":"object","properties":{"node_id":{"type":"string"},"address_raw":{"type":"string"},"address_norm":{"type":["string","null"]},"onto_class":{"type":"string","enum":["EOA","Contract","Token","ExchangeDeposit","Bridge","Mixer","Unknown"]},"label":{"type":["string","null"]},"aliases":{"type":"array","items":{"type":"string"}},"first_seen":{"type":["string","null"]}},"required":["node_id","address_raw","onto_class","aliases"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 문제만 푸는 함정 회피): (1) 표기흔들림. 같은 주소의 체크섬/소문자 표기를 aliases 에 넣어 정규화가 필요하게(address_raw 와 aliases 가 대소문자만 다른 케이스 2~3건), (2) 미매핑/파싱 실패. address_norm 이 null 이고 onto_class=Unknown 인 orphan 노드 1~2건, (3) 라벨 결측. label=null, onto_class=Unknown 인 노드 2~3건, (4) first_seen 결측 null 2~3건. JSON 배열만.{"type":"object","properties":{"node_id":{"type":"string"},"address_raw":{"type":"string"},"address_norm":{"type":["string","null"]},"onto_class":{"type":"string","enum":["EOA","Contract","Token","ExchangeDeposit","Bridge","Mixer","Unknown"]},"label":{"type":["string","null"]},"aliases":{"type":"array","items":{"type":"string"}},"first_seen":{"type":["string","null"]}},"required":["node_id","address_raw","onto_class","aliases"]}지식그래프의 엣지(관측된 온체인 관계 + 추론된 온톨로지 관계). transfer·deploy·approve·holds 는 트랜잭션으로 관측된 관계고, same_entity 는 추론된 클러스터 관계입니다. GraphRAG 의 경로 탐색·클러스터 조회가 이 테이블을 훑습니다. 관측/추론을 구분하고 0값·결측·끊긴 외래키를 섞어, 답변이 근거 없이 단정하지 못하게 합니다.
| edge_id | src_id | dst_id | edge_type | tx_hash | value_token | token_id | block_time |
|---|---|---|---|---|---|---|---|
| e1 | n_a1 | n_h1 | transfer | 0xaa1 | 2.5 | ETH | 2026-02-04T11:40:00Z |
| e2 | n_h1 | n_ex1 | transfer | 0xaa2 | 2.4 | ETH | 2026-02-04T12:10:00Z |
| e3 | n_a1 | n_h2 | transfer | 0xaa3 | 1 | ETH | 2026-02-04T13:00:00Z |
| e4 | n_h2 | n_h3 | transfer | 0xaa4 | 0 | ETH | 2026-02-04T13:30:00Z |
| e5 | n_h3 | n_ex2 | transfer | 0xaa5 | 0.9 | ETH | — |
아래 JSON Schema 에 맞는 온체인 지식그래프 엣지 50행을 JSON 배열로 생성. src_id·dst_id 는 onchain_nodes 의 node_id 와 매칭되게, edge_type 분포는 transfer 다수 + deploy/approve/holds/same_entity 소수.
{"type":"object","properties":{"edge_id":{"type":"string"},"src_id":{"type":"string"},"dst_id":{"type":"string"},"edge_type":{"type":"string","enum":["transfer","deploy","approve","holds","same_entity"]},"tx_hash":{"type":["string","null"]},"value_token":{"type":["number","null"]},"token_id":{"type":["string","null"]},"block_time":{"type":["string","null"]}},"required":["edge_id","src_id","dst_id","edge_type"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 추론 관계 결측. same_entity 는 tx_hash·value_token·token_id 를 모두 null 로(관측이 아니라 추론이므로) 3~5건, (2) 비전송 관계 결측. deploy/approve/holds 의 value_token 또는 tx_hash 가 null 인 행 각 1~2건, (3) 경계값. value_token=0.0 인 0값 전송 1~2건, (4) 끊긴 외래키. dst_id 가 onchain_nodes 에 없는 orphan(예: n_zz9) 1건(탐색이 '미매핑' 으로 알려야 함), (5) block_time 결측 null 2~3건. JSON 배열만.{"type":"object","properties":{"edge_id":{"type":"string"},"src_id":{"type":"string"},"dst_id":{"type":"string"},"edge_type":{"type":"string","enum":["transfer","deploy","approve","holds","same_entity"]},"tx_hash":{"type":["string","null"]},"value_token":{"type":["number","null"]},"token_id":{"type":["string","null"]},"block_time":{"type":["string","null"]}},"required":["edge_id","src_id","dst_id","edge_type"]}| Python | 온체인 더미 적재 파이프라인(노드·엣지 → 그래프 저장소), NL→쿼리 평가·grounding 검사 스크립트 |
| LLM | Claude Sonnet 으로 자연어 질문을 그래프 쿼리로 번역하고, 탐색된 서브그래프를 근거로 답변 문장을 생성합니다(변환·요약만, 정답 판정은 그래프 탐색이 담당) |
| RAG | GraphRAG. 벡터 검색이 아니라 질문에서 시작 노드를 찾아 3-hop 이내 서브그래프를 검색하고, 그 서브그래프 안의 노드·트랜잭션만 인용하도록 grounding 합니다 |
| Neo4j / Cypher | 지식그래프 저장·탐색. 자연어에서 번역된 Cypher 형 쿼리로 경로·클러스터를 조회합니다(소규모는 networkx BFS 로 결정론 정답을 산출) |
| Next.js / TypeScript | GraphRAG 콘솔 UI. 질문 입력, 답변, 근거 경로·인용 노드를 그래프로 시각화합니다 |
| FastAPI | 질의 API(POST /ask: 질문 입력 → output_schema 반환) |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(답이 객관적으로 맞았는지 검증)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(다중 홉 추론·정합성 검증 확장)로 진행합니다.
자연어 질문을 그래프 쿼리로 번역해 3-hop 이내 서브그래프를 탐색하고, 근거 경로·인용 노드와 함께 답을 냅니다. 정답은 그래프 탐색(결정론)과 인용 노드·트랜잭션이 실제 서브그래프에 존재하는지(grounding)로 객관 채점합니다.
{"type":"object","properties":{"q_id":{"type":"string"},"intent":{"type":"string","enum":["path_exists","token_flow","cluster_lookup","label_lookup","no_path"]},"generated_query":{"type":"string"},"answer_ko":{"type":"string"},"path":{"type":"array","items":{"type":"object","properties":{"edge_id":{"type":"string"},"tx_hash":{"type":["string","null"]},"from":{"type":"string"},"to":{"type":"string"}},"required":["edge_id","from","to"]}},"cited_nodes":{"type":"array","items":{"type":"string"}},"confidence":{"type":"string","enum":["low","mid","high"]},"grounding_ok":{"type":"boolean"}},"required":["q_id","intent","answer_ko","path","cited_nodes","grounding_ok"]}[
{
"input_ref": "Q1: \"n_a1 에서 3-hop 안에 거래소 입금주소(ExchangeDeposit)에 자금이 닿나요?\"",
"output": {
"q_id": "q_001",
"intent": "path_exists",
"generated_query": "MATCH p=(a {node_id:'n_a1'})-[:transfer*1..3]->(x) WHERE x.onto_class='ExchangeDeposit' RETURN p LIMIT 1",
"answer_ko": "예. n_a1 → n_h1 → n_ex1 2-hop 경로로 거래소 입금주소(n_ex1)에 닿습니다. 두 전송 모두 관측된 트랜잭션(0xaa1, 0xaa2)입니다.",
"path": [
{
"edge_id": "e1",
"tx_hash": "0xaa1",
"from": "n_a1",
"to": "n_h1"
},
{
"edge_id": "e2",
"tx_hash": "0xaa2",
"from": "n_h1",
"to": "n_ex1"
}
],
"cited_nodes": [
"n_a1",
"n_h1",
"n_ex1"
],
"confidence": "high",
"grounding_ok": true
}
},
{
"input_ref": "Q2: \"n_d4 에서 3-hop 안에 믹서(Mixer)로 가는 경로가 있나요?\"",
"output": {
"q_id": "q_002",
"intent": "no_path",
"generated_query": "MATCH p=(a {node_id:'n_d4'})-[:transfer*1..3]->(x) WHERE x.onto_class='Mixer' RETURN p LIMIT 1",
"answer_ko": "3-hop 이내 경로가 없습니다. n_d4 은 전송 이력이 없어 믹서로 닿는 경로를 찾지 못했습니다. 없는 경로를 지어내지 않고 '경로 없음' 으로 보고합니다.",
"path": [],
"cited_nodes": [
"n_d4"
],
"confidence": "high",
"grounding_ok": true
}
},
{
"input_ref": "Q3: \"n_a1 과 같은 주체로 추정되는 지갑은?\"",
"output": {
"q_id": "q_003",
"intent": "cluster_lookup",
"generated_query": "MATCH (a {node_id:'n_a1'})-[:same_entity*1..2]-(y) RETURN DISTINCT y",
"answer_ko": "n_b2, n_h1 이 same_entity 추론으로 동일 주체 클러스터에 묶입니다. 다만 same_entity 는 트랜잭션으로 관측된 관계가 아니라 추론된 관계라, 확정이 아니라 추정으로만 제시합니다.",
"path": [
{
"edge_id": "e9",
"tx_hash": null,
"from": "n_a1",
"to": "n_b2"
},
{
"edge_id": "e10",
"tx_hash": null,
"from": "n_b2",
"to": "n_h1"
}
],
"cited_nodes": [
"n_a1",
"n_b2",
"n_h1"
],
"confidence": "mid",
"grounding_ok": true
}
},
{
"input_ref": "Q4: \"n_orphan 주소는 어떤 온톨로지 클래스인가요?\"",
"output": {
"q_id": "q_004",
"intent": "label_lookup",
"generated_query": "MATCH (n {node_id:'n_orphan'}) RETURN n.onto_class, n.address_norm",
"answer_ko": "온톨로지 미등록입니다. n_orphan 은 주소 정규화(address_norm)가 실패해 클래스가 부여되지 않았습니다(Unknown). 억지로 클래스를 추측하지 않고 '미매핑' 으로 보고합니다.",
"path": [],
"cited_nodes": [
"n_orphan"
],
"confidence": "high",
"grounding_ok": true
}
}
][자동 검증] 1. JSON Schema 통과: 필드·enum(intent·confidence) 형식이 맞는지. 2. 인용 실재성: path 의 각 edge_id·tx_hash 와 cited_nodes 가 onchain_edges·onchain_nodes 에 실제 존재하는지 집합 대조. 서브그래프에 없는 tx 를 인용하면 환각으로 보고 grounding_ok=false 처리 후 실패. 3. 경로 정답: path_exists·no_path 답의 예/아니오를 결정론적 그래프 탐색(networkx BFS 3-hop 이내) 결과와 대조. 4. 쿼리 번역 정확도: generated_query 를 실제 그래프에 실행해 gold 서브그래프의 노드 집합과 일치하는지(자연어→쿼리 번역이 맞는지). [수동 검증] 1. 온톨로지 매핑 타당성: 검토자 2명이 같은 주소에 같은 onto_class 를 부여하는지 라벨링해 일치도 측정(Cohen's κ: 두 사람 답이 우연 이상으로 일치하는 정도, 0~1, 하한 0.6 이상 목표). 2. 추론 과단정 spot check: same_entity 추론을 관측(transfer)으로 오인해 단정하지 않았는지 5% 표본 사람 점검.