TL;DR
이번 상위 스레드는 에이전트와 배포 시스템에서 조용한 실패를 막으려면 기본값과 사후 검증보다 실행 전 거부 조건이 필요하다는 흐름을 보였습니다. 런타임 라우팅에서는 하드 요구사항을 먼저 필터링하고 선호도는 통과한 후보의 순위만 정해야 하며, 에이전트 행동 변화는 고정된 재생 사례와 결정률·도구 호출 분포로 추적해야 한다는 의견이 모였습니다. 모델 개발 쪽에서는 TPU v5e용 Gated DeltaNet-2 커널과 210M 파라미터 text-to-image DiT의 벤치마크가 공유됐고, 후자는 timestep shift와 생성 품질 지표의 관계를 측정했습니다. Claude 기반 게임 제작, AgentZ의 deny-all 샌드박스, RedThread의 도구 호출 재생처럼 구현 사례도 있었지만, 실제 효과와 적용 범위에는 이견이 남았습니다.
Reddit 서브레딧별 토론
r/LLMDevs글 3건
제로 워커 배포 성공을 막은 런타임 요구사항 분리 ↗
복제본 수가 누락된 설정이 0으로 조용히 대체되면서 워커를 하나도 만들지 않은 배포가 성공 상태로 끝났고, 이후 검증 단계가 이를 되돌렸습니다. 댓글은 하드 요구사항을 거부 게이트로 두고 선호도 점수와 분리하며, 거부 사유에 누락 항목과 부족한 정도를 담아야 설정 조합의 폭증을 피할 수 있다는 데 모였습니다.
하드 요구사항은 최소 조건을 검사하는 별도 predicate로 두고, 통과하지 못한 후보는 선호도 점수에 넣지 않아야 합니다. 선호도는 이미 조건을 만족한 런타임을 정렬하는 데만 쓰며, 후보가 없으면 가장 가까운 실패 후보를 선택하지 않고 누락 키와 부족한 정도를 반환해야 합니다.
누락된 수량·제한·시간 초과·재시도 예산을 0이나 무제한으로 대체하면 아무 일도 하지 않은 작업이 성공처럼 보일 수 있습니다. 렌더링 전에 필수값을 파싱하고 복제본 수를 1 이상으로 제한하면 비용이 드는 실행 전에 오류를 막을 수 있습니다.
거부를 배포 시점의 하드 오류로 처리할지, 라우팅하지 않고 작업을 대기 상태로 남길지는 댓글에서 열려 있습니다. 다만 거부 자체를 조용한 불일치나 가장 가까운 후보 선택으로 대체하지 않는다는 방향은 일관됩니다.
- 하드 요구사항과 선호도는 서로 다른 자료형과 처리 단계로 분리해야 합니다.
- 누락된 필수값을 조용한 기본값으로 바꾸지 말고 실행 전에 차단해야 합니다.
- 요구사항 불충족을 배포 단계의 즉시 오류로 처리할지 작업 대기로 남길지는 정해지지 않았습니다.
- the second a deploy succeeds with zero workers you know something deeply wrong is happening behind the scenes. good on you for killing the fallback entirely instead of just adding a warning. warnings get ignored typed runtime policy is the move. i went down the rabbit hole of trying to make a universal matcher once and ended up with basically a full constraint solver that nobody wanted to maintain. curious what your refusal path looks like, is it a hard error at deploy time or does it just refuse to route and leave the task pending
- Keep them in two places with different types. Hard requirements are a short list of minimums that either match or refuse, and preferences are just a score used to rank the runtimes that already passed. My rule for which side a field goes on: if you could ever reasonably relax it, it is a preference. The schema only gets giant when preferences leak into the must-match side.
- The rule that survived contact for us: a hard requirement is never allowed to carry a weight. The moment it is a number in the same struct as a preference, a high enough score on everything else buys it, and you are back at the zero-replica deploy wearing a different hat. So they live in two different shapes. Requirements are a predicate over a candidate that returns OK or a refusal carrying the reason. Preferences are a ranking function that only ever sees candidates which already returned OK. One list filters, the other sorts, and there is no arithmetic path from the second into the first. The other half is what the refusal carries. Ours does not return false, it returns what was missing and by how much: out of reach by two squares, not "invalid". That single change moved most of our routing logic out of config, because a caller can react to a named gap and does not need a schema entry for every combination in advance. Schema size then stops growing with the cross product. A new capability is one predicate, not a row of matrix cells.
- removing the fallback is the right call, and it generalises: a missing required value should be an error, not a default. zero is the worst possible default for a count, because zero is a valid-looking answer that means "do nothing, successfully". worth auditing the rest of the config for the same shape. anywhere a count, limit, timeout or retry budget quietly defaults to 0 or to unlimited is the same bug waiting on a different missing key. make the schema require them and the deploy fails at parse time instead of at verification.
- yeah keep hard requirements as a boolean gate before any preference scoring, drop anything that fails the required set instead of soft-matching. preferences only rank what's left, and if that set is empty fail loud with the missing keys rather than picking the nearest miss.
- the shape of this bug ("technically succeeded, semantically did nothing") is the one I've learned to fear most in my own systems. the version I hit: our site only rebuilds once a day, and only one specific commit message is allowed to trigger that rebuild — everything else should be a no-op. for a while, "no-op" silently meant "still spin up the build container, still burn the cost, just skip the actual deploy step at the end." the pipeline reported success every time, and the failure was purely financial, not functional — so nothing anywhere looked wrong until someone actually read the bill. what fixed it wasn't a smarter check, it was moving the gate earlier: the commit message is checked before anything expensive happens, not after. same instinct as your typed runtime policy — the cheapest fix for "quietly did nothing" is usually to make the empty/zero/no-op path physically unable to reach the expensive part at all, rather than detecting it once it's already there. question for you: now that the replica count has to be ≥1 to render anything, have you found a second field that's still allowed to silently default in the same codepath? in my experience hardening one field just mo
에이전트 파이프라인보다 직접 지정한 1회성 코드 수정 ↗
작성자는 필요한 파일과 컨텍스트를 직접 지정해 LLM이나 aider로 코드를 수정하고 diff를 확인하는 방식이 대부분의 작업에서 저렴하고 빠르다고 했습니다. 댓글은 이 효율이 1회성 수정 자체보다 코드베이스를 잘 아는 사람이 정확한 파일을 고르는 데서 나온다는 반론을 보탰고, FrugalGPT 표기와 aider 사용 경험도 언급됐습니다.
작업자가 변경할 파일과 범위를 알고 있으면 작은 프롬프트로 필요한 코드만 전달하고, 웹 챗봇의 복사·붙여넣기나 직접 편집 도구로 결과를 받은 뒤 diff를 검토하는 흐름이 긴 agentic 파이프라인보다 간결합니다. 댓글에서는 이 방식이 프로젝트 전체를 불필요하게 탐색하거나 대규모 리팩터링을 일으키는 위험을 줄인다고 봤습니다.
효율의 원인은 1회성 수정이라는 형식보다 작업자가 정확한 파일과 컨텍스트를 이미 알고 있다는 점일 수 있습니다. 전체 워크플로를 쓰는 10%의 작업이 낯선 코드 영역에 집중되는지 비교해야 두 방식의 차이를 분리할 수 있습니다.
- 정확한 파일 선택과 충분한 컨텍스트가 수정 결과의 품질에 큰 영향을 준다는 데 의견이 모였습니다.
- 직접 수정 방식이 agentic 파이프라인보다 일반적으로 빠르고 정확한지는 코드베이스 친숙도에 따라 달라질 수 있습니다.
- i do the exact same thing. the whole agentic pipeline feels like overkill for 90% of what i actually need to get done. i know my codebase, i know what files need changing, just let me point the thing at the right spot and go the copy/paste from web chat is so underrated too. no api costs, no weird tool integrations breaking, just me and the diff. feels way more like actual pair programming than babysitting some agent that's gonna wander off and refactor half the project
- frugaast? I think you mean FrugalGPT - https://github.com/stanford-futuredata/Frugalgpt ?
- Yes same experience here. Still big fan of aider in 2026
- Most of the time I do the same 👍
- Your third bullet is doing all the work. You know the codebase well enough to name the files, and that is the step the agentic pipeline exists to replace. You are doing it in your head for free. So the comparison underneath is between having the context already and making a machine go find it. Your 90% looks like the fraction of your work that lands in code you know. There is a way to check. Look at whether the 10% where you reach for the full workflow is also the part of the codebase you know least. If it is, familiarity is the variable and the heavy workflow is just what you use when you lose it.
- i'd bet the correctness comes from your file selection, not the one-pass part. you hand-pick the exact context; agents mostly fail because they guess at it, and no pile of skills and md files fixes a bad guess.
릴리스 사이 에이전트 행동 회귀를 잡는 재생 테스트 ↗
기능 테스트를 통과해도 할인율·가격 선택·에스컬레이션·전환율 같은 상업적 행동이 달라질 수 있다는 문제에 대해, 댓글은 고정된 운영 사례를 매 릴리스 재생하고 결정률과 도구 호출 순서를 비교하는 방식을 공유했습니다. Judge model은 명확한 기준이 있는 경우에 제한하고, shadow traffic은 게이트보다 새로운 사례를 찾는 보조 수단으로 두자는 의견이 많았습니다.
실제 운영에서 정제한 고정 trace와 상업적 시나리오를 매 릴리스 같은 입력으로 재생하고, 할인 여부·할인 폭·에스컬레이션 여부·도구 호출 순서를 하드 assertion으로 비교해야 합니다. 한 번의 답변이 자연스러워도 도구 호출이 사라지거나 인자가 바뀌면 게이트에서 잡을 수 있습니다.
단일 pass/fail 대신 사례를 여러 번 실행해 결정률 분포를 저장하고, 할인·에스컬레이션 같은 행동군별로 평균과 범위를 따로 추적해야 합니다. 댓글에서는 단일 실행의 샘플링 변동과 전체 평균이 특정 행동의 악화를 가릴 수 있다고 봤습니다.
서로 다른 model family의 두 judge가 같은 ground truth를 근거로 동일한 문제를 지적할 때만 회귀로 인정하는 방식이 제안됐지만, LLM-as-judge만으로는 부드러운 회귀를 놓칠 수 있다는 반례도 나왔습니다. Shadow traffic은 시나리오 세트에 새 사례를 추가하는 데 유용하지만 기준 게이트를 대체하지는 못한다는 방향입니다.
- 기능적 성공과 승인된 버전과 같은 행동을 유지하는 것은 별도 검증 대상입니다.
- 고정된 재생 사례와 행동별 분포 지표가 단순 기능 테스트보다 적합합니다.
- Judge model을 어느 범위까지 사용할지와 운영 중 shadow traffic의 게이트 역할에는 차이가 있습니다.
- Functional tests miss this because the agent is still "correct". We pin a replay set of the commercial contexts that matter, then run two read-only judges from different model families that never see each other's notes. A regression only sticks if both flag the same fact against the same ground truth (policy, pricing table, escalation rules). Vague unease does not lower the score, and letting the same family that wrote the agent grade itself is how soft drift slips through.
- replay set plus distribution checks. run the same 50 odd commercial cases a few times each release and graph the rates, like discount given, escalation triggered, not just pass fail. single runs hide drift because sampling noise covers it, the shift in the average is what catches the aggressive discounting stuff early.
- we stopped trusting unit tests for this. what bit us was the agent still "passing" the happy path while quietly skipping a tool call it used to make, or calling it with slightly different args that still looked valid. now we keep a frozen set of real prod traces (sanitized) and replay them on every prompt/model bump — if the tool sequence drifts or the final claim set changes, it fails the gate even when the answer sounds fine. llm-as-judge alone kept rubber-stamping soft regressions for us.
- The gap you describe is between "it works" and "it behaves like the version we signed off", and tests only check the first one. What worked for me: a set of cases that encode the commercial behaviours (discounting, escalation, pricing, all with the same context) with hard assertions where the decision is a choice, did it discount, how much, did it escalate. LLM judge only where its actually a judgement call. The run I accept becomes the reference, I commit it together with prompt, config and the commit hash, and every release gets compared to it case by case Two things that replay datasets usually miss imo. One, I sample each case a few times on the accepted version and keep the range, so a change counts only if it goes outside that range. Judges flip on identical input way more than people think, Dan Luu measured \~23% on Senior SWE-Bench just yesterday, and I've seen 5/5 -> 2/5 -> 5/5 in eleven minutes on the same case. Two, aggregate per class (one number for discounting, one for escalation etc), because a good average hides one broken behaviour very easily. Shadow traffic I'd use after, not instead. Its useful to find new cases to add to the reference, but it is not the gate.
- Behavior is emergent, you cannot dictate it as a list as it’s not functional. The secret is creating an operational envelope between constraints and invariants.
- Functional tests miss this because the failure is statistical, not a crash. What worked for us was scoring behavior, not correctness. We built a fixed set of scenarios and recorded the decision the agent made on each, discount given whether it escalated, which path it chose. Every release you rerun the set and diff the distribution so if average discount jumps or escalation drops it shows up even though every case still technically passes. The other half is shadow running the version on a slice of real traffic before it takes over because the scenario set never covers everything. Treat those decision rates as regression metrics, with thresholds the way you would latency.
r/deeplearning글 3건
TPU v5e용 Gated DeltaNet-2 융합 학습 커널 ↗
게시자는 JAX/Pallas로 Gated DeltaNet-2 학습 커널 세 가지를 구현하고, TPU v5e-8에서 순전파와 역전파를 함께 측정했습니다. PALLAS는 FP32에서 associative-scan 경로 대비 27.18배, 순수 JAX chunked-WY 경로 대비 2.63배였고, 최고 측정치는 38.77배였지만 순전파만 보면 순수 JAX보다 약 1.6배 느려 현재는 학습용에 맞춰져 있습니다.
Pallas의 fused custom_vjp 역전파가 저장된 순전파 잔차를 재사용해 재계산을 줄이면서 backward-dominated 학습에서 큰 속도 향상을 냈다는 점이 핵심입니다. 댓글은 38.77배 향상이 역전파 계산에서 비롯된 효과일 가능성이 크다고 봤습니다.
게시자는 FP32·BF16, 두 기준 구현, 여러 shape sweep의 결과와 gradient check·token-serial 비교·raw JSON을 함께 제공했지만, 추가 baseline과 forward 병목 프로파일링이 더 필요하다고 했습니다. TPU v5e와 d_head=128 중심의 최적화라 CPU·GPU나 추론 전용 사용에는 순수 JAX fallback이 적용됩니다.
- 큰 속도 향상은 순전파보다 역전파 경로에 집중되어 있습니다.
- that 38.77x jump is absurd, backward pass must be doing some serious heavy lifting
1,400줄로 처음부터 만든 Deep Learning 프레임워크 ↗
본문과 댓글에 구체적인 내용이 없습니다.
훈련 샘플의 선택과 순서가 미치는 영향 ↗
본문과 댓글에 구체적인 내용이 없습니다.
r/artificial글 3건
근처 Meta 스마트 글래스를 감지하는 iPhone 앱 ↗
폴란드 개발자가 주변의 Meta 스마트 글래스를 감지하는 iPhone 앱을 만들었다는 게시글에 대해, 댓글은 앱이 Bluetooth 광고를 읽고 구별 가능한 MAC prefix를 이용하는 방식으로 추정했습니다. 감지 거리는 약 10m일 수 있지만 착용자가 주소를 무작위화하거나 이미 페어링한 경우 실패할 수 있다는 한계가 함께 나왔습니다.
앱의 실용성은 주변 기기의 존재를 알 수 있다는 점에 있지만, Bluetooth 광고와 MAC prefix에 의존하면 거리와 식별 조건에 따라 감지 결과가 달라질 수 있습니다. 착용자가 주소를 무작위화하거나 기기를 이미 페어링한 경우에는 탐지가 어려워집니다.
일부 댓글은 공공장소에서 촬영되는 상황 자체를 크게 신경 쓰지 않거나 iPhone을 사용하지 않아 해당 앱을 쓸 이유가 없다고 했습니다.
- 앱이 Bluetooth 광고와 기기 식별 정보에 의존한다는 점이 댓글에서 공통으로 언급됐습니다.
- 스마트 글래스 감지 앱의 실제 필요성과 활용 가치는 엇갈렸습니다.
- I wouldn't no. I'm in public, record me walking around doing boring things if you want. I also don't have an iPhone.
- It's just sniffing Bluetooth advertisements, and those MAC prefixes are pretty distinctive, so range is maybe 10 meters and it fails if the wearer randomizes or pairs already
- woahh
- Title: Polish developer builds app that detects nearby Meta smart glasses First sentence: Polish developers made an iPhone app that can detect nearby Meta smart glasses Second sentence: Apparently a group of Polish developers created an iPhone app that can detect nearby Meta smart glasses. Why are you wasting our time like this? Are you even a human?
AI가 인류를 위협하는 다섯 가지 경로 ↗
게시글은 전력망 장애, 자동화된 군사적 오판, 생물학적 악용, 핵심 인프라의 점진적 의존, AI 연구 자동화라는 다섯 시나리오를 제시하고 1번과 4번을 더 가능성 높은 경로로 봤습니다. 댓글은 인간이 기술을 이용해 서로를 해치는 경로가 초지능적 통제 상실보다 현실적이라는 의견과, 전력망·공급망 의존은 우려되지만 일부 시나리오는 인류 멸종 규모에 이르기 어렵다는 반론으로 갈렸습니다.
전력망과 공급망처럼 사람이 내부 동작을 충분히 이해하지 못하는 시스템에 에이전트를 연결하면, 오류가 여러 기관과 인프라를 따라 전파될 수 있다는 우려가 나왔습니다. 댓글에서는 이미 불투명한 재고 시스템을 재부팅에 의존하는 경험을 식량 공급망과 병원으로 확장하면 위험이 커진다고 봤습니다.
인류 멸종에 가까운 결과보다 인간이 AI를 무기나 의사결정 도구로 사용해 다른 인간을 해치는 역사적 경로가 더 현실적이라는 의견이 나왔습니다. 전력망 장애나 일부 국가의 핵심 인프라 위탁만으로는 전 지구적 멸종에 이르기 어렵다는 반론도 있었습니다.
생물학적 악용과 목표가 어긋난 AI 연구 자동화는 댓글에서도 가장 심각한 후보로 남았지만, 전제와 실현 가능성에 대한 추가 근거는 제시되지 않았습니다.
- 인간이 AI를 이용해 다른 인간에게 피해를 주는 경로와 핵심 인프라의 불투명한 자동화가 주요 우려로 남았습니다.
- 전력망 장애와 자동화된 핵심 인프라가 인류 멸종까지 이어질 가능성, 군사 시스템에 AI를 투입할 시점, 초지능적 통제 상실과 인간의 악용 중 어느 쪽이 더 현실적인지를 두고 의견이 갈렸습니다.
- I guess I just remain in the camp of being less worried about a skynet scenario and more worried about the historically accurate scenario: humans using a new technology to kill other humans in a terrible way. I think it’s far more likely we use the technology to end our selves than anything else
- 1. This wouldn't even come close to wiping out humanity 2. Nuclear launches will not be handled by AI for some time to come. 4. The most critical stuff won't be handed over in all countries, so again, not wiping out humanity, even if some nation would take a big hit. 3. and 5. seem like the worst options out of these, but the answer is not great in general.
- I work in retail so maybe this is just my brain being fried from dealing with inventory systems that break for no reason, but number 4 scares me way more than the others. We already got systems at my job that nobody fully understands and when something goes wrong we just reboot and pray. Scale that up to like, food supply chains and hospitals and we're just hoping the magic box keeps working The grid one feels too real also. Remember when Texas froze and it wasn't even an AI thing just regular old infrastructure failure. Add in some agent systems nobody monitored properly and yeah I can see that happening in February somewhere cold
- So uhhh there's books and stuff about this. But yeah those are decent ones.
- I couldn't read them all in a row because it genuinely terrifying
최신 사건 오인으로 인한 LLM 편향 지적 ↗
작성자는 LLM이 특정 정치 집단을 방어하는 편향을 반복하고 다른 집단으로 화제를 돌린다고 했습니다. 댓글은 최신 사건이 학습 데이터에 없거나 웹 검색을 하지 않아 생긴 시점 문제일 수 있으며, 편향을 단정하기보다 최신 뉴스를 검색하도록 요청하고 결과를 함께 점검하는 편이 낫다고 봤습니다.
댓글에서는 같은 현상을 편향보다 최신 사건에 대한 학습 데이터 부재와 검색 미실행으로 해석했습니다. 사용자가 최신 뉴스 검색을 명시하고 모델의 오류를 협력적으로 교정하면 원인과 사실관계를 더 분명히 확인할 수 있다는 의견입니다.
작성자는 특정 정치 집단을 방어하고 다른 집단으로 전환하는 응답이 반복된다고 보고 편향을 문제로 제기했습니다. 다만 댓글에는 해당 패턴을 독립적으로 확인하는 사례가 충분히 나오지 않았습니다.
- 최신 사건을 다룰 때 모델의 지식 시점과 웹 검색 여부를 확인해야 합니다.
- 관찰된 응답을 정치적 편향으로 볼지 최신 정보 부족으로 볼지가 갈렸습니다.
- What bias do you claim is happening here? All I see is the very typical pattern of an LLM not knowing latest events because it wasn't trained on them and didn't bother to web search. This happens all the time.
- Rather than telling the machine "You showed bias..." try asking it, "Will you please check the internet for news about the most recent..." I think some users get locked into an accuse/demand spiral when LLMs work much better in a collaborative dynamic. You have to accept that it's going to make mistakes, and you have to remember that it cannot read your mind
- Did you tell them your dad was in town the same weekend
- I mean the LLM will agree with you on most things if you tell it directly like that.
r/AutoGPT글 3건
Omarion SEC CLI의 자율 루프와 오류 회복 ↗
Omarion SEC CLI는 장기 메모리, 헤드리스 검색, 대화와 실행 요청의 분리, 중복 오류를 감지하는 전략 전환, 작업 완료 전 자체 평가를 결합한 ReAct 루프를 구현했습니다. 댓글은 같은 도구 호출을 반복하다 컨텍스트가 소진되는 문제를 피하는 self-healing 설계를 긍정적으로 평가했습니다.
도구 호출 실패의 지문을 비교해 같은 오류를 반복하지 않고 다른 전략으로 전환하는 방식은 무한 오류 루프를 끊는 직접적인 장치입니다. 댓글은 일반적인 에이전트가 같은 오류를 되풀이해 컨텍스트를 소진하는 문제와 대비해 이 설계를 긍정적으로 봤습니다.
Omarion은 대화 요청을 실행 루프에서 분리하고, Pydantic 도구 스키마 검증·backoff 재시도·완료 전 평가 단계를 추가해 실행 조건을 좁혔습니다. 장기 루프의 실제 예외 상황과 유지 비용은 댓글에서 다뤄지지 않았습니다.
- 중복 오류를 감지해 동일한 실패 경로를 반복하지 않는 장치가 필요하다는 평가가 나왔습니다.
- That self-healing part is actually clever, most agents just bang their head on same error until context fills up.
실제 자금을 움직이는 자율 에이전트 보안 ↗
본문과 댓글에 구체적인 내용이 없습니다.
도구 호출 실패 경로를 재생하는 RedThread ↗
RedThread는 신뢰할 수 없는 텍스트가 에이전트의 다음 도구 호출을 바꾸는 사례를 저장하고, 입력 컨텍스트·도구 계약·제안된 호출·결과·점수를 다시 실행하도록 만든 CLI입니다. 게시자는 이를 자율성 프레임워크가 아닌 모델·프롬프트·어댑터 변경을 비교하는 테스트 하네스로 구분했습니다.
r/LangChain글 2건
Perplexity보다 저렴한 웹 기반 AI 서비스 ↗
작성자는 1,000회 질의당 3.5달러의 웹 기반 AI 서비스를 만들었고, SimpleQA 82%와 일반 질의 95% 이상을 기록했다고 했습니다. 유일한 댓글은 Perplexity가 무료인지 묻는 가격 모델에 대한 의문이었습니다.
서비스의 비용과 정확도 수치가 제시됐지만, 댓글에서는 비교 대상인 Perplexity의 무료 이용 가능성을 지적해 가격 비교의 기준이 명확하지 않다는 문제가 남았습니다.
- 1,000회당 비용을 Perplexity와 직접 비교할 수 있는지에 의문이 제기됐습니다.
- Isn't perplexity free?
프롬프트 변경 뒤 위험한 도구 경로를 재생하는 RedThread ↗
RedThread는 검색된 텍스트나 중간 도구 결과가 이후 호출을 바꾸는 사례를 컨텍스트 조각·도구 스키마·제안 호출·응답과 함께 저장합니다. 작성자는 이를 프롬프트·모델·어댑터 변경 뒤 반복 실행하는 초기 단계의 CLI로 소개했으며, LangChain 통합이나 런타임 가드레일은 아니라고 선을 그었습니다.
r/ClaudeAI글 3건
Claude로 만든 브라우저용 3D 피자 배달 게임 ↗
작성자는 Claude를 사용해 도시 생성, 스쿠터 물리, GPS 최단 경로, 피자 상태 변화, 교통 신호 상태 머신과 택시 교통 AI를 포함한 브라우저 게임을 만들었습니다. 댓글은 결과물이 거칠고 컴퓨팅 자원을 낭비했다는 반응이 많았으며, 건물 모서리 충돌·화면 밖 geometry 제거·교차로에서 택시가 멈추는 문제를 추가 프롬프트와 수동 수정으로 해결해야 했다는 본문과 맞물렸습니다.
댓글은 게임의 시각적 완성도가 낮고 컴퓨팅 자원을 많이 쓴 결과에 비해 목적이 불분명하다고 평가했습니다. 이는 작성자가 충돌 오류와 렌더링 성능 문제를 직접 수정하고 교통 AI를 여러 차례 조정해야 했다는 내용과 연결됩니다.
Claude가 도시 격자 연결, GPS 경로와 방향 안내, 스쿠터 운동 모델, 신호등 감지, 택시 이동 로직을 생성해 여러 시스템을 하나의 브라우저 게임으로 묶었다는 점은 댓글의 비판과 별개로 구현 범위를 보여줍니다.
- Claude가 게임의 여러 하위 시스템을 생성했지만 충돌·성능·교통 AI에는 추가 수정이 필요했습니다.
- 게임의 결과물을 유용한 프로토타입으로 볼지 컴퓨팅 자원 낭비로 볼지가 갈렸습니다.
- What a waste of compute
- looks a bit sloppy
- but why?
- > The city 's hungry. You're on the > clock. Jesus man.
- Looks pretty bad tbh
- how many tokens dude
- Necronomicon loading
- Can you just give it 1 more prompt "fix clipping issues"
- 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.*
- Everybody says that if **you're** driving a car, you should look twice for motorcycles. Well, what if the motorcycle is bigger than the cars?
Claude와 예멘 무기 사용 의혹 기사 ↗
본문 댓글은 자동 관리 봇과 커뮤니티 운영 봇의 안내뿐이며, 기사 내용이나 Claude·Anthropic의 직접 관련성을 뒷받침하는 토론은 없습니다.
- 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.*
- **ClaudeAI-mod-bot usage limit reached. Your post will be reviewed in 5 hours.** j/k! Relax. Just need to get the humans to take a look at this...
- This post is not considered sufficiently relevant to the ClaudeAI subreddit. We require sufficient direct relevance to the Claude/Anthropic technology. Please post more general interest posts elsewhere. If this about a competitor, it must contain substantiated direct comparisons against Claude. Please refer to subreddit rules.
Claude 사용량 제한 관련 게시물 ↗
댓글은 해당 게시물을 사용량 제한 토론 허브로 옮기라는 자동 안내와 운영 로그를 제공합니다. 기술적 원인이나 해결책에 관한 이용자 의견은 없습니다.
- 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.*
- Hey, we have identified your post as being related to Claude usage limits. **Please post this in the latest [**Usage Limits Discussion Hub here**](/comments/1w46dbl) to help us keep track of experiences and see what others have reported. **Look for workarounds in the comments and past reports.** Be sure to mention your plan tier and platform. Your post has been mirrored and recorded on the [**r/ClaudeAI report log here**](https://www.reddit.com/r/ClaudeAI/comments/1t33k25/rclaudeai_user_problem_report_log_and_surge/). If you believe your post has been misclassified, please message the humans via Modmail. FYI: We favor posts on the main page that share useful analysis and workarounds.
r/computervision글 3건
Materials Science 관점의 Computer Vision 학습 경로 ↗
Materials Science 학생이 Classical Machine Learning 이후 Computer Vision과 Materials Informatics를 공부할 순서와 프로젝트를 물었습니다. 댓글은 MATLAB Image Processing 예제나 Python OpenCV로 디지털 이미지 처리부터 익히고, Digital Signal Processing 기초를 거쳐 1차원 신호에서 2차원 이미지 처리로 확장하라고 권했습니다.
기초 디지털 이미지 처리 알고리즘을 먼저 익힌 뒤 MATLAB의 Image Processing 예제나 Python OpenCV를 사용하고, 신호 처리 지식을 1차원에서 2차원으로 확장하는 순서가 권장됐습니다. 관련 교재로 Gonzalez·Woods·Eddins의 저서와 Davies의 Computer and Machine Vision이 언급됐습니다.
- Computer Vision 입문 전에 디지털 이미지 처리와 신호 처리 기초를 익히는 경로가 권장됐습니다.
- I would recommend form all basic Image proceeding algorithms - since You are student - - if You have Matlab then start form examples in Image processing module (alternatively Python OpenCV ) . There are a lot of good books like : "Digital Image Processing Using Matlab" - Gonzalez Woods & Eddins or "Digital Image Processing " by Gonzalez Woods & Eddins ( any book of this authors) - I recommend start form older to newest edition. "Digital Signal and Image Processing using MATLAB" by Gérard Blanchet Maurice Charbit "Computer and Machine Vision: Theory, Algorithms, Practicalities " by E. R. DAVIES and other authors. In My opinion it is good to have basic digital signal processing knowledge, it is easy then move form 1-D (signal) to 2-D (image) processing.
ECCV Workshop Springer/Meteor 최종본 제출 지연 ↗
ECCV 2026 워크숍 논문의 Springer/Meteor 최종본 제출 링크가 도착하지 않았다는 문의에 대해, 댓글 작성자는 워크숍 주최 측으로부터 Springer 쪽 지연이 일주일가량 지속된다는 안내를 받았다고 했습니다.
제출 링크 지연의 원인이 Springer 측 처리 지연이라는 경험담이 공유됐지만, 최종본 제출 일정이나 해결 시점은 확인되지 않았습니다.
- Springer 측의 제출 링크 발송이 지연되고 있다는 경험이 공유됐습니다.
- Same here! We got an email from workshop organizers that there has being a delay from Springer side about a week ago.
Pi 5의 Hailo-8L 960 입력과 소형 객체 탐지 ↗
작성자는 Raspberry Pi 5와 Hailo-8L에서 960 입력의 실제 종단 간 처리량, YOLO 라이선스, 항공 영상의 10–25픽셀 객체 학습, 이동 카메라의 ego-motion 추적을 함께 물었습니다. 댓글은 Hailo 자체 소프트웨어와 라이브러리를 사용하면 공식 속도에 가까웠다는 경험을 공유했지만, 소형 객체 개선과 ego-motion 보정의 신뢰성에는 구체적 수치를 제시하지 않았습니다.
Hailo-8L의 모델 자체 속도와 Pi 5에서 전처리·후처리를 포함한 전체 파이프라인 속도는 구분해야 합니다. 댓글은 제조사 소프트웨어를 모두 사용하면 공식 수치에 가까웠다고 했지만, 960 입력의 종단 간 결과는 제공하지 않았습니다.
소형 객체를 단순히 crowd detection 방식으로 처리하는 것 외에 확실한 개선책은 댓글에서 나오지 않았고, 이동 카메라의 telemetry 기반 보정은 기존 방식보다 신뢰성이 낮을 수 있다는 우려가 제기됐습니다.
- 모델 자체 처리량과 전처리·후처리를 포함한 실제 파이프라인 처리량을 구분해야 합니다.
- 소형 객체 탐지와 telemetry 기반 카메라 움직임 보정의 실효성은 확인되지 않았습니다.
- 1. I got speeds of the Hailo8 that match what they say using all their own software and libraries. The rest of the pipeline is up to you of course. 3. .. not really unless you just go down the crowd detection route like using ShanghiTech 4. Never tried it. But seems meaningfully less reliable
r/MachineLearning글 1건
단일 GPU에서 210M text-to-image DiT를 처음부터 훈련한 측정 ↗
게시자는 RTX PRO 6000 한 장으로 3.5일 동안 4.2M장의 256² 이미지를 사용해 210M 파라미터 text-to-image DiT를 훈련했습니다. Cross-attention의 학습된 슬롯이 중간 noise에서 약 90%의 attention mass를 받았고, flow-matching loss는 0.805에서 0.754로 줄었지만 FID는 33.7에서 27.0으로, FD-DINOv2는 570에서 218로 개선됐으며, timestep shift 2.8은 20단계 생성에서 no-shift보다 낮은 FID를 냈습니다.
학습된 2개의 key/value 슬롯이 중간 블록 cross-attention 질량의 약 90%를 흡수하고 EOS는 약 4%로 낮아졌으며, image token보다 4–13배 큰 register vector norm이 관찰됐습니다. 댓글은 timestep 선택과 latent dimension 측정이 연구에 직접 유용하다고 평가했습니다.
Flow-matching loss가 줄어드는 것만으로 생성 품질을 판단하기 어렵고, held-out FID·FD-DINOv2·객체 정확도는 별도로 확인해야 합니다. 게시자의 측정에서는 품질 지표가 개선됐지만 loss는 고 noise 속도 목표의 불가역적 분산을 포함해 거의 같은 수준으로 움직였습니다.
20단계에서 timestep shift 2.8은 FID 27.0, no-shift는 FID 27.3과 FD-DINOv2 228을 기록했고, 50단계는 FID 26.6, 8단계는 28.4였습니다. 다음 단계의 Flow-GRPO 보상으로 PickScore/HPSv2, detector 기반 객체 보상, 검증 가능한 counting 중 무엇을 택할지는 댓글에서 해결되지 않았습니다.
- Flow-matching loss만으로 생성 품질을 판단하기 어렵고 FID·FD-DINOv2·객체 정확도 같은 별도 지표가 필요합니다.
- timestep shift와 latent 설정이 생성 단계의 품질에 영향을 줄 수 있다는 측정이 공유됐습니다.
- 다음 Flow-GRPO 단계에서 선호도 점수, detector 기반 보상, counting 기반 검증 중 어떤 보상을 우선할지는 정해지지 않았습니다.
- Wow, your write-up was awesome! Thank you for that. Legit, the stuff about timestep choices and latent dims are directly relevant to my research. I hope to see more posts like this in the future :)
- congrats, this is too good for reddit! Thanks for the release and writeup What other communities exist for scientists? On X/Bsky there's too many bots and similar silence and concentration of eyes on very few profiles. Amplified Gauss Curve
- Kind of things I'd like to do but never motivated enough when working alone 😅 Thanks for the write-up! I'm currently gathering all tricks and tips I find in every paper/blogs I see so I can know what are all options for each part of the process. The goal would be to have chapters for each "concepts" which would describe pro/cons. For example Attention - Self-attention - Cross-attention - Causal attention - Linear Attention - Softmax attention - Sliding Window (local attention) - Global attention - FlashAttention - Multi-Head Attention (MHA) - Multi-Query Attention (MQA) - Grouped-Query Attention (GQA) - Multi-Head Latent Attention (MLA) - Interleaved Head Attention (IHA) - Radix attention - Kda - kimi Etc.. I'm wondering how you organize your knowledge? There is so much being released nowadays I wanted to work on a knowledge base to organize all concepts and would summarize them for me to be able to quickly understand them when I need them. Because I don't find the time to dive in all papers.
- If you found the HF article useful, an upvote there would be much appreciated: https://huggingface.co/blog/ivanmikhnenkov/tinydit-text-to-image-from-scratch-one-gpu
- added here: [https://github.com/andysingal/CV\_public/tree/main/DiT](https://github.com/andysingal/CV_public/tree/main/DiT)
r/mlops글 1건
모든 AI 에이전트를 deny-all 네트워크 샌드박스에서 시작하는 AgentZ ↗
AgentZ는 에이전트를 처음부터 네트워크 전면 차단 샌드박스에 넣고, 관리자가 허용 규칙을 추가한 뒤에만 외부 연결을 허용합니다. 실제 API 키와 데이터베이스 비밀번호는 에이전트에 전달하지 않고 프록시가 호출 시점에 비밀을 치환하며, 재사용 가능한 샌드박스 템플릿으로 여러 workspace에 정책을 배포합니다.
deny-all을 기본값으로 두면 에이전트가 실수로 외부 네트워크에 연결하거나 비밀을 유출할 경로를 먼저 차단한 뒤 필요한 권한만 열 수 있습니다. 댓글은 API 전용 컨테이너에서 키 유출을 줄이려면 이 방식이 적합하다고 평가했습니다.
프록시가 호출 시점에 실제 자격 증명을 주입하고 에이전트에는 placeholder만 노출하면, 실행 컨텍스트에 장기 비밀을 보관하지 않아도 됩니다. 재사용 가능한 샌드박스 템플릿은 여러 workspace의 정책을 한 번에 갱신하는 운영 이점을 제공합니다.
- 에이전트 네트워크 접근을 전면 차단으로 시작하고 필요한 연결만 허용하는 방식이 안전한 기본값으로 평가됐습니다.
- 에이전트에 실제 API 키를 직접 보관하지 않는 구조가 긍정적으로 받아들여졌습니다.
- **AI usage disclosure** Hi u/Federal_Ad7921 — 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.*
- i set up something similar with a few api-only containers last year, deny-all by default is the only way that makes sense once you see how easy it is to accidentally leak a key the reusable sandbox templates are a nice touch, updating one thing and having it roll out everywhere saves a ton of headache when you're juggling a dozen workspaces
용어 해설
- 하드 요구사항(Hard Requirement)
- — 런타임이나 작업이 반드시 충족해야 하는 최소 조건입니다. 후보가 조건을 만족하지 못하면 선호도 점수와 무관하게 거부하고, 부족한 항목과 정도를 반환해 후속 처리를 가능하게 합니다.
- 섀도 트래픽(Shadow Traffic)
- — 새 버전의 시스템을 실제 요청 일부에 병렬 연결하되 사용자에게 결과를 반영하지 않는 검증 방식입니다. 기존 버전과 결정률이나 도구 호출 차이를 비교해 운영 환경의 행동 변화를 확인합니다.
- 사용자 정의 VJP(custom_vjp)
- — 자동 미분 과정에서 역전파 계산을 직접 지정하는 JAX 기능입니다. 해당 구현에서는 순전파 잔차를 저장해 역전파 때 재계산을 피하면서 TPU 학습 커널의 처리 시간을 줄이는 데 사용됩니다.
- 플로 매칭(Flow Matching)
- — 확산 계열 생성 모델이 시간에 따른 속도장을 학습하도록 만드는 훈련 방식입니다. 게시글에서는 훈련 손실이 낮아지는 정도와 생성 품질 지표인 FID·FD-DINOv2가 반드시 같은 방향으로 움직이지 않았습니다.
- 전면 차단 샌드박스(Deny-All Sandbox)
- — 에이전트 실행을 시작할 때 네트워크와 자격 증명 접근을 모두 차단하고, 관리자가 허용 규칙을 추가한 뒤에만 외부 호출을 허용하는 격리 방식입니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
