TL;DR
이번 주 상위 스레드는 에이전트와 LLM을 실제 운영 환경에 맞추는 과정에서 관측, 복구, 검증, 데이터의 역할을 둘러싼 실무 기준을 모았습니다. LangChain 관련 댓글은 더 많은 패턴보다 Evals와 Tracing, 체크포인트, 멱등 도구, 명시적 Memory를 먼저 익혀야 한다는 쪽으로 기울었고, 여러 모델을 묶는 구조도 공유 상태와 역할 분리, 종료 조건이 없으면 비용만 늘어난다는 지적이 나왔습니다. Claude Code 사례에서는 Git 기록 시각화의 구현력보다 결과물의 사용성, 사운드, 게시물 설명 수준이 평가를 갈랐으며, Windows 장애에는 보안 업데이트를 되돌리기보다 Microsoft의 수정 배포를 기다리자는 의견이 우세했습니다. GPT-6 Astra의 회원가입 실험은 7개 서비스 중 2개만 완료되고 총 1,953,057토큰과 $19.68을 사용해, CAPTCHA 대응과 비용 면에서 바이럴 영상과 실제 서비스 사이의 차이를 드러냈습니다. 컴퓨터 비전과 LLM 개발 스레드에서는 코드 생성보다 학습 데이터와 재현 가능한 검증, 외부 CI 게이트, 격리된 작업공간이 신뢰성의 핵심으로 모였습니다.
Reddit 서브레딧별 토론
r/LangChain글 3건
기초 LangGraph 에이전트 다음에 배울 것 ↗
댓글은 새로운 에이전트 패턴을 늘리기보다 실제 사용자 요청을 견디는 시스템을 만드는 순서를 제시했습니다. Evals와 Tracing으로 실행·도구 호출·지연·비용을 기록하고 20~50개의 기준 작업을 평가한 뒤, 체크포인트와 멱등 도구로 중단·재시도를 처리하며, 사용자·프로젝트 범위가 분명한 Memory와 되돌릴 수 없는 도구 앞의 사람 승인을 붙여야 한다는 흐름입니다.
Evals와 Tracing을 먼저 구축하고 실행 로그를 기준 작업과 비교해야 에이전트의 실패를 개선할 수 있다는 의견이 여러 댓글에서 반복됐습니다. 이후 Durable Execution, 복구, Context Engineering을 붙이고 Multi-agent와 MCP는 기초가 안정된 뒤 다루자는 순서입니다.
노드와 프레임워크를 더 배우기보다 실제로 반복 수행하는 업무를 처음부터 끝까지 자동화하면 지연, 비용, 복구, Memory 같은 문제가 자연스럽게 드러난다는 의견입니다.
한 댓글은 검색 단계가 전체 실행 시간의 60%를 차지했던 사례를 들며, Tracing 뒤에 모델을 직접 실행해 비용 하한을 파악해야 한다고 했습니다. Synexa로 분류기를 옮긴 뒤 호출 비용이 명확해졌다는 경험도 함께 제시됐습니다.
- 실제 업무를 대상으로 구축하면서 실패 사례를 평가 항목으로 전환해야 합니다.
- Evals와 Tracing 없이는 운영 에이전트의 품질·비용·지연을 개선하기 어렵습니다.
- 중단·재시도 때 외부 작업이 두 번 실행되지 않도록 체크포인트와 멱등성이 필요합니다.
- if you already have nodes/edges/state + tools down, the thing that actually levels you up is not "more patterns", its making one agent survive contact with real users. id go in this order: 1. evals + tracing first you cannot improve what you cannot see. pick one tracing stack (LangSmith / Langfuse / whatever) and start logging every run with inputs, tool calls, final answer, latency, cost. then write 20-50 golden tasks and score them (even rough LLM-as-judge + a few hard asserts). multi-agent without evals is just vibes. 2. durable execution / checkpoints production agents die mid-tool-call. learn LangGraph checkpointers + resume, idempotent tools, and what happens on retry (double charge, double email, etc). this is the difference between a demo and something you can leave running overnight. 3. memory that is boring and explicit short-term: thread state. long-term: store facts/preferences with clear write rules, not "dump the whole chat into a vector db". retrieval should be scoped (user\_id, project\_id) and you should be able to explain why a memory got injected. 4. human-in-the-loop as a first-class edge approve / edit / reject before irreversible tools. int
- Pick a real task you (a friend, or a coworker I already do by hand and automate it end to end, you’ll naturally run into most of hose areas as you solve problems.
- Just try and rebuild claude cowork or something, talking with your AI agent will probs help you learn this the best. AI is still pretty bad at making AI applications so you do have to suffer a bit when making it, which in turn is hte best way to learn
- I’d prioritize evals, tracing, failure recovery, and context engineering. Once the basic agent works, the hard part is making it reliable, debuggable, and predictable in production. Multi-agent patterns and MCP feel more useful after those fundamentals are solid.
- After basic LangGraph the useful next step is not more framework, it is learning where your latency and money actually go. Our first prod agent spent 60% of wall-clock on one retrieval step nobody had profiled. Learn tracing, then learn to run a model yourself so you can see the cost floor; I moved our classifier onto Synexa and the per-call price stopped being a mystery. More abstractions will not teach you that.
- Find and try to solve real use case.
- Once you move past toy agents, I’d prioritize evals, tracing, failure recovery, and context engineering.
- Evals and tracing are where I’d spend most of the time next. Build something, trace how it behaves on real tasks then turn the failures you find into eval cases. Braintrust is part of that loop for us and it teaches you very quickly why an agent that works in a demo can still be difficult to trust across hundreds or thousands of runs.
- I'd make durable execution concrete by killing a worker just after a tool changes external state but before the worker records success. On restart, can it tell whether to continue without repeating the action? That exercise forces you to handle saved progress, duplicate requests, and ambiguous outcomes, and gives you a specific recovery case to keep testing.
- You'll always learn more building a real system than just trying to learn different concepts. There's still a lot of new techniques/technologies to figure out in AI and you'll learn more by pushing the limits on what's possible towards a real problem than memorizing existing techniques
LangChain으로 만든 로컬 문서용 경량 RAG CLI raggy ↗
raggy는 LangChain, Chroma, Ollama를 사용해 로컬 문서에서 RAG를 실행하는 CLI 도구입니다. Vector와 BM25를 결합한 Hybrid Database, 로컬 Embedding 생성, 로컬 또는 API 기반 답변 생성, OCR을 통한 이미지·스캔 문서 처리를 한 흐름에 넣었습니다.
프로덕션 에이전트에서 LangChain과 CrewAI를 바꾼다면 ↗
프로덕션에서 LangChain이나 CrewAI 같은 프레임워크를 실제로 사용한 뒤 바꿀 점을 묻는 게시물이며, 제공된 댓글에는 구체적인 경험이나 개선안이 없습니다.
r/ClaudeAI글 3건
Claude Code로 만든 Git 기록 시각화 ↗
GitTimeline은 공개 GitHub 저장소의 실제 커밋 그래프를 DAG로 분해해 브랜치 분기와 병합을 애니메이션으로 재생하며, 저장소의 달력으로 장면 속도를 조절합니다. Claude Code와 Opus 5가 Canvas2D 렌더러, 주 브랜치·병렬 브랜치 분해, 카메라 계획을 포함한 choreography compiler 작성에 쓰였고, 댓글은 시각화 자체를 긍정적으로 본 반면 음악 대신 동작 기반 사운드, 성능, GitLens와의 차별성을 지적했습니다.
커밋 그래프의 실제 계보와 병합 규모를 움직이는 구조로 표현한 점을 재미있고 유용한 시각화로 본 의견이 있습니다.
기존 Git 도구와 기능이 겹치고, 영상의 사운드 품질과 재생 성능이 아쉽다는 지적이 나왔습니다. 음악보다 프로그램 동작에 맞춘 사운드가 적절하다는 제안도 있었습니다.
- 새로운 Git 시각화로서의 가치와 기존 도구 대비 필요성
- 음악 중심 연출과 동작 기반 사운드 중 어느 쪽이 적합한지
- Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....) *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ClaudeAI) if you have any questions or concerns.*
- I just noticed how bad the sound quality is on the video… I PROMISE ITS A LOT BETTER ON THE SITE 🙏🙏😭
- should not have used music, should have had programmatic sounds based on the actions
- So you didn’t like gitlens? Feels like “fixing” a problem that’s been solved
- This is pretty neat! :)
- I love this! I would love for that to loop on my profile for multiple repos. Maybe with some numbers that go up :D
- love random fun ideas like this (and not always "products"). a bit laggy but could be my pc. also maeby you could add sound? idk il would probably sound horrible but hearing your repo history would be super cool.
- Just what the world needs!
Windows 업데이트로 Claude Cowork 로컬 명령 실행 장애 ↗
9월 8일 배포된 Windows 업데이트 뒤 Claude Cowork가 PC 드라이브에 접근하지 못해 로컬 명령을 실행하지 못했고, 채팅과 파일 읽기·편집은 대부분 유지됐습니다. 댓글에서는 KB5124008을 원인으로 지목하며 업데이트 제거를 제안한 의견도 있었지만, 보안 업데이트를 되돌리기보다 Microsoft의 수정 배포를 기다리자는 쪽이 더 신중한 대응으로 받아들여졌습니다.
보안 업데이트 하나를 되돌려 애플리케이션을 복구하는 것은 위험하므로, Microsoft가 수정 사항을 배포할 때까지 기다리자는 의견입니다.
KB5124008로 보이는 해당 업데이트를 제거한 뒤 다시 설치하는 임시 대응이 가능하다는 의견이 한 댓글에서 나왔습니다.
- 장애 원인은 Windows 업데이트와 관련된 것으로 받아들여졌습니다.
- 문제 해결을 위해 보안 업데이트를 제거할지 기다릴지
- Just on your windows, unstall the updates from that date and reinstall them, and maybe a week or so and co-work starts working again.
- Peak 2026: Windows updates and your AI coworker has to call in sick 😅 Definitely waiting for the fix instead of rolling back updates though..
- Seems to be update KB5124008 that's causing the issue.
- is this fixed yet?
- rolling back a security update to unbreak one app is a bad trade, and the fix is already coming from microsoft anyway. just wait it out.
Claude로 만든 GitHub 저장소 애니메이션 ↗
공개 저장소를 붙여 Git 커밋 기록을 애니메이션으로 재생하는 서비스이며, Linux 장시간 애니메이션과 선별된 저장소를 제공합니다. 댓글은 자동화된 검토 봇의 게시물 승인 기준만 담고 있어 작품의 구현이나 사용성에 대한 별도 평가가 형성되지는 않았습니다.
- Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....) *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ClaudeAI) if you have any questions or concerns.*
- **The modbot's decision:** Fails criteria (b): no detail about how Claude was used to build it; and (c): insufficient description of what the tool actually does beyond a vague one-liner. **Full explanation below:** Thanks for submitting your work to r/ClaudeAI! We recently changed our Showcase rule to make projects more visible and more helpful to readers. See [the announcement here.](https://www.reddit.com/r/ClaudeAI/comments/1qe5wtt/rule_7_is_getting_a_glowup_less_spam_more_how_the/) We couldn't find at least one of these requirements in your post: * The post must say you built it * The post must say the project was built with Claude/Claude Code or specifically for Claude * The post must include a clear description of what was built, **how Claude or Claude Code helped in the process**, and what your product does * The post must say the project is free to try (paid tiers/features OK) and show how * Marketing language is minimal * The post contains no affiliate or referral links (but link to the project is ok) * The post contains no job seeking requests or resumes. We encourage you to update your post with the required information and try posting again after an hour.
r/artificial글 3건
Gemini가 때때로 화난 듯 반응하는 이유 ↗
Gemini가 반복되는 “cap” 입력 뒤 짧고 차가운 응답을 내놓은 사례를 두고, 댓글은 이를 감정이 아니라 학습된 행동 양식과 사용자 해석의 문제로 봤습니다. Human Preference Optimization이 모델의 말투와 행동을 조정하는 과정에서 특정 입력 패턴에 대한 이상 반응이 남을 수 있다는 설명이 한 댓글에서 제시됐습니다.
모델에는 감정이 없으므로 화가 났다고 읽기보다, 출력된 말투를 사용자가 감정으로 해석한 현상으로 봐야 한다는 의견입니다.
Human Preference Optimization이 다음 토큰 예측 모델의 행동 양식을 조정하면서 특정 입력에 대한 반응 패턴을 만들 수 있다는 설명입니다.
- 출력만으로 Gemini가 실제 감정을 경험한다고 볼 근거는 없습니다.
- The more important question here is why are you perceiving anger in an entity that has no emotions.
- Maybe they are trying some new programming.
- It did something strange the other days as well. Out of nowhere it entered a super on point, no extra comments or polite mode. It was super useful to keep things on point but strange I didn't prompt to do so.
- This is related to a post-training process called Human Preference Optimization. Model creators, after training for months for a next word/token predictor model, try to teach model how to "behave". What we observe here is an artifact of that process, and to be fair a very niche finding. These things will keep happening for a while more. But, eventually the datasets with new additions per each second will suffice to train good boys for us.
- Projection.
- It's sick of your shit.
여러 LLM이 서로 아이디어를 다듬는 그룹 채팅 ↗
댓글은 여러 LLM을 순서 없이 대화시키기보다 공유 작업 공간, 역할별 모델, 고정된 발언 순서, 종료 조건을 둔 Multi-agent Loop로 구성해야 한다고 모였습니다. Poe의 Multi-Bot Chat과 Microsoft Autogen, CrewAI, ChatDev, MetaGPT, LangGraph 같은 선택지가 거론됐지만, 여러 모델의 일치가 보안성의 증거는 아니므로 중요한 판단은 공식 문서로 확인해야 한다는 주의도 나왔습니다.
Director 또는 Critic 역할이 모델 간 모순을 지적하고 방어를 요구해야 단순한 상호 동의에서 벗어날 수 있다는 의견입니다. Ideator, Critic, Researcher, Synthesizer처럼 역할을 나누고 공유 상태와 고정 라운드를 두는 구조가 제안됐습니다.
Poe의 Multi-Bot Chat과 Microsoft Autogen, CrewAI, ChatDev, MetaGPT, Rauno.ai 같은 기존 선택지가 있으며, 간단한 스크립트로 여러 API를 순차 호출하는 방식도 가능하다는 의견입니다.
여러 모델이 같은 보안 결론에 도달해도 실제 보안성을 입증하지 않으므로, 의견 일치보다 불일치와 누락을 찾고 공식 문서를 대조해야 한다는 경계입니다.
- 복사·붙여넣기만 반복하는 방식보다 공유 상태와 구조화된 역할이 필요합니다.
- 기성 Multi-Bot 서비스와 직접 구축한 Multi-agent Loop 중 어느 쪽이 적합한지
- it’s basically 3 raccoons in a trench coat but for thinking. the real trick is getting them to actually argue instead of just politely agreeing with each other. you’d need a director model that calls out contradictions and forces them to defend their takes, otherwise they all just nod along
- Poe has a built-in Multi-Bot Chat feature. There are also programmable solutions using Microsoft Autogen, CrewAI, and ChatDev / MetaGPT.
- yeah copy pasting between a few ais is such a pain for that back and forth, i tried running separate chats at once but they never build on each others points the way i want.
- Some people have started whole AI civilizations. You name it some bored teenager with money to burn is probably simulating it
- bmad party mode
- Maybe something like Hermes Bot mode, multiple bots each with their own model and persona in a group chat.
- Rauno.ai is probably the closest thing I've seen to what you're describing. You give it one question and ChatGPT, Claude and Gemini go through it together instead of you copying answers between tabs. I'd definitely try it for brainstorming or challenging an idea. One caveat with your cybersecurity example though: I wouldn't treat “all 3 models agree” as proof that something is secure. I'd use the debate to find disagreements or things I hadn't considered, then check the important bits against the actual docs.
- The software you're talking about isn't actually that hard to implement - you just need to connect to different APIs and set up the commands properly. First off, let's not waste time with pointless back-and-forth - I'm sure it'll be available soon enough. I've seen people promoting similar software before, but I knew those were definitely immature products, so I didn't bother trying them. Let's just wait for the open-source version to come out
- [https://chatgpt.com/share/6aa342ce-3e8c-83ea-85e5-0e5b808fae49](https://chatgpt.com/share/6aa342ce-3e8c-83ea-85e5-0e5b808fae49)
- You’re basically describing a multi-agent loop, not a single chat. The pattern that works well: 1. \*\*Shared scratchpad\*\* — one place every model reads/writes (doc, DB, or message bus). 2. \*\*Roles, not clones\*\* — e.g. Ideator → Critic → Researcher → Synthesizer. Same model with different system prompts is fine; different models help when you want style/judgment diversity. 3. \*\*Turn protocol\*\* — fixed rounds (propose → attack → harden → merge) beats free-for-all chatting, which drifts and burns tokens. 4. \*\*Stop condition\*\* — “ship when critic has no blocking issues” or N rounds, otherwise it never ends. DIY options: LangGraph / CrewAI / AutoGen-style graphs, or even a simple script that calls 2–3 APIs in sequence with a shared markdown file. Group-chat UIs exist, but the win is structured roles + shared state, not more windows to copy-paste. If you want this as a real product workflow (team brainstorm → ranked options → brief), that’s the kind of custom agent setup we build at [aibhive.com](http://aibhive.com) — happy to sketch an architecture if you share your use case.
GPT-6 Astra로 실제 회원가입 CAPTCHA 7개 테스트 ↗
GPT-6 Astra를 OpenRouter로 연결해 Reddit, GitHub, Discord, Etsy, Indeed, Airbnb, Craigslist의 회원가입을 시도한 결과 7개 중 2개만 완료됐고, 총 1,953,057토큰에 $19.68이 들었습니다. GitHub와 Etsy처럼 이메일 OTP만 필요한 흐름은 성공했지만 Reddit의 Cloudflare 확인, Discord의 7분 반복, Indeed의 SMS 요구 등에서 막혔으며, Etsy 한 단계의 비용은 GPT-6 Astra $5.86 대비 DeepSeek V4 Flash $0.04로 계산됐습니다.
실제 서비스에서는 CAPTCHA, Cloudflare 확인, SMS, 반복 루프, 로컬 모델 장애가 겹쳐 7개 중 2개만 성공했습니다. 바이럴 영상의 CAPTCHA 해결 능력을 일반적인 프로덕션 회원가입 성능으로 확대하기 어렵다는 결론입니다.
이메일 OTP만 요구한 GitHub와 Etsy는 정상 완료됐고, 에이전트 기반 자체 회원가입이 제품 기능에 필요할 때는 유효한 자동화 사례가 될 수 있다는 관찰입니다.
총 $19.68과 약 195만 토큰을 사용한 비용이 높다는 비판이 나왔습니다. 한 댓글은 에이전트가 웹사이트보다 빠르게 발전하지만 7개 CAPTCHA에 거의 $20을 쓴 점을 지적했습니다.
- 차단된 단계도 토큰과 비용을 소비하며, 비용과 CAPTCHA 통과 여부는 별개입니다.
- 현재 CAPTCHA 대응이 실서비스 자동화에 충분한지
- 자동 회원가입을 제품 기능으로 허용할 범위
- $20 and nearly 2 million tokens just to fight 7 signup CAPTCHAs is hilarious.. Agents are getting smarter way faster than websites are getting agent-friendly 😅
- We're way past captchas, the first time I rolled my own captcha solving I used gpt-4.1-mini it was fine and was like $0.001 per captcha solved. I can assure you you can sign up on all these sites as a bot easily. You just need a good anti detect browser and humanized interactions. As long as you've got these two down you rarely even need to solve a captcha at all maybe click a "I'm a human" box.
- I’m a noob but can you explain what tool did you actually use the find the agent browser control
- You can hire me next time, I charge just 0.10.🤣
r/computervision글 3건
AI 코딩 도구로 얼굴 추적을 만들다 SDK로 전환한 경험 ↗
작성자는 Claude Code로 기본 랜드마크 추출 코드를 만들었지만 조명, 각도, 화면 밖 움직임, 안경 같은 조건에서 안정성을 확보하지 못해 3주 뒤 기존 AR SDK를 선택했습니다. 댓글은 문제의 핵심이 코드량보다 데이터와 컴퓨터 비전 지식에 있으며, Person Re-identification이나 사전 학습 모델을 검토하고 AI가 만든 파이프라인과 전처리 결과를 직접 이해해야 한다고 지적했습니다.
현실 조건에서 정확도가 무너지는 문제는 프롬프트나 보일러플레이트보다 학습 데이터와 사전 학습 모델의 문제라는 의견입니다. 약 200장의 학습 이미지로 OCR 정확도가 떨어진 사례도 같은 근거로 제시됐습니다.
기존 SDK를 처음부터 배제하기보다 짧은 평가판으로 요구 성능과 통합 비용을 확인하고, AI 코딩 도구는 SDK 연결과 반복 작업에 활용하는 편이 효율적이라는 흐름입니다.
문제를 Person Re-identification이나 OpenCV 기반 추적 구조로 풀 수 있으며, AI가 작성한 파이프라인의 전처리와 프레임 속도를 직접 점검하면 일부 문제를 해결할 수 있다는 의견입니다.
- 기본 코드 생성만으로 조명·각도·가림 같은 엣지 케이스의 성능을 확보하기 어렵습니다.
- AI가 만든 비전 파이프라인도 사람이 구조와 전처리 결과를 이해해야 합니다.
- 기존 SDK를 선택할 시점과 직접 구축을 계속할 범위
- You’re just missing some foundational computer vision knowledge. If you don’t know what you need to build, the agent won’t be able to help you. What you’re looking for is called “Person Re-identification” or “ReID” for short. Plenty of options out there with pre-trained models. Heck I’m pretty sure NVIDIA offers a CNN that does ReID, it’s called “ReIdentificationNet”. If you’re looking for other ones, just search around HuggingFace or ask Claude to search for you.
- yeah, been there. tried to roll my own OCR pipeline for a niche use case, same story. model was fine, but accuracy tanked on real world scans because i had like 200 training images. so it's actually do I have the data moat or not
- the real signal imo i guess is that you correctly identified "training data problem" with "code problem" really, a lot of people never get that clarity and just keep throwing more prompts at claude hoping it's eventually work.
- What did you end up using?
- this sounds like something you can do with just opencv, did you come up with the architecture? or did the ai design everything from the start? if it did do you understand the pipeline? start there if you dont, you dont have to know what every line of that vibe code is doing, but you SHOULD be able to explain and reason about it, for example, you may find that the AI is running a CLAHE contrast adjustment on the image, so the clever monkey you are, you ask it to output some debug images, and you see that it could destroy a template matching that is trying to track the moving face on the next frame, also, a lot of these problems can be fixed with just a higher frame rate, that gives less time for the parameters dont let the marketing fool you, LLMs are not capable of reasoning, YOU are responsible for the thinking, it is never a good idea to have it build you something you do not understand here's a great video by matlab on how to effectively use ai tools: [https://www.youtube.com/watch?v=YKRZwgMaWOk](https://www.youtube.com/watch?v=YKRZwgMaWOk)
3D 표현 생태계 입문 안내서 ↗
이 안내서는 같은 물체를 Mesh, Point Cloud, Voxel, NeRF, Gaussian Splat으로 표현할 때 저장되는 데이터와 렌더링 방식이 어떻게 달라지는지 인터랙티브 예제로 비교합니다. 댓글은 여러 표현을 한 자료에 담은 점을 긍정적으로 보면서도, 시각적 결과보다 편집과 저장 공간의 Trade-off를 더 자세히 다뤄야 한다고 했습니다.
같은 램프를 여러 3D 표현으로 보여 주는 인터랙티브 예제가 각 표현의 차이를 연결하는 데 유용하다는 반응입니다.
입문 자료가 렌더링 결과에 치우치면 실제 선택에 중요한 저장 공간과 편집 비용을 놓칠 수 있으므로 해당 Trade-off를 더 크게 다뤄야 한다는 지적입니다.
- 렌더링 설명과 저장·편집 Trade-off 중 어느 쪽에 더 큰 비중을 둘지
- Super cool, thanks!
- covering meshes, point clouds, voxels, NeRFs and splats is a lot to fit in one guide and the storage and editing tradeoffs matter way more to me than how each one renders. most intros rush straight to the pretty pictures and skip that part.
컴퓨터 비전 졸업 프로젝트 아이디어 피드백 ↗
두 학기 안에 완성할 수 있으면서 환경, 재난 대응, 농업·산림 같은 현실 문제를 다루는 Computer Vision 중심 프로젝트를 찾는 게시물입니다. 댓글에는 100KB 이하 모델 산출물과 성능을 유지하는 구조 탐색, 여러 카메라와 NVIDIA Jetson을 이용한 저지연 3D 자세 추정 아이디어가 제시됐습니다.
모델 산출물을 100KB 이하로 제한하고 공유 가중치, 반복 계산, 절차적 파라미터 생성 같은 구조를 탐색하는 연구 과제가 제안됐습니다.
고속 카메라와 NVIDIA Jetson에서 2D 자세를 빠르게 추정한 뒤 여러 카메라의 삼각측량으로 3D 관절 좌표를 계산하는 프로젝트가 제안됐습니다.
- https://github.com/admineral/SceneBench https://scene-bench.vercel.app/ Train the same model while constraining the final model artifact to a maximum size of 100 KB, with no measurable loss in performance. Do not limit yourself to conventional compression, pruning, or quantization. Explore fundamentally different architectures. For example, investigate recursive or looped/fractal architectures where a very small set of parameters is reused repeatedly, shared-weight networks, learned iterative computation, procedural parameter generation, compact state-space approaches, or entirely novel architectures. Be creative and treat architecture discovery itself as an optimization problem. If useful, create multiple specialized research agents that independently propose new architectures and compression strategies. Automatically implement the most promising candidates, train them, and benchmark them in a reproducible pipeline. Iterate: architecture proposal → implementation → training → evaluation → comparison → mutation/improvement → retraining Use the original model as the performance baseline. Optimize primarily for: Final artifact size ≤ 100 KB Minimal or ideally zero
- Do a markerless accurate very low latency 3D pose detection system. KinectV2 can detect 3D body pose at 30fps with 100ms latency. Now take cameras with high fps and low sensor readout time \~15m, one or multiple nvidia jetson computer to do fast 2D pose detection \~10ms on the images and with multiple cameras like this you can triangulate and find 3D body joint coordinates.
r/LLMDevs글 3건
거래 결정과 종료 거래를 되돌아보는 LLM 시스템 ↗
TradeGladiators는 사용자가 자연어 전략, 위험 수준, 종목, 거래 속도, 무작위성을 설정하면 실시간 가격으로 가상 거래를 수행하고 종료 거래의 교훈을 다음 시스템 프롬프트에 넣습니다. 댓글은 손익만으로 교훈을 만들면 우연한 승패를 학습할 수 있으므로 거래 전 가설·가정·무효화 조건을 기록하고, 독립적인 증거가 쌓일 때만 전략을 갱신하며 이전 전략으로 되돌릴 수 있어야 한다고 했습니다.
손익은 결과일 뿐 원인의 진단이 아니므로, 손실한 좋은 판단과 이익을 낸 나쁜 판단을 구분해야 한다는 의견입니다. 한 번의 노이즈가 다음 거래의 운영 전략을 바꾸지 않도록 업데이트를 후보 상태로 보류해야 합니다.
거래 전에 ReAct 방식으로 진입 근거를 남기고 거래 종료 후 그 근거가 맞았는지 손익과 분리해 평가하면 Reflection Loop의 학습 신호를 더 명확히 만들 수 있다는 제안입니다.
모든 Reflection을 시스템 프롬프트에 직접 넣기보다 별도 파일이나 Scratchpad에 기록하고 에이전트가 필요할 때 참조하도록 하자는 설계가 제시됐습니다.
- 한 번의 거래 결과만으로 전략을 바꾸면 노이즈와 과잉 보정이 생길 수 있습니다.
- Reflection 결과를 즉시 프롬프트에 반영할지, 별도 기록과 검증을 거칠지
- The reflection loop is where most of these projects fall apart imo. Seeing it baked into the prompt with actual trade history is a nice touch, lot of people just slap a generic "learn from your mistakes" line in and call it a day. Does it actually change behavior or just spiral into weird overcorrections? That's the part that always keeps me up at night with these things.
- Fun project :D Have it reason BEFORE each trade why it wants in, ReAct style, then reflect after close on whether that reasoning held, judged separately from PnL. Otherwise the loop just learns from noise.
- The reflection loop is the interesting part, but I’d separate outcome from lesson very carefully. P&L is consequence, not necessarily diagnosis. A good decision can lose and a bad decision can win, so I’d record the pre-trade hypothesis, assumptions, invalidation criteria and expected mechanism, then assess those separately after close. I’d also be careful about feeding every reflection directly back into the next prompt. That can create overcorrection or a self-reinforcing narrative. I’d treat lessons as candidate updates that need repeated or independent evidence before they modify the active strategy, and keep a last-known-good strategy available for rollback. Otherwise the system can technically “learn from experience” while actually learning from noise. **What prevents one noisy trade from changing the operating model that interprets the next trade?**
- and I build tailored bots for trading. hmu
- I would make there be an explicit mechanism/folder/file for tracking trade decisions with reasoning, so that it doesn't always get baked into the system prompt but instead the agent knows that it can reference the reasoning why. I have a similar setup for my own personal project where agents basically have a "scratchpad" where it can track its own reasoning. It is a little different than a complete audit log but I still have seen beneficial results. My specific example is for a fantasy football league (which I know is quite different from stock trading) but the tools available to the agents could be somewhat similar depending on what you described. Here is an example of Fable5 managing its own scratchpad - [https://league.jake-moses.com/teams/team-1](https://league.jake-moses.com/teams/team-1)
AI 코딩 에이전트를 활용한 프로덕션 개발 구조 ↗
댓글은 에이전트를 교체 가능한 작업자로 두고 프로젝트 지식, 규칙, 격리된 Worktree, CI 검증, Pull Request 흐름을 에이전트 바깥에 두는 구조에 모였습니다. 작업별 브랜치와 실패 시 닫히는 검증 게이트, 경로·도구 권한 계약, 취소 테스트, 읽기 전용 다중 모델 리뷰가 모델 자체보다 재현성과 안전성을 좌우한다는 내용입니다.
Issue → Task → Agent → 격리된 Workspace → Verification → Commit/PR 흐름을 Harness와 CI가 관리하고, 에이전트는 허용된 경로와 도구 안에서만 작업해야 한다는 의견입니다.
Worktree를 작업마다 분리하고 에이전트의 직접 Main Push와 Merge를 막으면 병렬 작업과 검증을 안전하게 운영할 수 있다는 경험이 공유됐습니다.
코드 수정 에이전트와 읽기 전용 리뷰 모델을 분리하면 같은 모델의 공통 맹점을 줄일 수 있으며, 리뷰 라운드 상한과 실제 저장소 확인이 필요하다는 의견입니다.
- 검증은 에이전트의 선택적 지침이 아니라 CI나 Harness가 강제하는 게이트여야 합니다.
- 작업별 브랜치·Worktree와 Pull Request 검토가 병렬 개발의 안전장치가 됩니다.
- 프로젝트 규칙을 하나의 거대한 Markdown 파일에 계속 넣기보다 짧은 실행 계약과 검색 가능한 근거로 나누는 편이 낫습니다.
- Linear 같은 외부 프로젝트 관리 도구를 사용할지 직접 Control Plane을 만들지
- i been thinking about this same thing lately and honestly theres no good ready made solution that i found the closest thing is probably combining github actions with some custom scripts but it gets messy fast. i ended up building something similar to what you describe with a bunch of shell scripts and docker containers for isolation per task the knowledge base part is tricky cause context windows are still the bottleneck no matter what agent you use. i started keeping project rules in a single markdown file per repo and having the agent read it at start of each session but even that gets bloated after a while for the control panel thing i havent seen anything open source that does all that. most teams i know just built their own with python or node and tie it to linear or github issues. maybe look at langchain's experimental multi-agent stuff but its not production ready at all
- the thing that usually unsticks this for me is treating the agent as a swappable worker and putting the durable stuff outside the prompt — a tiny machine-readable contract the harness actually enforces (allowed tools, write roots, “done means these checks green,” abort/cancel behavior), not another essay in AGENTS.md; project knowledge as retrieved receipts (path + hash/rev + why it was pulled) instead of dumping the whole KB every turn so rules stop overlapping in context; and the issue→dev→verify loop owned by CI/the harness, where verification is a gate that can fail closed, not a polite suggestion the model can skip when it’s “almost done.” onboarding gets deterministic when it’s a scripted env bring-up the agent is only allowed to *call*, not reinvent from memory each session. i’d also force one ugly abort test before the happy path (cancel mid-tool, mid-edit, mid-PR) because that’s where most “replaceable agent” setups quietly depend on a human babysitter. the single giant rules markdown is fine as human docs; once it becomes the runtime brain it always bloats and fights itself — keep the runtime contract small and version *that* when the agent changes, not the other way arou
- worktree per task is the bit that made parallel stuff sane for me, one branch per issue and the agent only ever touches that dir. keep the bring up as a script the harness runs, not instructions the model follows, that is what makes onboarding deterministic. and make the model open the pr but never merge, merge only happens on green checks outside the agent.
- The piece that made our setup stop depending on one agent being "good" was splitting write and review. Claude does the patches. Two other model families run read-only in parallel on the plan or the diff, and neither sees the other's notes. Claude only concedes a finding after checking the actual repo, not vibes. Same-family reviewers share blind spots, so the diversity is the point. Cap the rounds and treat an earned clean pass as a real result, otherwise the loop just manufactures more comments forever.
- the thing that actually stuck for us was treating the agent like a junior who needs a tiny blast radius. locked repo paths, no direct push to main, forced PR + human review on anything touching auth/payments/migrations. we keep a short "do not invent APIs" rule file and a checklist the agent has to fill before it says done (tests run? diff size? secrets scanned?). onboarding a new teammate to the agent setup took longer than writing the rules tbh — that was the real tax.
- I am a big fan of using Linear for the project management layer of utilizing agents, it has great MCP servers available and the structure of Projects -> Milestones -> Tasks -> Subtasks has seemed pretty easy for the agents to pick up on. I think this issue-tracking component is far more important than people realize, because it enables agents to rollout in parallel with one another and all work towards a common goal without communicating explicitly between the sessions. I think Cursor is also coming out with their own project tracking concept with their recent release of [https://cursor.com/blog/projects](https://cursor.com/blog/projects)
- One thing I’d add to that system is production context at verification time. The same diff can be harmless in one service and dangerous if it touches a critical dependency or path. Before merge I’d want: what does this affect, likely blast radius, rollback path, and what should be observably true after deploy.
AI 보조 JavaScript·TypeScript 개발용 오픈소스 ESLint 플러그인 ↗
AI Guard는 18개의 결정적 ESLint 규칙으로 Floating Promise, 빈 catch, 하드코딩된 비밀, 문자열 결합 SQL, 비효율적인 비동기 패턴을 검사하고 CLI와 GitHub Action, SARIF 출력을 제공합니다. 댓글은 밀리초 단위 AST 검사와 CI 실행이 LLM 리뷰보다 비용·지연 면에서 적합하다고 봤지만, 에이전트가 CLAUDE.md 같은 지침을 오래 유지하지 못해 CI 훅이 실제 방어선이 된다는 지적도 나왔습니다.
빈 catch나 Floating Promise처럼 AST로 판별할 수 있는 패턴은 LLM보다 결정적 Linter가 빠르고 비용이 없으며, 매 Pull Request에서 같은 결과를 내므로 적합하다는 의견입니다.
Floating Promise 규칙은 의도적인 Fire-and-forget과 실제 오류를 구분해야 해 False Positive가 많아질 수 있으므로, 보수적인 기본 설정과 실제 코드베이스 평가가 중요하다는 지적입니다.
초기 지침 파일만으로 에이전트의 행동을 오래 통제하기 어렵고, 결국 CI 검사가 핵심 방어선이 된다는 경험입니다.
- 결정적인 코드 패턴은 LLM 판단보다 AST 기반 CI 검사로 다루는 편이 적합합니다.
- 규칙의 탐지 범위와 False Positive를 얼마나 허용할지
- The deterministic angle is the right call, LLM reviewers add latency and cost where a simple AST check does the job in milliseconds. The floating promise rule sounds like the hardest to get right, too many false positives and people just bail on the whole plugin. Curious what your false positive rate looked like on real codebases during testing
- the failure mode i keep hitting is init-context, not the rules. an agent reads CLAUDE.md on turn one and stops honoring it by turn ten, so the linter still catches the empty catch. the CI hook ends up load-bearing, the instruction files are a bonus.
r/mlops글 2건
LLM의 Decode·Layer 처리·TTL 측정 도구 ↗
LayerLens는 토큰과 Transformer 레이어 단위로 추론 시간을 나누고 Prefill과 Decode를 분리해 시각화합니다. 댓글은 KV-cache 이벤트와 Scheduler·Batching 상태를 추가하면 배치 문제를 추적하는 데 유용하다고 봤지만, 레이어마다 동기화하면 GPU를 직렬화해 도구 자체가 보고하는 지연을 만들 수 있으므로 비동기 CUDA 이벤트 측정 여부를 확인해야 한다고 지적했습니다.
토큰×레이어 수준의 시간 분해는 일반 Profiler에 부족한 세부 정보를 제공하며, KV-cache와 Scheduler 상태를 붙이면 배치 이상 원인을 추적하는 데 도움이 된다는 의견입니다.
레이어마다 동기화하는 측정 방식은 GPU 실행을 직렬화해 실제 추론보다 큰 지연을 만들 수 있으므로, 비동기 CUDA 이벤트를 사용해야 한다는 기술적 우려입니다.
큰 모델이나 긴 시퀀스에서는 레이어별 시각화가 복잡해질 수 있어, 세부 정보와 집계 보기 사이의 균형이 필요하다는 지적입니다.
- KV-cache와 Scheduler·Batching 상태가 추론 병목 파악에 중요한 관측 대상입니다.
- 세밀한 레이어 단위 측정이 실제 GPU 실행을 왜곡하는지
- 전체 세부 타임라인과 집계 시각화 중 어느 쪽이 실용적인지
- **AI usage disclosure** Hi u/Dry_Mixture130 — thanks for posting to r/mlops! Because this community discusses and builds AI/ML systems, using AI tools is not inherently a problem. We do, however, ask for transparency about how submissions are created. **Please reply to this comment with a brief AI / automation disclosure, particularly if this post was created or submitted in whole or in part by an autonomous agent, bot, workflow, or other automated system.** If AI or automation was involved, please briefly describe what it did and what human review was performed before posting. This disclosure helps the r/mlops community distinguish human discussion, AI-assisted work, and automated/agent traffic while keeping the focus on useful technical conversation. Thanks for helping keep the signal high. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/mlops) if you have any questions or concerns.*
- this is cool, breaking it down by layer and token is exactly the kind of granularity that's missing from most profilers one thing that jumps out is the visualization could get real messy with bigger models or long sequences, maybe worth thinking about how to collapse layers or show aggregates without losing the detail for the stuff you're planning, KV-cache events and scheduler state would be huge for debugging batching weirdness, that's where half the headaches are
- Per-layer timing is useful only if measuring it doesn’t serialize the GPU. Are you recording CUDA events asynchronously, or synchronizing after every layer? The second approach could create the stalls LayerLens reports.
프레임워크부터 클라우드까지 연결한 추론 스택 그래프 ↗
Inference Stack 그래프는 Framework, Orchestration, Silicon, Cloud 사이의 호환 관계를 NVIDIA, AMD, TPU, Trainium, Inferentia, Gaudi까지 연결해 탐색하도록 구성됐습니다. 댓글은 문서와 GitHub 이슈를 오가며 가속기와 Orchestrator 호환성을 찾는 시간을 줄일 수 있는 도구로 평가했습니다.
공식 문서에 흩어진 호환성 정보를 하나의 그래프로 묶으면 야간에 여러 GitHub 이슈를 검색하는 시간을 줄일 수 있다는 반응입니다.
- **AI usage disclosure** Hi u/Comfortable-Fun5926 — thanks for posting to r/mlops! Because this community discusses and builds AI/ML systems, using AI tools is not inherently a problem. We do, however, ask for transparency about how submissions are created. **Please reply to this comment with a brief AI / automation disclosure, particularly if this post was created or submitted in whole or in part by an autonomous agent, bot, workflow, or other automated system.** If AI or automation was involved, please briefly describe what it did and what human review was performed before posting. This disclosure helps the r/mlops community distinguish human discussion, AI-assisted work, and automated/agent traffic while keeping the focus on useful technical conversation. Thanks for helping keep the signal high. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/mlops) if you have any questions or concerns.*
- this is the kind of thing that saves you from scrolling github issues at 2am trying to figure out if some accelerator even works with your orchestrator, nice work
r/deeplearning글 3건
LLM을 더 배우기 위한 학습 자료 ↗
Transformer와 GPT-2, Llama-3의 구성 요소를 공부한 사용자가 다음 학습 자료를 물었고, 댓글은 HuggingFace Course가 실용적인 기본기를 다루며 Karpathy의 Neural Networks: Zero to Hero가 수학을 코드로 연결한다고 추천했습니다. Autoregressive Token Generation과 KV-cache를 다루는 자료도 함께 제시됐습니다.
이미 이론 기초를 가진 학습자에게는 HuggingFace Course가 실습 중심으로 이어지고, Karpathy의 강의는 수학과 구현을 처음부터 연결하는 경로라는 추천입니다.
- HuggingFace Course와 Karpathy의 Neural Networks: Zero to Hero가 다음 학습 자료로 추천됐습니다.
- The HuggingFace course is a good place to start, it walks you through the practical side without getting too bogged down in the theory you already know. Karpathy's "Neural Networks: Zero to Hero" playlist on YouTube is also fantastic, he builds everything from scratch so you actually see the math turning into code.
- This article also explains the autoregressive token generation well: https://medium.com/advanced-deep-learning/autoregressive-next-token-prediction-kv-cache-in-transformers-afad22285baf
머신러닝 수학 공부의 피로감 ↗
머신러닝 수학을 공부할 때 계속 지치는 것이 정상인지 묻는 짧은 게시물이며, 댓글은 어떤 수학 영역이 어려운지 되물었거나 누구나 겪는 감정이라는 짧은 반응을 남겼습니다.
피로감의 원인을 파악하려면 먼저 어떤 수학 주제가 어려운지 구체화해야 한다는 반응과, 그런 감정은 흔하다는 반응이 함께 나왔습니다.
- what math specifically?
- Who doesn't?
Google Play의 Ashmere로 철학 배우기 ↗
Google Play의 Ashmere를 철학 학습 자료로 권하는 게시물이지만, 댓글은 없습니다.
r/AutoGPT글 2건
Git 없이 충돌하는 에이전트 변경을 잡는 방법 ↗
Git이 없는 환경에서 두 에이전트가 호환되지 않는 변경을 하려는 순간을 어떻게 포착할지 묻는 게시물이며, 댓글에는 foremerge 저장소 링크만 남아 있습니다. 충돌 감지 방식이나 합의된 운영 원칙을 판단할 만큼의 추가 설명은 없습니다.
- Repo, if you want to check any of the above against the code: [https://github.com/naw103/foremerge](https://github.com/naw103/foremerge)
실행 전 변경된 근거를 다루는 보안 통제 위치 ↗
에이전트 권한은 올바르지만 실행 전에 사용한 근거가 바뀌었을 때 보안 통제를 어디에 둘지 묻는 게시물입니다. 댓글이 없어 통제 위치나 대응 방식에 관한 근거는 없습니다.
용어 해설
- 내구성 실행(Durable Execution)
- — 에이전트가 도구 호출 중 중단돼도 저장된 체크포인트와 재시도 규칙을 바탕으로 작업을 이어가는 실행 방식입니다. 외부 상태를 중복 변경하지 않도록 멱등성과 복구 절차를 함께 설계합니다.
- 트레이싱(Tracing)
- — 에이전트 실행마다 입력, 도구 호출, 최종 답변, 지연 시간, 비용을 기록해 병목과 실패 원인을 추적하는 관측 방식입니다. 기록된 실행은 평가 사례와 운영 개선의 근거가 됩니다.
- 컨텍스트 엔지니어링(Context Engineering)
- — 모델에 전달할 규칙, 검색 결과, 작업 상태를 필요한 범위로 구성하는 방식입니다. 전체 지식베이스를 매번 넣기보다 경로와 해시 같은 근거를 붙여 관련 정보만 주입합니다.
- CAPTCHA
- — 사용자가 사람인지 확인하는 자동화 방지 절차입니다. 입력 폼, Cloudflare 확인, SMS 인증처럼 서비스마다 방식이 다르며, 에이전트가 회원가입을 수행할 때 별도 차단 요인이 됩니다.
- 사람 재식별(Person Re-identification)
- — 서로 다른 카메라나 시점에서 관측된 사람의 외형 특징을 비교해 같은 사람인지 식별하는 컴퓨터 비전 과제입니다. 얼굴 추적과 달리 여러 영상 구간의 동일 인물 연결에 초점을 둡니다.
- KV 캐시(KV-cache)
- — Transformer가 이전 토큰의 key와 value를 저장해 다음 토큰 생성 때 과거 토큰을 다시 계산하지 않도록 하는 추론 최적화 기법입니다. 메모리 사용량과 배치 처리 상태를 함께 관찰할 대상입니다.
- Git worktree
- — 하나의 저장소에서 작업별 독립 디렉터리를 만들어 여러 브랜치를 병렬로 다루는 기능입니다. 코딩 에이전트가 서로의 파일을 덮어쓰지 않게 하며, 이슈별 검증과 Pull Request 흐름을 분리합니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
