LLM

비용과 보안 때문에 직접 작은 모델을 만들어보기로 했다 – 『원하는 대로 튜닝하는 나만의 sLLM』

작성자:
원하는 대로 튜닝하는 나만의 sLLM 책 표지

상용 LLM API의 비용과 금융권 보안을 고민하던 핀테크 AI 개발자가 직접 작은 모델을 만들어보기로 했다. LoRA·QLoRA부터 양자화, RAG, FastAPI 배포까지 하반기 앱 챗봇 개발을 위해 읽은 실전 입문서.

같은 뉴스가 30번 들어올 때, 효과적인 중복 제거 3단계

작성자:

외부 뉴스 소스 수십 개를 수집하는 파이프라인을 만들면서 수집보다 더 골치 아픈 문제가 따로 있었다. 같은 사건이 매체마다 제목만 살짝 바꿔서 들어온다. 연준이 금리를 올리면 그 한 사건이 30개 매체에서 30개의 제목으로 쏟아진다. “연준, 기준금리 0.25%p 인상”, “Fed 25bp 금리 인상 단행”, “미 연준 금리 또 올렸다”… 사람 눈엔 같은 사건이지만 문자열로는 전부 다르다. 이걸 … 더 읽기

수백 건의 뉴스를 LLM 코멘터리 한 편으로 – 출력 강제와 실패 기록

작성자:

외부 뉴스 소스 수십 개를 수집하는 파이프라인을 만들었다. 수집하고, 중복을 거르고, 죽은 소스를 끊어내고 나면 매일 깨끗한 뉴스 데이터가 출력되고 쌓인다. 그런데 거기서 한 가지 문제가 남았다. 데이터만 쌓아두면 아무도 안 읽는다. VSI 경보 몇 건, 과열 섹터 몇 개, 헤드라인 수백 줄. 이걸 표로 던져주면 그건 리포트가 아니라 로그 덤프다. 매일 아침 “그래서 오늘 … 더 읽기

못 미더운 외부 소스를 가두는 법 2가지 – 서킷브레이커와 소스 health 관측

작성자:

외부 뉴스 소스 수십 개를 수집하는 파이프라인을 만든 적이 있다. RSS, YouTube, 공시, 검색 API 같은 외부 소스에서 뉴스를 긁어모으는 구조였다. 여기서 가장 빨리 배운 건 알고리즘이 아니었다. 외부 소스는 반드시, 그리고 제멋대로 실패한다는 사실이었다. 어떤 RSS는 어제까지 멀쩡하다 오늘 502를 뱉고 어떤 피드는 형식이 깨진 채로 응답한다. 문제는 소스 하나의 실패가 파이프라인 전체를 끌어내린다는 … 더 읽기

Agent를 관측하는 3가지 도구 살펴보기 ft. LLM Token

작성자:

– Tool 권한 설계 시리즈, 마지막 편 지난 글에서 Agent에게 Tool을 어떻게 제한적으로 열어줬는지를 정리했다. 그 글 마지막에 이렇게 썼다. “다음 글에서는 이렇게 설계한 멀티 에이전트 시스템을 실제로 운영하면서 겪은 모니터링과 디버깅 이야기를 정리해보려 한다.” 이번 글이 그 이야기다. 처음부터 모니터링을 제대로 짜둔 건 아니었다. 어느 날 token 사용량이 급격히 줄어든 걸 보고 나서야 깨달았다. … 더 읽기

Orchestrator는 Agent가 아니다

작성자:

멀티 에이전트에서 ‘통제자’의 역할을 분리하며 배운 것들 Orchestrator(오케스트레이터)는 원래 ‘지휘자’라는 뜻이다. 소프트웨어에서는 여러 구성 요소를 정해진 순서와 조건에 따라 호출하고, 결과를 보고 다음 단계로 넘길지 멈출지를 결정하는 통제 코드를 가리킨다. 쿠버네티스나 워크플로 엔진에서 말하는 ‘오케스트레이션’도 같은 말이다. 멀티 에이전트에서는 각 Agent가 판단을 맡고, Orchestrator가 결정을 맡는다. 이 글은 그 결정을 LLM이 아니라 코드에 맡겨야 한다고 … 더 읽기

에이전트는 생각보다 ‘대화’가 어렵다

작성자:

— 멀티 에이전트에서 State와 메시지 버스로 상태를 관리하며 겪은 혼란 멀티 에이전트를 설계하기 시작하면자연스럽게 이런 생각이 든다. “각자 역할을 나눠서 서로 이야기하게 하면 되지 않을까?” 사람 팀처럼 말이다. 내가 만들던 멀티 에이전트 구조도 그랬다.Planner가 계획을 세우고,Executor가 코드를 실행하고,Reviewer가 결과를 검토한다. 겉으로 보면 꽤 그럴듯한 협업 구조다.단일 Agent보다 더 똑똑해 보이기도 하고실제로 역할 분담도 명확해 보였다. … 더 읽기

Agent 설계에서 LLM에게 맡기면 안 되는 판단 3가지

작성자:

LLM은 “판단하는 도구”이지,시스템의 규칙과 책임까지 대신 설계해주지는 않는다. LangChain으로 Agent를 설계하다 보면 어느 순간부터 이런 프롬프트를 쓰고 있는 나를 발견하게 된다 “적절히 판단해서 처리해줘” “상황에 맞게 알아서 결정해줘” 이게 나만의 문제는 아니라고 생각한다 LLM은 너무 똑똑해보이고 실제로 웬만한 질문에는 그럴듯한답을 내놓기 때문이다. 특히 멀티 에이전트 구조를 만들 때는 더 그렇다 각 에이전트가 역할을 나눠서 추론하고, … 더 읽기