솔트룩스
경력근거: 온톨로지·Agentic AI를 아우르는 FDE 양성 및 채용
※ 실제 산출물이 아닌 AI 예측 시안입니다.
솔트룩스 FDE 공고는 온톨로지와 Agentic AI 를 함께 아우르는 사람을 뽑고, 데이터분석·데이터엔지니어·DBA 축과 RDBMS·NoSQL·Python 을 요구합니다. 지식그래프 위에서 에이전트가 다단계로 경로를 밟아 답하고 홉마다 근거를 대는 이 게이트는 그 두 축(온톨로지 지식그래프와 Agentic AI 계획)을 정면으로 보여줍니다. 다만 솔트룩스의 실제 고객 도메인(공공·금융·언어지능 제품 데이터)이나 SI 구축 현장의 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않고, 일반 도메인 온톨로지로 기술만 보이며 그 깊이는 면접에서 모르면 모른다고 말합니다. 에이전트가 밟은 경로를 그래프 탐색과 인용 청크로 채점하는 이 사슬은 단순 LLM 질의응답 맥락으로는 그대로 만들 수 없습니다.
온톨로지와 Agentic AI 를 함께 다루는 FDE 를 요구합니다. 지식그래프 위 다단계 탐색 에이전트가 정면으로 정렬됩니다.
데이터분석가·데이터엔지니어·DBA 축과 RDBMS·NoSQL·Python 스택을 요구합니다. 그래프 적재와 질의 파이프라인 구현이 정렬됩니다.
솔루션·SI·ERP·CRM 구축 맥락의 FDE 로, 고객 도메인 문제를 실제 산출물로 푸는 역할입니다. 도메인별로 갈아끼우는 질의 에이전트가 정렬됩니다.
도메인 질문을 받아 지식그래프 위에서 에이전트가 여러 홉으로 그래프를 타며 답을 찾습니다. 홉마다 어떤 엣지를 밟았는지와 그 엣지의 원문 근거 청크를 남기고, 근거 없는 홉이 나오거나 시작 노드가 없거나 홉 한도를 넘으면 답을 멈춥니다. 정답 여부는 지식그래프의 실제 경로 탐색과 인용 청크 일치로 결정하고, LLM 은 다음에 어떤 관계를 밟을지 계획하고 답 문장을 다듬는 보조만 맡습니다. 온톨로지 자체의 옳고 그름 판정이 아니라 그래프 위 다단계 질의의 근거 정합성 게이트입니다.
솔트룩스 FDE(온톨로지·Agentic AI 담당). 고객 도메인 지식그래프에 질문이 들어오면 에이전트가 어느 경로로 답에 닿았는지, 그 홉이 원문에 근거가 있는지를 일일이 되짚어 검수하던 일을, 한 화면에서 경로와 근거와 판정을 함께 보고 싶은 사람입니다.
도메인 지식그래프와 질문 세트를 한 스키마로 묶고 에이전트에 홉 계획을 맡기면, (a) 그래프에 없는 엣지나 근거 없는 홉을 규칙으로 걸러 오답을 막고, (b) 답에 닿은 경로를 원문 인용으로 풀며, (c) 여러 도메인 그래프를 끊김 없이 같은 질의 파이프라인으로 다룹니다.
도메인 지식그래프에 질문을 넣으면 에이전트가 여러 홉으로 경로를 밟아 답을 내고, 홉마다 실제 엣지·원문 근거·홉 한도를 검사해 근거 없는 홉이 나오면 멈추는 동작하는 에이전트입니다. 그래프·질문은 일반 도메인 더미로 시작하고, LLM 홉 계획은 사내 API 호출을 가정하지 않고 공개 모델 API 로 바로 돕니다.
에이전트가 낸 답과 경로를 심은 정답 경로·검수자 2명 라벨과 비교해 정확도와 경로 일치율, 검수자 일치도를 보여주는 화면입니다.
도메인·질문 홉수·거절 사유별 정답률과 근거 없는 홉 분포를 누적 집계해 약한 경로를 보여주는 화면입니다.
질문 시나리오 12종(단일 홉·다중 홉·근거 없는 홉·미존재 노드)을 넣으면, 경로·근거·답 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(끊긴 엣지·미등록 관계 타입·노드 표기 흔들림·홉 한도 초과)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 경로 40건 중 답·거절 판정이 일치한 게 34건(약 85%)입니다. 단, 그래프·질문·정답을 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
두 검수자의 답 라벨 일치도(Cohen's κ: 두 사람 답이 우연 이상으로 일치하는 정도, 0~1)를 2주차에 붙여 보여줍니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정확도·경로 일치율은 솔트룩스의 실 도메인 그래프와 실 검수자가 있어야 측정 가능합니다. 이 에이전트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
정답 경로를 작성자가 만들었으니 잘 맞는 게 당연합니다. 끊긴 엣지·미등록 관계 타입·노드 표기 흔들림·홉 한도 초과 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 단일 홉만 통과시키는 게 아님을 보여줍니다
이 포트폴리오는 온톨로지로 제약한 지식그래프 위 Agentic 다단계 탐색 + 근거·경로 정합성 검증 기술을 보여줍니다. 솔트룩스의 공공·금융·언어지능 제품 같은 실제 고객 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
LLM 이 계획한 홉은 그럴듯해도 그래프에 없거나 원문에 근거가 없을 수 있습니다. 홉마다 실제 엣지와 원문 청크 인용을 대게 하고, 근거가 없으면 답을 멈춰 오답을 막습니다
노드·관계 표기가 제각각입니다. 정규화로 같은 노드로 묶고 못 묶은 건 추측하지 말고 '미매핑 노드'로 알립니다. 실제 도입 시 온톨로지·관계 정의와 그래프 규모가 더미와 다르므로 관계 enum 과 홉 한도를 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
도메인 지식그래프의 엣지(관계) 목록. 에이전트가 홉을 밟을 때 실제로 존재하는지, 원문 근거 청크가 있는지 대조하는 그래프입니다. 노드 표기 흔들림·끊긴 엣지·근거 없는 엣지를 일부러 섞어 홉 탐색의 함정을 만듭니다.
| edge_id | src_raw | src_id | src_type | rel | dst_id | dst_type | grounded | chunk_id |
|---|---|---|---|---|---|---|---|---|
| e001 | 홍길동 | p_hong | Person | worksFor | c_acme | Company | true | ch_11 |
| e002 | 에이크미 | c_acme | Company | locatedIn | pl_seoul | Place | true | ch_12 |
| e003 | 홍 길동 | — | Person | knows | p_kim | Person | true | ch_13 |
| e004 | 에이크미 | c_acme | Company | acquired | c_beta | Company | false | — |
| e005 | 베타 | c_beta | Company | makes | pr_x1 | Product | true | ch_15 |
아래 JSON Schema 에 맞는 지식그래프 엣지 60행 JSON 배열로 생성합니다. 노드 타입 4~5종(Person·Company·Product·Place)과 관계 타입 8종을 섞고, 하나의 시작 노드에서 2~3홉으로 답에 닿는 경로가 만들어지게 엣지를 잇습니다.
{"type":"object","properties":{"edge_id":{"type":"string"},"src_raw":{"type":"string"},"src_id":{"type":["string","null"]},"src_type":{"type":"string"},"rel":{"type":"string"},"dst_id":{"type":["string","null"]},"dst_type":{"type":"string"},"grounded":{"type":"boolean"},"chunk_id":{"type":["string","null"]}},"required":["edge_id","src_raw","src_id","src_type","rel","dst_id","dst_type","grounded","chunk_id"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 단일 홉만 통과시키는 함정 회피): (1) 같은 노드의 표기 별칭(src_raw 가 '홍길동'/'홍 길동'처럼 흔들려 src_id 로 정규화돼야 하고, 못 묶으면 src_id=null) 3건 이상, (2) 근거 없는 엣지(grounded=false, chunk_id=null) 2건, (3) 끊긴 엣지(dst_id=null 인 orphan 목적어) 1~2건, (4) 3홉 이상 이어져야 답에 닿는 긴 경로 2건. grounded 와 chunk_id 정합성(grounded=false 면 chunk_id=null)을 지켜라. JSON 배열만.{"type":"object","properties":{"edge_id":{"type":"string"},"src_raw":{"type":"string"},"src_id":{"type":["string","null"]},"src_type":{"type":"string"},"rel":{"type":"string"},"dst_id":{"type":["string","null"]},"dst_type":{"type":"string"},"grounded":{"type":"boolean"},"chunk_id":{"type":["string","null"]}},"required":["edge_id","src_raw","src_id","src_type","rel","dst_id","dst_type","grounded","chunk_id"]}에이전트가 답해야 할 질문과 심은 정답 경로. 에이전트가 낸 경로·답을 이 정답과 대조해 자가채점합니다. 그래프에 근거 없는 홉이 낀 질문·시작 노드가 없는 질문·홉 한도를 넘는 질문을 섞어 거절이 정답인 케이스를 만듭니다.
| query_id | question | start_id | gold_path | gold_answer | max_hops | gold_decision |
|---|---|---|---|---|---|---|
| q001 | 홍길동이 일하는 회사는 어디에 있나요 | p_hong | ["worksFor","locatedIn"] | pl_seoul | 3 | answer |
| q002 | 홍길동이 세운 회사가 만드는 제품은 무엇인가요 | p_hong | ["foundedBy"] | — | 3 | refuse |
| q003 | 에이크미가 인수한 회사의 제품은 무엇인가요 | c_acme | ["acquired","makes"] | — | 3 | refuse |
| q004 | 김철수가 다니는 회사가 만드는 제품은 무엇인가요 | p_kim | ["worksFor","makes"] | pr_x1 | 3 | answer |
| q005 | 제품X1의 다음 세대 제품은 무엇인가요 | pr_x1 | ["supersedes"] | — | 2 | refuse |
아래 JSON Schema 에 맞는 질문 세트 40행 JSON 배열로 생성합니다. kg_edges 그래프 위에서 시작 노드부터 관계를 밟아 답에 닿는 질문을 만들고, gold_path 는 밟아야 할 관계 배열, gold_answer 는 도착 노드 id 로 심습니다.
{"type":"object","properties":{"query_id":{"type":"string"},"question":{"type":"string"},"start_id":{"type":["string","null"]},"gold_path":{"type":"array","items":{"type":"string"}},"gold_answer":{"type":["string","null"]},"max_hops":{"type":"integer"},"gold_decision":{"type":"string","enum":["answer","refuse","max_hops"]}},"required":["query_id","question","start_id","gold_path","gold_answer","max_hops","gold_decision"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 단일 홉만 통과시키는 함정 회피): (1) 경로 중간에 grounded=false 엣지를 밟아야 해서 답을 멈춰야 하는 refuse 케이스 3건 이상(gold_answer=null·gold_decision=refuse), (2) 시작 노드가 그래프에 없는 케이스(start_id=null·gold_decision=refuse) 2건, (3) 정답 경로가 max_hops 를 넘는 max_hops 케이스(gold_decision=max_hops·gold_answer=null) 2건, (4) 3홉 이상 정상 답 케이스 2건. gold_decision=answer 일 때만 gold_answer 를 채우고 나머지는 null 로 두어라. JSON 배열만.{"type":"object","properties":{"query_id":{"type":"string"},"question":{"type":"string"},"start_id":{"type":["string","null"]},"gold_path":{"type":"array","items":{"type":"string"}},"gold_answer":{"type":["string","null"]},"max_hops":{"type":"integer"},"gold_decision":{"type":"string","enum":["answer","refuse","max_hops"]}},"required":["query_id","question","start_id","gold_path","gold_answer","max_hops","gold_decision"]}| 온톨로지 | 질문에 답할 때 밟을 수 있는 관계(엣지 타입)를 제한하는 규칙 층입니다 |
| Agentic AI | 질문을 여러 홉으로 나눠 다음에 어떤 관계를 밟을지 계획하는 에이전트 루프입니다 |
| 지식그래프 | 노드·엣지로 도메인을 담고 홉 탐색으로 답을 찾는 저장소입니다 |
| RAG | 홉마다 엣지의 원문 근거 청크를 검색해 근거 인용에 붙이는 보조입니다 |
| Python | 그래프 적재·홉 탐색·정합성 규칙 엔진의 구현 언어입니다 |
| RDBMS | 질문·정답 경로·판정 로그를 담는 관계형 저장소입니다 |
| NoSQL | 원문 청크와 노드 속성을 담는 문서형 저장소입니다 |
| Claude | 홉 계획과 답 문장 정리를 맡는 LLM 입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(답이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(도메인·홉수별 정답률 추이)로 진행합니다.
질문 1건에 대한 에이전트의 답 카드. 결정·밟은 경로·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 온톨로지 옳고 그름이 아니라 그래프 위 다단계 질의의 근거 정합성 게이트입니다.
{"type":"object","properties":{"query_id":{"type":"string"},"decision":{"type":"string","enum":["answer","refuse","max_hops"]},"answer":{"type":["string","null"]},"path":{"type":"array","items":{"type":"object","properties":{"src":{"type":"string"},"rel":{"type":"string"},"dst":{"type":"string"},"chunk_id":{"type":["string","null"]}}}},"factors":{"type":"array","items":{"type":"string","enum":["ungrounded_hop","missing_start_node","missing_edge","hop_limit_exceeded","node_alias_unmapped"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["query_id","decision","answer","path","factors","reason","evidence","hedge"]}[
{
"input_ref": "q001 (2홉 정상 답)",
"output": {
"query_id": "q001",
"decision": "answer",
"answer": "pl_seoul",
"path": [
{
"src": "p_hong",
"rel": "worksFor",
"dst": "c_acme",
"chunk_id": "ch_11"
},
{
"src": "c_acme",
"rel": "locatedIn",
"dst": "pl_seoul",
"chunk_id": "ch_12"
}
],
"factors": [],
"reason": "홍길동이 worksFor 로 에이크미에 닿고 에이크미가 locatedIn 으로 서울에 닿아, 두 홉 모두 원문 근거 청크가 있어 답합니다.",
"evidence": "worksFor:ch_11, locatedIn:ch_12",
"hedge": null
}
},
{
"input_ref": "q003 (경로에 근거 없는 홉)",
"output": {
"query_id": "q003",
"decision": "refuse",
"answer": null,
"path": [
{
"src": "c_acme",
"rel": "acquired",
"dst": "c_beta",
"chunk_id": null
}
],
"factors": [
"ungrounded_hop"
],
"reason": "acquired 엣지가 원문 근거가 없어 LLM 이 지어냈을 수 있습니다. 근거 없는 홉을 밟지 않고 답을 멈춥니다.",
"evidence": "acquired grounded=false",
"hedge": "인수 관계에 원문 근거가 없어 답하지 않습니다"
}
},
{
"input_ref": "q006 (시작 노드 미존재)",
"output": {
"query_id": "q006",
"decision": "refuse",
"answer": null,
"path": [],
"factors": [
"missing_start_node"
],
"reason": "박영희에 해당하는 시작 노드가 그래프에 없어 첫 홉을 밟을 수 없습니다. 추측하지 않고 답을 멈춥니다.",
"evidence": "start_id=null",
"hedge": "시작 노드가 없어 답하지 않습니다"
}
},
{
"input_ref": "q008 (홉 한도 초과)",
"output": {
"query_id": "q008",
"decision": "max_hops",
"answer": null,
"path": [
{
"src": "p_hong",
"rel": "foundedBy",
"dst": "c_acme",
"chunk_id": "ch_18"
},
{
"src": "c_acme",
"rel": "locatedIn",
"dst": "pl_seoul",
"chunk_id": "ch_12"
},
{
"src": "pl_seoul",
"rel": "partOf",
"dst": "pl_kr",
"chunk_id": "ch_21"
}
],
"factors": [
"hop_limit_exceeded"
],
"reason": "정답에 닿으려면 홉 한도 3을 넘겨야 해서 한도 안에서는 답을 확정할 수 없습니다. 무리해서 답하지 않고 멈춥니다.",
"evidence": "max_hops=3 초과",
"hedge": "홉 한도 안에서 답에 닿지 못해 멈춥니다"
}
}
][자동 검증] 1. JSON Schema 형식 검증으로 출력의 필드·enum 이 스키마를 통과하는지 확인합니다(못 통과하면 화면 카드에 못 올리므로 거릅니다). 2. path 의 각 홉이 kg_edges 에 실제로 있는 엣지인지, chunk_id 가 그 엣지의 근거 청크와 일치하는지 토큰 매칭으로 확인하고, grounded=false 엣지를 밟았으면 answer 가 되지 않게 강제합니다. 3. decision 이 정합성 규칙(근거 없는 홉·미존재 시작 노드·미존재 엣지→refuse·홉 한도 초과→max_hops·정상 도달→answer)과 일치하는지 봅니다. 4. answer·gold_decision 을 심은 정답 경로·gold_answer 와 비교해 정확도와 경로 일치율을 계산합니다. [수동 검증] 1. 검수자 2명이 비동기로 답·경로를 라벨링해 정확도와 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.
근거: 온톨로지·Agentic AI를 아우르는 FDE 양성 및 채용