학 습 목 표
- 온톨로지 조회를 에이전트 도구 4종으로 포장한다.
- 계획–실행–합성 루프와 추적 로그를 구현한다.
- 근거 부착 답변으로 판정 기준 4를 완성한다.
에이전트와 도구 — 함수 호출의 구조
에이전트란 목표를 받아 스스로 행동을 고르는 체계이고, LLM 에이전트의 행동 목록이 곧 도구(tool)다. 각 도구는 이름·설명·입력 형식을 가진 함수이고, LLM은 도구 설명을 읽고 무엇을 언제 부를지 결정한다 — 함수 호출(function calling)이라 불리는 구조다. 온톨로지를 에이전트에 연결한다는 것은 결국 조회 능력을 도구 명세로 포장하는 일이다. psymap에서는 네 개면 된다: define(정의·출처), tasks_for(측정 과제), components(구성 요소), ca_link(공용 좌표). 각 도구의 몸통은 5-7과 6-7에서 이미 만든 SPARQL이다 — 새 지식이 아니라 새 포장이다.
# agent_tools.py — 도구 하나의 전형 def tool_tasks_for(term): "구성개념을 측정하는 과제 목록" # ← LLM이 읽는 도구 설명 iri = LEX.get(term) # 용어 연결(6-7 재사용) rows = g.query(...) # measures 질의(5-7 재사용) return {"과제": sorted(...)} # 구조화된 반환 TOOLS = {"define": ..., "tasks_for": ..., "components": ..., "ca_link": ...}
도구의 뼈대. 반환이 자연어 문장이 아니라 구조화된 값이라는 점이 요체다 — 합성 단계가 무엇이 근거인지 추적할 수 있다. 계획기는 이번에도 규칙 기반 축소 구현이고, 실전에서는 LLM이 도구 설명만 보고 이 결정을 내린다.
실행 — 추적 로그가 있는 답
$ python3 agent_tools.py 질문: 작업기억이 무엇이고, 어떻게 측정하는가? [1] 호출 define(작업기억) → {"정의": "진행 중인 인지 과제를 위해 정보를 일시적으로 유지하고 조작하는 능력.", "출처": "Baddeley, A. D. & Hitch, G. (1974). Work…"} [2] 호출 tasks_for(작업기억) → {"과제": ["N백 과제", "숫자폭 과제"]} [3] 호출 ca_link(작업기억) → {"CA": "trm_4a3fd79d0b5a7"} 답(근거 부착): 작업기억은(는) 진행 중인 인지 과제를 위해 정보를 일시적으로 유지하고 조작하는 능력.. 대표 측정 과제는 N백 과제, 숫자폭 과제이다. 공용 좌표는 Cognitive Atlas trm_4a3fd79d0b5a7 [출처: Baddeley, A. D. & Hitch…]
실제 실행 출력. 답의 모든 조각이 어느 호출에서 왔는지 로그가 증언한다. 합성문의 어색함 — "작업기억은(는)", 겹친 마침표 — 은 일부러 남겼다: 규칙 기반 합성기의 몫이 어디까지이고 LLM이 맡으면 무엇이 매끄러워지는지를 그 흠이 정확히 보여 준다.
판독 — 네 기대의 완성
이 작은 루프에 1-1의 네 기대가 모두 들어 있다. 근거 있는 답 — 정의에 출처가, 좌표에 CA ID가 붙어 나온다(위 출력이 그 실물이다). 공통 어휘 — 용어 연결이 '작동기억'도 같은 도구로 보낸다. 보장된 추론 — tasks_for의 답은 유사도 추정이 아니라 공리의 귀결이고, 5-7의 검증이 그 뒤를 받친다. 행동의 경계 — 에이전트가 할 수 있는 일은 도구 네 개가 전부이고, 온톨로지에 없는 용어 앞에서는 "도구 없이는 답하지 않는다"가 출력된다. 6-4에서 본 기업 에이전트(온톨로지 객체를 보고 허용된 액션만 실행)와 구조가 같다 — 규모와 액션 유무만 다를 뿐이다. 이로써 판정 기준 4 — 온톨로지를 RAG와 에이전트의 도구로 연결하고 답변 차이를 시연한다 — 가 달성되었다.
| 축소 구현(이 차시) | 실전 대체물 | 달라지는 것 |
|---|---|---|
| 규칙 기반 계획기 | LLM + 함수 호출 | 표현 다양성 흡수, 다단계 계획 |
| 문자열 조립 합성기 | LLM 생성(도구 결과만 재료로) | 자연스러운 문장 — 단, "도구 결과 밖은 말하지 말라" 지시 필수 |
| 도구 4종 | CQ 전체의 도구화 + 검색 도구 | 커버리지 — CQ 목록이 도구 목록의 설계도 |
| 추적 로그 print | 구조화된 감사 로그 | 사후 검증·디버깅 |
표 1축소 구현과 실전의 대응. 어느 칸을 바꾸든 불변인 것 — 도구 반환이 근거의 단위라는 것, 그리고 도구함의 설계도가 CQ(3-2)라는 것.
판별 연습
문 1합성기를 LLM로 바꿨더니, 답에 "작업기억 훈련으로 용량을 늘릴 수 있다"는 문장이 섞여 나왔다. 어디가 뚫렸고 어떻게 막는가.
답 확인
도구 결과에 없는 내용이므로 합성 단계에서 파라미터 지식이 샌 것이다 — 도구는 접지를 보장하지만, 합성기가 재료 밖을 말하면 보장이 깨진다. 방어: 프롬프트에 "도구 반환에 있는 내용만 쓰라, 각 문장에 근거 호출 번호를 달라"를 명시하고, 후처리로 각 문장을 도구 반환과 대조(인용 검증)한다. 추적 로그가 있어야 이 대조가 가능하다 — 로그는 장식이 아니라 방어선이다.
문 2도구를 CQ에서 끌어내는 이유를, "조회 함수를 그냥 많이 만들면 된다"는 입장과 대비해 설명하라.
답 확인
도구가 많아질수록 LLM의 선택 오류(엉뚱한 도구 호출)도 는다 — 도구함에도 공리 예산(2-5)의 논리가 적용된다. CQ는 "이 온톨로지가 답하기로 약속한 질문"의 목록이므로(3-2), CQ에서 도출된 도구는 존재 이유와 테스트(골드스탠더드)를 함께 갖고 태어난다. 쓰임이 증명되지 않은 도구를 미리 만들지 않는 것 — 요구 명세에서 출발하는 설계가 도구함에서도 반복된다.
적용: 산출물과 파일
실행 스크립트 전문은 agent_tools.py에서 열어 볼 수 있다. 이로써 실습 3종이 끝났다 — 같은 psymap.owl이 검색의 재료(6-6), 번역의 스키마(6-7), 에이전트의 도구함(6-8)으로 세 번 다르게 쓰였다. 자신의 도메인으로 실습 중인 독자는 자기 CQ 10문을 도구 명세로 바꾸는 것으로 이 차시를 재연할 수 있다. 남은 것은 하나 — 처음에 적어 둔 판정 기준으로 전체를 점검하는 일이다.
용어 정리
| 용어 | 원어 | 뜻 |
|---|---|---|
| 에이전트 | agent | 목표를 받아 도구 호출을 스스로 계획·실행하는 체계 |
| 함수 호출 | function calling | LLM이 도구 설명을 읽고 구조화된 호출을 생성하는 방식 |
| 추적 로그 | trace log | 어느 호출이 어느 근거를 가져왔는지의 기록. 인용 검증의 토대 |
| 근거 부착 답변 | evidence-attached answer | 모든 조각에 출처·호출이 달린 답 — 네 기대 중 첫째의 실물 |
실습 파일: agent_tools.py(본 사이트 수록 — 출력은 전부 실제 실행 결과). · Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR — 계획–실행 루프의 원형. · Luo, L. et al. (2024). Reasoning on Graphs(RoG) 계열 연구.