하루 9건씩 오던 스팸 댓글이 0건이 됐다 – 워드프레스 유료 플러그인 없이 막은 4겹 방어
Akismet은 유료였고 스팸은 손으로 지운 것만 292건이었다. 허니팟·서명 토큰·내용 규칙·Cloudflare로 DB에 저장되기 전에 거부하도록 만들고, 16일 뒤 실제로 몇 건이 들어왔는지 다시 세어본 기록.
AI
비용과 보안 때문에 직접 작은 모델을 만들어보기로 했다 – 『원하는 대로 튜닝하는 나만의 sLLM』
상용 LLM API의 비용과 금융권 보안을 고민하던 핀테크 AI 개발자가 직접 작은 모델을 만들어보기로 했다. LoRA·QLoRA부터 양자화, RAG, FastAPI 배포까지 하반기 앱 챗봇 개발을 위해 읽은 실전 입문서.
AI 개발자에게 멀티모달의 문턱을 낮춰주는 책 – “허깅페이스로 배우는 멀티모달 모델”
— 이론에서 실습까지, 허깅페이스의 a to z를 따라가다 보면 멀티모달이 더 이상 무겁지 않다
Orchestrator는 Agent가 아니다
멀티 에이전트에서 ‘통제자’의 역할을 분리하며 배운 것들 Orchestrator(오케스트레이터)는 원래 ‘지휘자’라는 뜻이다. 소프트웨어에서는 여러 구성 요소를 정해진 순서와 조건에 따라 호출하고, 결과를 보고 다음 단계로 넘길지 멈출지를 결정하는 통제 코드를 가리킨다. 쿠버네티스나 워크플로 엔진에서 말하는 ‘오케스트레이션’도 같은 말이다. 멀티 에이전트에서는 각 Agent가 판단을 맡고, Orchestrator가 결정을 맡는다. 이 글은 그 결정을 LLM이 아니라 코드에 맡겨야 한다고 … 더 읽기
Agent 설계에서 LLM에게 맡기면 안 되는 판단 3가지
LLM은 “판단하는 도구”이지,시스템의 규칙과 책임까지 대신 설계해주지는 않는다. LangChain으로 Agent를 설계하다 보면 어느 순간부터 이런 프롬프트를 쓰고 있는 나를 발견하게 된다 “적절히 판단해서 처리해줘” “상황에 맞게 알아서 결정해줘” 이게 나만의 문제는 아니라고 생각한다 LLM은 너무 똑똑해보이고 실제로 웬만한 질문에는 그럴듯한답을 내놓기 때문이다. 특히 멀티 에이전트 구조를 만들 때는 더 그렇다 각 에이전트가 역할을 나눠서 추론하고, … 더 읽기