팔란티어(Palantir) 서비스 개요팔란티어 파운드리(Palantir Foundry)는 기업 내부에 산재한 방대한 데이터를 수집하여 하나의 '디지털 트윈(Digital Twin)'으로 형상화하는 데이터 플랫폼 소프트웨어다. 단순한 데이터 시각화를 넘어, 물리적 세계의 데이터를 객체로 모델링하고 이를 기반으로 실제 비즈니스 프로세스를 작동시키는 '액션(Action)' 중심의 에이전틱 AI 체계를 제공한다.https://www.palantir.com/platforms/aip/ Palantir Artificial Intelligence PlatformRun LLMs and other models on your private network with full control.www.palantir.com 팔란티..
TL;DR국내 데이터 선도 기업들은 예외 없이 ①데이터 민주화(로그·SQL·BI로 전사 셀프서브) → ②신뢰성·거버넌스(지표 표준화·데이터 카탈로그·리니지·품질) → ③AI/ML 내재화(추천·예측 모델, 그리고 2025~2026년 LLM/MCP 기반 셀프서브) 라는 3단계 로드맵을 공통적으로 밟았다. 가장 상세히 문서화된 벤치마크는 당근(중앙 데이터가치화팀 + KarrotMetrics + 3년 로드맵)과 마이리얼트립(시즌1 데이터 민주화 → 시즌2 파이프라인·거버넌스 → MySQLTrip LLM 자동화)이다.데이터사이언티스트·AI/ML 커리어 관점의 핵심 시사점은 "모델링 이전에 신뢰 가능한 지표·로그·파이프라인이 먼저"라는 것이며, LLM 시대에 데이터 조직의 역할은 "답을 대신 만들어주는 팀"에서 "..
온톨로지의 제약이나 추론을 하기 전에 "그런데 온톨로지가 정확히 뭔데?", "지식그래프는 그래서 어떻게 만드는 건데?"라는 질문이 먼저 나온다. 용어부터 진입장벽이 있고 막상 "만드는 법"을 처음부터 끝까지 보여주는 글은 드물다. 개념 설명은 W3C 명세처럼 딱딱하거나, 튜토리얼은 너무 간단하게 노드와 엣지로 설명하고 끝나는 경우가 있다. 그래서 이 글은 하나의 실제 프로젝트를 가정하고 실용적인 관점에서 작성하고자 시작했다. 합성 의료 데이터(Synthea) CSV 뭉치를 받아서, 온톨로지를 설계하고, 트리플로 변환해 그래프 데이터베이스에 적재하고, 쿼리하는 것까지를 다룬다. 이 과정에서 온톨로지란 무엇인지, 그리고 지식그래프의 대표적인 구조인 RDF와 LPG가 실제로 뭐가 다른지를 정리하고자 한다. 이..
4편까지의 내용은 검증된 근거만 LLM에 사용하는 구조를 만들었다. 남은 문제는 LLM이 그 근거로 답을 만드는 순간이다.근거에 없는 내용을 생성하거나, 근거 두 개를 잘못 결합하거나, 근거와 반대로 말하는 일은 생성 단계에서 여전히 일어난다.그리고 더 근본적인 문제로 사람이 "이 답이 왜 이렇게 나왔는지"를 확인할 방법이 없다면, 아무리 내부가 정교해도 시스템 전체는 블랙박스다. 이번 편은 그 마지막 조각인 provenance(출처·이력 정보)와 평가에 대한 내용이다. 답변에 "이 답은 이런 쿼리를 실행했고, 이런 공리를 따라 탐색했고, 이런 검증을 통과한 근거에서 나왔다"는 기록을 같이 보여주어 사람이 답을 재검증할 수 있게 만드는 것이 목표이다.1.기존 RAG와 같이 인용 붙이기문서 기반 RAG는 ..
이번 편은 시리즈의 기술적인 내용이 많이 나오는데 본론(제약이 검색을 보조하는 구조)에 들어가기 전에 짚고 넘어가야 할 게 있다. OWL, SHACL, SWRL이 각각 뭐고, 서로 뭐가 다를까?공부를 해도 개념만 보면 헷갈린다... 이게 쿼리 언어인가? 어떤 툴의 기능인가? 설정 파일인가? 감을 잡기 어렵다..그리고 개인적으로도 OWL에서 domain/range를 선언하는 것과 SHACL이 하는 게 어떤 차이일까? 나도 이걸 명확하게 설명하려고 하니 한 번 정리가 필요했다.1.LPG와 OWL의 차이앞 편들에서 "LPG는 스키마 제약이 없다"고 계속 말해왔는데, 정확히 하면 LPG에 스키마가 아예 없는 건 아니다. 있긴하지만 성격이 다르다. Neo4j 기준으로 LPG의 스키마 관리는 세 겹으로 나뉜다.① ..
AI 기반 챗봇의 보편화로 사용자는 자연어로 묻는게 당연해졌다. 하지만 실제 뒤에서 데이터를 꺼내올때는 그래프는 SPARQL로 답한다. 그 사이를 LLM이 채우기 위해 text2SPARQL(LPG라면 text2Cypher)을 사용한다.다만, text2sparql은 생각보다 자주 틀리고, 문법이 틀리면 차라리 실행이 실패하니까 틀린 걸 알 수 있다.진짜 문제는 문법은 멀쩡한데 의미가 틀린 쿼리다. 실행되고, 결과도 나오고, 그 결과가 답변에 들어가기 때문에 검증이 어렵다.1. 어떻게 틀리는가직접 겪거나 관찰한 실패를 유형별로 나눠보면 대략 이렇다.존재하지 않는 속성을 지어낸다. 스키마에는 :worksIn뿐인데 :employedBy, :memberOf를 만들어 쓴다. 그래프에 그런 술어가 없으니 결과는 나..
온톨로지를 단순히 개념이 아니라 사용할 수 있게 하려면 지식그래프를 구축해야한다.다만, 그래프에 데이터를 어떻게 넣고, 어떻게 최신으로 유지할 것인가?GraphRAG의 답변 품질은 결국 그래프가 현실을 얼마나 반영하느냐에 묶여 있기 때문이다.어제 배치로 만든 그래프는 실시간이 아니기 때문에, 시간이 지나면 오답일 수 있다.예를 들어 인사 발령이 오늘 났는데 그래프가 지난주 상태라면, 아무리 SHACL 검증을 통과해도 틀린 답이 나간다. 내가 아는 한 이 문제에 대한 접근은 크게 세 가지로 생각했다.정답이 있는 게 아니라 각자 다른 선택지들이라 이번 글은 셋을 비교해보려 한다경로 1. 변환 후 적재 (ETL/ELT)가장 전통적이고, 지금도 대부분의 서비스가 쓰는 방식이다. 원천 데이터(RDB, CSV, A..
내가 온톨로지를 공부하던 시절에는 지금 같은 시대가 올 줄 몰랐다😅대학원에서는 AI보다는 온톨로지 표준을 만드는 일에 집중했고, 연구실에서 공동으로 TTA 데이터맵 표준 제정 작업에도 참여했다. 주로 공공데이터를 분석하고 데이터 카탈로그의 메타데이터를 다루는 일이었다. 그러다 LLM이 등장하고 건너건너 이런기업이 있다더라했던 팔란티어가 이렇게까지 뜰줄이야... 그러다보니 많은 분야에서 온톨로지를 말하는데, 해석하는 방식이 각자 다르다. 내가 생각하기에 팔란티어는 일종의 플랫폼이고 온톨로지 자체는 이론이자 표준 모델인데, 이 둘이 혼용되다보니 다들 다른 방식으로 생각하는 것을 같다. 특히 공공 분야에서는 "AI가 안 되는 걸 온톨로지를 쓰면 해결된다"거나, 표준도 스키마도 없이 추론으로 환각을 줄여달라는..
논문 요약: SPARQL-LLM경량 메타데이터(질의 예시 + 스키마)를 활용해 자연어 질문을 실시간·저비용으로 정확한 SPARQL 질의로 변환하는, 오픈소스 및 트리플스토어 독립적 시스템 https://arxiv.org/abs/2512.14277 SPARQL-LLM: Real-Time SPARQL Query Generation from Natural Language QuestionsThe advent of large language models is contributing to the emergence of novel approaches that promise to better tackle the challenge of generating structured queries, such as SPARQL q..
서론: 인공지능 추론 아키텍처의 패러다임 전환최근 대규모 언어 모델(LLM, Large Language Models)은 단순한 텍스트 생성을 넘어, 고도의 논리적 추론과 도메인 특화 지식 처리가 요구되는 복잡한 작업(Task)에 투입되고 있다. 초기 LLM의 한계인 환각 현상(Hallucination)과 지식의 정적 성질을 극복하기 위해 외부 지식 베이스를 활용하는 검색 증강 생성(RAG, Retrieval-Augmented Generation) 기법이 도입되었다. 그러나 전통적인 벡터 기반 RAG는 문서의 의미론적 조각(Chunk)을 독립적으로 검색하기 때문에, 문서 전체를 아우르는 전역적 맥락(Global Context)의 이해나 엔티티 간의 복잡한 관계망을 추적해야 하는 다중 홉 추론(Multi-h..
- Total
- Today
- Yesterday
- rdflib
- palantir
- 온톨로지
- RDF
- LLM
- Postgis
- knowlegegraph
- docker
- graphrag
- polars
- text2sparql
- knowledgegraph
- ChatGPT
- python
- SPARQL
- Kafka
- 지식그래프
- PostgreSQL
- Claude
- vscode
- vectorsearch
- 키워드추출
- MongoDB
- ontology
- LPG
- PEFT
- Vue3
- TextRank
- pandas
- AWS
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |