TIL

LangChain을 쓰는 이유!사용 방법은 통일.모델만 다르게 불러오면 다른 코드를 바꾸지 않아도 됨.HumanMessage -> 사용자가 하는 질문, 요청SystemMessage -> 모델의 역할을 정함. 너는 @@이야.ChatPromptTemplate.from_me

LangChain 에이전트·툴: create_agent 기반 Agent·Tool 구성, RAG 파이프라인·Tool Calling·MCP(Model Context Protocol) 서버 연동·Text-to-SQL 연계 실습model.with_structured_outpu

ReAct생각(Reasoning): 뭘할지 말로 정리\-> 행동(Acting): 도구 고르고 입력을 줌\-> 관찰(Observation): 도구가 돌려준 결과를 받음ㄴ 답이 나올 때까지 반복!Hit@K: 상위 K개 안에 정답이 하나라도 있나 (있으면 1, 없으면 0)P

(1) MCP 서버를 연결하는 방법을 공식문서로 알기(2) 서버를 열어서 도구 목록을 전체 가져온다(3) 필요한 도구를 agent에 등록한다(4) 시스템 프롬프트를 등록된 도구와 agent 목적에 맞춰 설계한다Codex \- MCP (도구) \- 스킬 (어떤 기능을

요청 -> before_agent(한번만) -> agent 루프 -> after_agent(한번만) -> 최종 답변ㄴ before랑 after가 앞뒤, 중간을(?) wrap이 감쌈agent 루프ㄴbefore_modelㄴwrap_model_callㄴafter_modelㄴ

열 때: uv run streamlit run 파일명종료할 때: ctrl+c => 종료 꼭 해줘야됨st.write : 만능 출력st : 재실행모델, 위젯 조작 -> 스크립트 전체 재실행pandas 코드랑 st코드랑 다 같이 쓸 수 있음dataframe -> 인터랙티브t

그래프 : 노드와 관계로 이루어진 자료구조LPG (Neo4j, Cyper) : 빠르게 특화된 , 기업 문건속성 -> 한번만 필요할 때노드 -> 자주 필요한 카테고리RDF (wikidata, SPARQL) : 기관간 , 공개 지식주어, 술어, 목적어?변수 wdt: wd:

기본 문법 한줄MATCH (변수명: 출발 노드) -: 관계-> (변수명; 도착 노드) AS 별칭RETURN 변수명.필요한값추가 \- 변수명 다시 쓸 일 없으면 작성 x \- 화살 방향 의미있음. 방향 상관없으면 화살촉 빼기 \- WHERE ; 조건 \- ORDE

(m1:Member), (m2:Member)→ 서로 다른 노드는 변수명을 다르게 써야 한다.MATCH (m:Member), (c:Class)→ 서로 다른 두 노드를 찾을 때는 각각 ()로 감싼다.(m)-:ATTENDS->(c)-:TAUGHT_BY->(t)→ 관계가 두

. : 아무 문자 1개\* : 앞의 것이 0번 이상.\* : 아무 문자가 0개 이상\+ : 앞의 것이 1번 이상^ : 시작$ : 끝\[] : 이 중 한 글자| : 또는(a)-\[:REL\*1..3]->(b)→ 관계를 최소 1홉~최대 3홉까지 따라가며 탐색한다.MATCH

WITH s, sum(p.cnt) AS 곡재생→ s별로 집계하고 다음 단계에는 s, 곡재생만 전달한다.WITH other, 공유청취자수, count(DISTINCT x) AS 전체청취자수→ 이전에 만든 변수도 다음 단계에서 쓰려면 WITH에 다시 적어야 한다.WITH

LOAD CSV WITH HEADERS FROM $path AS row→ CSV 한 행을 row로 받아 컬럼명으로 값에 접근한다.row'역명'→ CSV의 실제 '역명' 값을 가져오며 괄호·공백 등이 있는 컬럼명도 \[] 방식으로 안전하게 접근한다.CALL apoc.lo

CALL gds.graph.project('graphName', \['Label'], \['REL'])→ Neo4j 원본 그래프에서 분석할 노드·관계를 골라 GDS 메모리 그래프로 투영한다.CALL gds.graph.drop('graphName')→ GDS 메모리에 만

교안 01커뮤니티 탐지 (군집화 알고리즘)\-> 서로 많이 연결된 집단끼리 묶어준다\-> 집단 내에서 연결이 많고, 집단끼리 연결이 적다(관계의 가중치를 넣어 줄 수 있었음 : 값이 클수록 서로 연결이 강함)커뮤니티가 잘 이루어졌는지 확인하는 지표(1) 모듈리티(2)

Document 준비Document 노드에 title, text 같은 원본 텍스트가 존재 → "검색할 문서를 먼저 준비"문서 임베딩title + text → embed_texts()→ 텍스트의 의미를 숫자 벡터로 변환 → 논문마다 하나의 벡터 생성벡터를 노드에 저장Do

IE 4단계NERㄴ 학습형 모델의 표기는 BIO 태깅BIO 태깅: B-, I-, O로 개체의 시작/내부/비개체를 표시하는 방식일반 NER 모델 => 유형이 고정됨규칙 기반 NER => 표준 사전 매칭. 미등록어,경계,대소문자,약어충돌 문제머신러닝 기반 NER => 사전

자연어 → 트리플ㄴ 사실을 (주어, 관계, 목적어)로 구조화ㄴ 트리플 → 그래프의 노드-관계-노드로 연결온톨로지 설계ㄴ 어떤 노드 타입과 관계를 사용할지 결정ㄴ 관계 시그니처 정의 (주어 타입, 목적어 타입, 판정 기준)ㄴ 노드의 키는 이름이 아니라 id온톨로지에서

스키마 준수율=> 낮으면 LLM 출력 제약 보완근거 원문 일치율 -> 인용문을 검사=> 낮으면 LLM의 인용 방식과 출처 연결 보완샘플 정밀도골드셋 (있어야 할 관계의 목록)정밀도, 재현율, F1정밀도 (precision) : TP / (TP + FP)재현율 (reca

엔티티 정규화 (ER) : 개체의 이름이 달라도 실제로 같은 개체인지 판별해서 하나로 통합하는 과정ER을 위한 절차(1) 중복 개체의 후보를 추출 (블로킹)문자 자체의 유사도, 임베딩 기반으로 의미 유사도, 노드 연결 유사도 (자카드)(2) 개체간의 실제 동일한지 판정

원문과 추출할 관계 정하기어떤 텍스트에서 무엇을 추출할지 결정허용할 노드(Entity) 타입과 관계(Relation) 타입 정의시작 노드 → 관계 → 도착 노드의 허용 방향을 정해서 Schema 구성원문 청킹, 벡터 확인KG Builder로 그래프 생성LLM이 지켜야

새로운 문서 -> 청킹 -> 스키마 정의 -> LLM 새로운 트리플 추출 -> 추출 결과 검증 (허용된 노드 유형/ 관계? S,R,O 조합? 근거 유무/원문존재?)(1) 새롭게 추출한 트리플의 노드들에 기존에 저장된 표준 ID 부여표준 ID가 없는 새로운 노드 -->

교안 01 저장된 관계 조회 Cypher → KG에 저장된 관계 직접 조회 홉을 이용해 연결 관계 탐색 LLM Text2Cypher 에이전트 → 자연어 질문을 Cypher로 변환 → KG 관계 검색 => 구조화된 그래프 관계 검색 벡터 검색 에이전트 →

Naive RAG (기본 RAG) → 개선 ⇒ Advanced RAG청킹 전략Fixed : 문자 수Recursive : 길이 제한 + 구분자 (길이 제한 안에서 경계 우선)Semantic : 의미 변화백분위를 높이면 더 의미가 관련이 없어야 짤리니까 청크가 줄어든다백분

Hybrid Search (하이브리드 검색)같은 질문 → BM25 ⇒ 어휘 검색 순위 ⇒ 가중 RRF ⇒ 최종 상위 K개→ Dense ⇒ 의미 검색 순위 ⇒ 가중 RRF ⇒ 최종 상위 K개가중 RRF : 등수의 기여를 합침IDF : 등장 문서 수, 희귀도 가중치TF

BM25 + Dense 검색기 → 각각 추출 → 중복 제거한 후보 ⇒ 리랭킹 ⇒ 최종 top_n개질문과 문서 비교Bi-Encoder : 질문과 문서 따로 벡터 ⇒ 유사도 비교 (Dense)Cross-Encoder : 질문과 후보 문서 한 쌍 → 모델 ⇒ 관련성 점수Co

01VectorRetriever : 의미 기반 검색질문 임베딩질문과 유사한 청크 검색같은 영화의 중복 청크 제거 → 기준 영화 후보VectorCypherRetriever : 의미 검색 + 그래프 관계 확장질문 벡터 → 진입 청크 찾기청크 → 원문 → 기준 영화기준 영화

State 정의TypedDict 으로 설계: 비교적 가볍고 에러가 날 확률이 적음전체 필드 선언초기 상태 선언담을 정보는 담고, 채울 정보는 비워둠Node 생성LLM이 반환할 분류 결과의 형식분류 기준과 입력 질문분류 결과분류 노드답변 프롬프트답변 노드노드는 함수로 생

: 작성 → 검토 → 수정 → 검토State 정의Node 생성Edge 연결문서 검토 통과종료미통과 & 검토 횟수 남음수정미통과 & 검토 상환 도달종료 (사람이 확인)State 정의prompt → MessagesPlaceholder 넣기Node 생성Edge 연결check

Store의 장기 기억 VS 체크포인터 (thread_id기준) - 대화세션Store의 장기 기억 : 사용자 ID별 사용자 맞춤 장기 기억 저장소 (대화내용XXX)Store : 장기기억 저장소Store 기본 구조namespace : 기억을 모아두는 공간문자열 튜플(”용