TL;DR
이번 상위 스레드에서는 에이전트와 모델을 실제 시스템에 연결할 때 권한 경계, 실행 재현성, 장애 복구 가능성이 핵심 쟁점으로 모였습니다. Curie 스레드는 SSD·RAM·GPU를 하나의 메모리 계층으로 다루는 17B 모델의 구조적 가능성과 1,100만 training tokens만으로는 품질을 판단하기 어렵다는 한계를 함께 드러냈습니다. 권한 관련 댓글은 middleware 앞단 검사만으로는 부족하며 실제 함수 내부 검증, 프로세스 격리, downscoped 권한이 필요하다는 데 가까이 모였습니다. Computer Vision과 RAG 스레드에서는 카드 인식에 segmentation·homography·embedding·KNN을 잇는 처리 흐름과 표 헤더·값 관계를 보존하는 평가 단위가 실질적인 해결책으로 제시됐습니다.
Reddit 서브레딧별 토론
r/computervision글 3건
금요일 컴퓨터 비전 프로젝트 ↗
댓글은 영상이나 프로젝트의 구체적인 정보가 부족하다는 반응과 함께 차선 검출에 사용한 모델을 물었습니다. 한 댓글은 화면에서 자동차가 제대로 검출되지 않는 상황을 가볍게 지적했습니다.
프로젝트 세부 정보와 차선 검출 모델이 공개되지 않아 기술적 평가보다 추가 정보 요청이 중심이었습니다.
- Any information?
- Trippy game
- Which model you are using for the lane detection?
- seeing everything but cars xD
포켓몬 카드 식별 알고리즘 제작 도움 ↗
OCR은 촬영 거리가 멀어지면 품질이 크게 떨어졌고, 댓글은 카드 영역을 segmentation으로 찾아 bounding box를 얻은 뒤 homography로 평면화하고 embedding 또는 feature extraction 후 KNN으로 식별하는 흐름을 제안했습니다. 작성자는 여러 조정에도 개선 폭이 작아 어려움을 겪고 있다고 덧붙였습니다.
문자 인식만 고집하기보다 카드 검출, 원근 보정, 특징 벡터 추출, 최근접 이웃 분류를 순서대로 연결해야 한다는 접근입니다.
현재 구현의 개선 폭이 작다는 호소는 있었지만, 추가적인 구체적 대안이나 성능 수치는 댓글에 충분히 나오지 않았습니다.
- OCR만으로는 촬영 거리가 멀어질 때 카드 식별 품질을 유지하기 어렵다는 점
- Segmentation to get the bounding boxes of the cards. Homogeneous mapping to map the card plane to a flat plane. Then some sort of embedding or feature extraction. Then do a knn at inference
- Hey guys, quick update: I've done lots of tweaking to the flow and I have only seen minor improvements, I have seen other people get this to work I just don't know how. Really feeling like giving up if anyone has a hail Mary feel free to throw it out there
Computer Vision용 합성 데이터셋 생성기 ↗
syntheticAIdata는 3D 모델과 객체를 선택하고 환경·카메라 각도·배경·방해 요소를 바꿔 라벨 이미지와 annotation을 자동 생성하며, 결과를 Edge Impulse로 보낼 수 있다고 소개됐습니다. 댓글은 경쟁력의 핵심이 범용 자산을 늘리는 데 있지 않고 고객이 직접 촬영한 객체와 환경을 입력해 맞춤형 샘플을 만드는 데 있다고 봤고, 홈페이지의 Surface 오탈자도 지적했습니다.
환경 변화와 자동 annotation을 이용한 합성 데이터 생성은 실제 촬영·라벨링이 어려운 조건의 학습 샘플을 마련하는 데 유용하다는 반응입니다.
기성 자산만 늘리면 창고 상자나 거리 보행자처럼 이미 흔한 데이터와 차별화되지 않으므로 고객 객체·환경의 사진을 바탕으로 합성해야 한다는 비판입니다.
- 범용 3D 자산 확장과 고객별 객체·환경 생성 중 어느 방향이 제품 차별화에 더 중요한지
- I think for this to really standout from the competitors it needs to be able to take photos of objects and environments from a customer of their own objects and automatically generate more synthetic example of those objects in those environments. Because it’s unrealistic they you’re going to pre-populated enough assets before getting customers. Like nobody needs another dataset of boxes in a warehouse or people walking around a street lol
- Also you misspelled Surfaces on your homepage
r/deeplearning글 1건
Federated Continual Class Incremental Learning 결과 재현 실패 ↗
본문과 댓글에 실험 결과나 재현 실패 원인에 관한 구체적인 정보가 없었습니다.
r/LLMDevs글 3건
일반 하드웨어의 SSD에서 실행되는 17B Curie 모델 ↗
Curie는 SSD·RAM·GPU를 하나의 메모리 계층으로 취급하고, 가중치를 SSD에 두면서 실행 경로에 따라 읽는 17B alpha 모델입니다. 작성자는 GPU 없는 노트북에서 C로 처음부터 학습했고 단일 CPU 코어에서 33 tokens/s를 기록했지만, 학습 토큰이 1,100만 개뿐이라 아직 언어 모델 품질을 판단할 수 없다고 밝혔습니다.
SSD와 RAM을 모델 실행에 직접 편입한 구조는 VRAM에 모든 가중치를 넣어야 한다는 전제를 바꾸며, 단일 CPU 코어에서 33 tokens/s를 낸 점이 구조 검증으로 의미 있다는 반응입니다.
1,100만 training tokens는 17B 모델의 품질을 학습·평가하기에 부족하고, 모델이 유용한 언어 능력을 갖췄다고 보기 어렵다는 비판입니다.
일부 댓글은 SSD 쓰기량에 따른 수명 문제, expert sparsity와의 관계, 공개·오픈소스 일정 등 구현 세부사항을 추가로 물었습니다.
- Curie의 현재 결과는 완성된 언어 모델 성능보다 SSD 중심 architecture를 시험한 alpha 단계라는 점
- 공개와 추가 benchmark가 있어야 구조와 품질을 더 판단할 수 있다는 점
- 1,100만 tokens로 얻은 17B 모델의 학습 상태를 어느 수준의 결과로 볼 수 있는지
- That's honestly an amazing demo considering the amount of people who would wildly assume that what you did is impossible.
- 1) This is cool and I think it really democratizes ai. 2) this might be a dumb question but how is it a 17b parameter model if it only has 11m training tokens?
- Awesome work, keep it up! Let us know once you’re ready to make it public.
- please keep us updated this would be awesome
- Looks like you’re training the model to have more predictable expert sparsity? “Topology aware training”?
- This looks super cool. I am doing similar work, but a model re-compiler -> executable runtime. You up to potentially trade notes?
- ever heard the tale of the man that figured out how to make a car run on water?
- I'm assuming the writing to memory is done on VRAM while most of the reading come off from SSD? I'm asking this because I'm not really thrilled with the idea of AI engine doing a lot of writing on SSD, which eats away its lifespan.
- You are not going to be training ANY coherent 17B model from scratch. You are saying you trained it from scratch on a laptop without a GPU. From the video you probably overfitted it on agentic traces. 11 million is fully not enough, for a way smaller model you need billions of tokens to reach the minimum (Chinchilla scaling laws), you made a training script, ran it overnight, 12 hours later it only trained on 0.0001% of the required token count. 17B is USELESS, you might as-well have done 50M and it would have been way better. It will never become smart unless you throw H200s at it and train it MINIMUM to chinchilla. I dont even know if you know how training works, you probably pretrained it to instruct samples right away
- You should open source it. I would love to train this. Maybe we can figure out how to make pretrained models compatible.
16GB RAM에서 쓸 만한 소형 로컬 코딩 모델 ↗
댓글은 16GB RAM 환경에서 Qwen2.5-Coder-14B를 Q4_K_M과 llama.cpp로 실행하면 약 9GB를 차지해 context와 terminal 공간을 남길 수 있다는 경험을 공유했습니다. 4B~8B 구간에서는 DeepSeek-Coder-V2-Lite-Instruct 8B의 반복 억제와 tool calling 형식이 낫다는 평가가 있었고, 다른 댓글은 Qwen 3.6 35B A3B·Qwen 3.8 27B·ornith1.5 9B를 추천했습니다.
모델 크기만 줄이기보다 RAM 사용량, quantization, runtime, terminal 여유 공간을 함께 보며 Qwen2.5-Coder-14B 또는 DeepSeek-Coder-V2-Lite-Instruct 8B를 선택하자는 접근입니다.
Qwen 3.8 27B와 Qwen 3.6 35B A3B가 더 높은 품질 후보로 언급됐지만, 16GB 환경에서 실제 실행 가능성은 댓글마다 달랐습니다.
- 16GB RAM에서 코드 품질·tool calling·응답 속도를 모두 만족하는 최적 모델
- same as I use now with over 64Gb - Qwen 3.6 35B A3B
- 3.8 27B by FAR the best
- For 16GB total system RAM I'd run Qwen2.5-Coder-14B at Q4\_K\_M with llama.cpp. Sits around 9GB, leaves breathing room for context and your terminal. It's the closest thing to the 32B's little sibling in terms of actually understanding what you want it to do, not just spitting out syntax. In the 4B-8B range I've had surprising mileage with DeepSeek-Coder-V2-Lite-Instruct at 8B. Doesn't loop on itself nearly as much as the Qwen 7B coder, and its tool calling format is cleaner out of the box. The 4B models all feel like interns who skimmed the docs once, though if you must go that small, Qwen2.5-Coder-4B is less broken than the rest.
- qwen
- I really like ornith1.5 9B model.
- You can use Daihive(.eu) network. It’s still in early beta, but if you have a friend or two, you can share a model between your computers to write code in open code.
- Do a search, there are dozens of posts answering this same question.
- Install this tool : https://github.com/adityaarakeri/llmscan Run: llmscan scan
단일 노드 멀티 모델 serving의 유휴 메모리 관리 ↗
Qwen3.8-27B, Nemotron, Chatterbox, Unlimited-OCR를 동시에 올리자 유휴 GPU 메모리 약 122GB가 예약됐고, Rust daemon이 idle 모델의 동적 할당을 비우면서 프로세스는 유지했습니다. 제시된 표에서는 총 79.4GB를 회수하고 wakeup latency를 200ms 미만으로 유지했지만, 댓글은 두 모델이 동시에 깨어날 때의 지연과 메모리 처리 방식을 물었습니다.
순차적 agent workload에서 서로 동시에 필요하지 않은 모델을 sleep 상태로 전환하면 cold start 없이 유휴 메모리를 회수할 수 있으며, 기존의 2~3초 재로드보다 200ms 미만 wakeup이 실용적이라는 반응입니다.
현재 수치는 모델 하나씩 깨우는 경우일 수 있으므로 두 모델이 같은 요청에서 동시에 활성화될 때의 메모리 경쟁과 지연을 추가로 측정해야 한다는 질문이 나왔습니다.
- 음성·비전 모델과 LLM이 모든 순간 동시에 필요하지 않은 agent loop에서는 정적 메모리 예약이 낭비가 될 수 있다는 점
- 프로세스 상주와 동적 버퍼 해제를 결합하면 완전한 container cold start보다 빠른 복구가 가능하다는 점
- 두 개 이상의 evicted model이 동시에 깨어날 때도 sub-200ms가 유지되는지
- damn that's a lot of memory saved just by putting models to sleep when they not needed i tried something similar but with python scripts that just unload models from vram on idle, the wakeup was like 2-3 seconds though so kinda useless for interactive stuff. 200ms is impressive, how do you preserve the process without keeping the allocated buffers?
- The mutual exclusivity point is the one most people miss when they copy production serving patterns onto a dev box. We hit a smaller version of this serving a 3B grounding model on serverless GPU, where the idle footprint between requests was pure waste and cold start was the tax for reclaiming it. A sleep mode that keeps process residency and still wakes in under 200ms is a nice middle. What breaks first when two models get woken by the same request?
- Is the sub-200ms warmup measured one model at a time? Curious what it looks like when two evicted models get hit in the same second.
r/LangChain글 3건
에이전트의 직접 tool 호출 우회 차단 ↗
댓글은 middleware 앞단의 permission check가 같은 프로세스에 원시 Python 함수를 import할 수 있는 경로를 남기면 보안 경계가 아니라고 봤습니다. 실제 부작용은 별도 프로세스나 HTTP·RPC 서비스 뒤에 두고, tool 본문에서 실행 직전 권한과 짧은 수명의 capability를 다시 확인하며, child agent에는 축소된 tool 목록과 권한을 전달해야 한다는 조언이 모였습니다.
권한 검사를 실제 callable 내부에 넣고 원시 함수는 에이전트 실행 범위 밖으로 분리해야 하며, 실행 시점에 approval ticket이나 signed lease를 재검증해야 한다는 입장입니다.
같은 프로세스에서 Python 실행이나 동적 import를 허용한 채 앞단 middleware만 추가하는 방식은 에이전트가 원시 함수를 호출할 수 있어 장식에 가깝다는 비판입니다.
child agent는 부모 권한을 자동 상속하는 것이 아니라 생성 시 전달한 tool과 권한을 받는다는 설명이 있었지만, 전체 toolkit을 넘기면 사실상 같은 취약점을 복제한다는 조건이 붙었습니다.
- 실제 부작용 함수가 같은 프로세스에서 import 가능하면 앞단 permission check만으로는 우회가 가능하다는 점
- 권한은 실행 시점에 다시 검증하고 child agent에는 최소 권한만 전달해야 한다는 점
- so you basically built a lock, put it on the front door, and then realized the agent can just walk around the side of the house and climb through an open window. yeah that's the whole problem in a nutshell. you're not missing something obvious, the framework kinda lets this happen by design because it's just python under the hood. the only real fix i've seen is wrapping the actual tool function itself with the guard logic so the check lives inside the callable, not in some middleware layer that can be bypassed. then you make that wrapped version the only thing you ever import anywhere, which is annoying to enforce but doable if you own the codebase. the child agent question is basically "does it get a copy of the parent's memory or just the tool list" and the answer is usually both unless you explicitly strip stuff out, which is its own headache.
- yeah your instinct is right, a check that sits "in front of" the tool in the agent loop is mostly decorative if the underlying function is still a normal importable python callable in the same process. the model doesnt have to respect your wrapper, and a subagent with code/exec or a bad tool can just call the real thing. what actually works: 1. make the privileged thing unreachable except through the tool. put the real side effect in a separate module/service the agent runtime cannot import (different process, private package, HTTP endpoint with auth the agent doesnt have). the u/tool function is then the only client, and it does the authz check inside its body right before the call. 2. child agents do not magically inherit parent access. they get whatever tools you pass when you build them. so spawn with a stripped tool list, or a tool that re-checks permissions for that childs role. if you hand the child the same toolkit as the parent, you basically cloned the hole. 3. for "verified/approved" state, check at time of use, not time of plan. store a short lived capability (approval id + expiry + exact action + resource) and have the tool revalidate that ticket when it fires. if
- If your agent runtime can import the naked function, that middleware check is just decorative wallpaper. The second you give an LLM python execution or dynamic tool routing, it won't respect your polite wrapper. It will import the raw module from `sys.modules` and run the side-effect behind your back. > An agent's self-reported "approved" status is pure narrative fiction. Storing `state["approved"] = True` inside context or graph state walks straight into a TOCTOU trap. An approval granted two nodes ago is already stale. If an async queue hiccups or the state gets rehydrated, the world has moved. Here is the mechanical reality for locking this down: **1. Treat tools as sealed capabilities, not bare imports** Pull direct library functions out of the agent's execution scope. The mutating action shouldn't be an in-process callable sitting in memory. Put the actual write behind an RPC boundary, or fuse verification directly to the function signature so it drops the hammer without an ephemeral, signed execution lease: ```python def execute_mutation(target_id: str, payload: dict, lease: SignedLease): payload_hash = sha256(json.dumps(payload, sort_keys=True)) if not lease.ver
- process isolation is the answer. if the function lives in the same process, any check is theater. tool calls that matter should cross a process boundary, then theres nothing to import
Temperature 0에서도 달라지는 코딩 에이전트 실행 ↗
같은 self-hosted Qwen과 vLLM, temperature=0으로 SWE-bench 작업을 13회 실행한 결과 12회가 같은 중간 Git diff에 도달했지만 최종 source state는 11가지로 갈렸습니다. 댓글은 continuous batching의 수치 비결정성, 병렬 tool-call 순서, 파일 목록과 timestamp 차이를 원인으로 들었고, trajectory 재현보다 테스트·type check·lint·canonical state hash를 통한 결과 검증과 checkpoint·rollback·fork-and-select가 더 중요하다고 봤습니다.
Temperature 0은 고정된 계산 그래프에서만 greedy decoding을 안정화할 뿐이며, serving-level 수치 오차와 환경 출력이 near-tie token 선택과 이후 context를 바꿀 수 있다는 설명입니다.
실행 경로와 최종 patch가 달라지는 현상을 억지로 제거하기보다, 여러 올바른 결과를 허용하는 verifier로 consequential divergence만 걸러야 한다는 입장입니다.
각 node와 tool 뒤 핵심 상태의 hash를 기록하고 공통 경로에서 처음 벗어난 지점을 bisect하면 divergence의 원인을 찾을 수 있다는 실무적 제안이 나왔습니다.
- Temperature 0만으로 전체 에이전트 실행을 결정론적으로 만들 수 없다는 점
- 실행 경로보다 테스트와 canonical state 검증을 통해 결과의 정확성을 측정해야 한다는 점
- Running open-weight agents in prod (self-hosted Qwen behind vLLM), so yes — we see this constantly, and we stopped fighting it. Two sources of temp-0 variance people underestimate: Serving-level numerical non-determinism. With continuous batching, the same prompt lands in different batches across runs; reduction order in attention/GEMM kernels changes, logits shift in the \~1e-7 range, and near-tie token choices flip. Greedy decoding is only deterministic for a fixed computation graph — a serving engine never gives you that. Non-deterministic environment outputs. Parallel tool-call ordering, unsorted directory listings, timestamps in command output. The agent's context differs even when the model is "frozen". On "does it matter": we reframed it exactly like you did — trajectory determinism is the wrong target, outcome verification is the right one. With a strong verifier (tests, type checks, lint, canonical state hash) harmless variation is just filtered out, and you start measuring pass\^k instead of pass@k. Consequential divergence shows up precisely where verification is weak — that's where we invest: checkpoints at canonical states + rollback, and fork-and-select with a veri
- Temperature 0 doesn't freeze the world the tools touch — filesystem, search order, prior artifacts — so trajectories diverge even when the model is sticky. The useful question is when they first diverge, not that the finals differ. Bisect by state: dump a hash of key fields after each node/tool; the first hop that leaves the common path is the origin. Catch empty/placeholder outputs early too — a "success" node that dropped a required key will fan out into 11 endings. I built ARGUS to flag that class of silent drift on LangGraph; same technique works with a cheap per-node callback if you just want the divergence point.
일시적인 에이전트와 지속되는 실행 상태 ↗
CellaFlow crash benchmark는 동시 재시도, claim 뒤 장애, 외부 부작용 뒤 장애, 느린 worker, 소유자 소실을 비교하며 중복 부작용 방지와 작업 진행 가능성을 함께 평가했습니다. 댓글은 checkpoint만 부작용의 진실 원천으로 삼으면 환불을 재실행할 수 있으므로, 실행 전 intent를 저장하고 외부 요청마다 idempotency key를 사용한 뒤 명시적 acknowledgment를 기록해야 한다고 보완했습니다.
Durable claim은 동시 재시도에서 부작용을 한 번으로 줄이지만 소유자가 사라지면 deadlock이 되므로 lease·heartbeat·ownership transfer·fencing을 결합해야 한다는 입장입니다.
임의의 외부 API가 트랜잭션에 참여하지 않으면 부작용 직후 프로세스가 죽었을 때 정확히 한 번 실행됐는지를 복구 시스템이 알 수 없다는 한계가 있습니다.
실행 시스템은 side effect 자체를 정확히 한 번 보장한다고 약속하기보다, idempotency key와 영속 실행 기록으로 재시도와 소유권 회복을 관리해야 한다는 방향입니다.
- 중복 방지만으로는 충분하지 않고 소유자 장애 뒤 작업이 다시 진행되는 liveness가 필요하다는 점
- 외부 API가 idempotency를 지원하면 그 키를 사용해야 한다는 점
- CellaFlow와 durable claim의 복구 동작이 동시 부작용과 다중 agent 환경에서도 동일하게 유지되는지
- The main risk in this design is making the checkpoint itself the source of truth for side effects, because that can still replay a refund after a crash. A safer pattern is to pair every external action with an idempotency key and persist the intent before execution, then treat the side effect as complete only after an explicit acknowledgment is recorded. That gives you a recoverable trail without blocking progress forever. Agentix Labs fits here as a good example of why runtime design matters more than prompt quality once an agent can touch real systems.
r/ClaudeAI글 3건
Claude 앱의 숨겨진 내부 설정 ↗
본문에는 내용이 없었고, 댓글은 외부 글 링크와 AutoModerator의 검토 안내만 남겼습니다.
- 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.*
- details: [https://nima-ahmadi.github.io/posts/claude-android-internal-settings/](https://nima-ahmadi.github.io/posts/claude-android-internal-settings/)
- Post appears to contain insufficient information or effort for this subreddit. Try adding more context, evidence, your own helpful insights and guidance and reposting . (Note: This might occur if you do not have enough introductory text in the post body.)
1주일 무료 Claude Code 추천 링크 ↗
댓글에는 AutoModerator의 검토 안내와 게시물 삭제 알림만 있었습니다.
- 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.*
- This post has been removed. Please review the subreddit rules and resubmit with any necessary details and changes. If this is related to performance or limits, please report on the relevant Discussion Hub https://www.reddit.com/r/ClaudeAI/comments/1vt5drr/list_of_latest_discussion_hubs_on_rclaudeai/. If you are showcasing your work, please read the requirements of Rule 7. If you are looking for guest passes, we don't allow that here. If you believe your post violates no rules, please message the mods via Modmail.
초지능 AI 금지 촉구와 영국 정치권 논쟁 ↗
본문은 비어 있었고, 댓글은 AutoModerator가 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.*
- This post is not sufficiently relevant to Claude/Anthropic. General interest posts belong elsewhere. If it's about a competitor, include substantiated comparisons to Claude. Please review subreddit rules. \ \ **NOTE: If you don't have enough text relevant to Claude in the body of your post, I can get confused.** I do not follow links. Repost with more detail or message the mods by Modmail if you think I screwed up.
r/AutoGPT글 2건
에이전트 간 권한 부여로 위험한 작업 차단 ↗
작성자는 단일 agent와 agent chain 전반의 위험한 작업을 막는 authorization layer를 만들었다고 알렸습니다. 유일한 댓글은 특히 cross-agent 권한 공백이 복잡한 문제가 된다는 점에서 접근을 긍정적으로 평가했습니다.
agent chain에서 서로 다른 구성 요소 사이의 권한 공백을 별도 authorization layer로 다루는 방향에 긍정적인 반응입니다.
- love how you're tackling this, cross-agent auth gaps are where things get messy real fast
CPU 하드웨어에서 Local Whisper 전사 속도 4배 향상 ↗
본문과 댓글에 기술적 내용이 없었습니다.
r/artificial글 3건
Anthropic 연구자들의 AI 멸종 위험 경고 ↗
Anthropic 연구자들의 초지능 위험 경고를 두고 댓글은 IPO와 규제 영향력을 위한 마케팅이라는 해석, 실제 불확실성을 인정해야 한다는 해석, 기업의 책임과 규제 공백을 먼저 다뤄야 한다는 해석으로 갈렸습니다. 실무 측면에서는 멸종 위험보다 CRM write access를 가진 agent의 실수와 책임 소재가 당장 관리해야 할 문제라는 관점이 제기됐고, AI 개발 중단이 경쟁법상 어려울 수 있다는 반론도 나왔습니다.
Anthropic이 IPO와 폐쇄형 생태계의 영향력을 키우기 위해 AI의 위험을 과장한다는 해석이 나왔고, 공개 발언자의 경력과 투자 배경도 의심 대상으로 거론됐습니다.
초지능 위험을 단정할 수는 없어도 아무도 미래를 모르는 상황에서 군사·생물학·malware와 결합될 위험을 무시할 수 없으며, 국제적 규제와 개발 속도 조절이 필요하다는 입장입니다.
기업 현장에서 당장 필요한 것은 멸종 확률의 합의보다 CRM write access를 가진 agent의 오류, 고객 피해, 승인 책임처럼 측정 가능한 운영 위험을 관리하는 일이라는 구분입니다.
- AI의 장기적 영향과 초지능 위험을 정확히 예측할 수 없다는 점
- 기업 현장에서는 agent 권한과 오류 책임 같은 단기 운영 위험도 별도로 관리해야 한다는 점
- Anthropic 연구자들의 경고가 진정한 안전 경고인지 투자·규제 전략인지
- AI 개발 중단이나 속도 조절이 경쟁법과 국제 경쟁 속에서 가능한지
- It’s because people are getting distracted from putting the blame on the tech CEOs. If they faced jail time and or the death penalty you’d see a significantly different AI space.
- It’s Anthropic, so it shouldn’t surprise anyone that they would be talking like this. They’re heading toward an IPO, so they have a strong incentive to convince people that they hold an unprecedented amount of power. It’s a simple and highly effective marketing strategy. They’ve already been aggressively trying to protect their closed garden, and apparently warning us about China wasn’t enough, so they’ve escalated the rhetoric even further. It has been said many times now that Dario genuinely believes AI could destroy the world, and that Anthropic should therefore either be the one controlling it or be the first to reach self-improving AI so that someone else doesn’t get there first and destroy everything.
- How is a 6 week alignment intern a "researcher" ? And why do you say he quit ? He appears to have a multi million USD funding background from the core anthropic investors - who originally invested in anthropic and now invest into regulation to protect their prime investment.
- The bottom line is that these guys have no clue what's the future of AI will bring. *Because no one does*. Will people use AI to created super viruses that leave the covid pandemic in the dust? Will we continue to add AI to our military weapons so that eventually AI can take control of our military? Will we start linking our graphics cards such that, when AI escapes from the lab, it will have a place to create persistent copies itself on computers on the internet and no longer be able to be shut down? Will the proliferation of malware become so rapid that vast swaths our of economy will fail? Will cancer be cured? Will battery technology advance so quickly that we can abandon fossil fuels decades earlier than expected? Will all of our jobs be replaced or will there be more jobs than ever and everything becomes super cheap? No one knows, but we are going to find out because there is no way the companies are going to stop. Even if we could stop them in the U.S., then they would race ahead in China and elsewhere. This isn't like nuclear weapons where you can have treaties and monitoring, because, let's say a country pledges to stop AI development, there is no way to be sur
- There's something very astroturfed about this recent discussion and I don't quite understand the angle besides dividing users into the haves-have nots. There'd be 5 million red flags prior to that becoming a real threat that are all easily avoidable. If you have sophisticated humanoid robots, don't give them cellular/satellite receivers. Don't give them access to manufacturing processes, weaponry or ammunition. Maintain kill switches at data centers. This is all so fake and tiresome.
- Start the conversation. Work with China to establish an independent regulatory body to slow down AI development for alignment.
- Capitalism is all gas no brakes until there's a catastrophe, then a period of externalizing losses and allowing limited temporary regulation. This formula may not play out very well this time however.
- OpenAI has been asking people in Congress whether an industry-wide slowdown would even be legal, per WIRED. Competitors agreeing to restrict output is Sherman Act territory, so it isn't a stupid question. There's already a bill for it. A bipartisan one went in back in July that would carve safety coordination out of antitrust, and it's been sitting in House Judiciary ever since without a hearing. So the honest answer to why nobody just pauses is that the obvious version of a pause might be illegal. I think that's a harder blocker than whether any of them mean what they say. Whether the bill ever moves, I don't know. Has anyone here seen it get picked up?
- After reading only the first paragraph, I immediately thought it was all marketing fluff. Since I work with neural networks every day, study new algorithms and technologies, train LoRA, program, write texts, generate images, and do many other things with modern models, I see and understand their capabilities well enough. Self-learning AI, at this point, is just a tall tale for investors; it's impossible for quite prosaic and banal reasons - current hardware technologies simply don't allow it. Not to mention that it's fundamentally unimplementable on transformer technology alone. So there's not even a minimal hardware or software foundation for it.
- I’d argue if we built an infrastructure so dumb that ai agents can kill is we deserve what we get
128KB RAM과 플로피 디스크 시대의 James Cameron ↗
댓글은 James Cameron의 미래 예측을 독창적 통찰로 볼지, 기존 SF 작품을 영화화한 결과로 볼지 갈렸습니다. 일부는 Terminator의 인간 디스토피아를 AI의 실제 위험 근거로 쓰는 방식에 회의적이었고, 다른 댓글은 영화의 시각적 영향력이 예측의 필연성처럼 받아들여졌다고 봤습니다.
Cameron이 당시의 제한된 컴퓨팅 환경에서도 AI와 인간의 충돌을 상상했다는 점을 미래를 내다본 사례로 보는 반응입니다.
Terminator의 핵심 발상은 기존 SF와 Frankenstein식 인간 디스토피아에 기대고 있어 Cameron만의 예측으로 보기 어렵다는 반론입니다.
영화의 서사와 실제 AI 위험을 직접 연결하는 것은 인간 사회의 디스토피아를 AI 행동의 증거로 오용할 수 있다는 지적입니다.
- Terminator를 독창적인 AI 예측으로 볼지 기존 SF 전통의 재구성으로 볼지
- What a visionary...who was familiar with previous sci-fi novels.
- Its a made up story.
- We keep using human dystopias as evidence for what AI will do to us.
- when you would have watched Terminator like a nerd you would know that they dont have forseen something. According to the story the attack on humas begun initally in 1997
- terminator is basically frankenstein with better special effects. the vision wasn't cameron's, he just had the budget to make it feel inevitable rather than theoretical
- Some people’s lives are so boring that they just want to see the world burn.
- Humanity under capitalism was always going to end with a destroyed planet and billions of dead, this is just one timeline.
가중치 없는 Human Engineered Intelligence ↗
작성자는 7,642줄의 Rust와 75개 architectural structures로 구성된 로컬 시스템을 만들었으며, 학습 corpus·model weights·network call 없이 dictionary에서 읽은 내용을 Point-String-Graph와 37개 authority pipeline으로 처리한다고 설명했습니다. 댓글은 내부 용어보다 실제 입력·출력과 GitHub 공개를 요구했고, 설계가 인간 뇌를 모방한 것인지 기능 요구사항에서 출발한 것인지 물었습니다.
가중치와 black box 없이 지식 구조, 주야간 revision, contradiction 처리, 파일 단위 상태 복원을 직접 설계한 점에 관심을 보이며 사용 가능한 공개를 요청했습니다.
내부 명칭과 구조 수치가 많지만 실제 입력·출력 사례가 없어 시스템의 능력과 유용성을 판단하기 어렵다는 비판입니다.
프로젝트의 고수준 functional requirements와 인간 뇌 모방 여부가 공개돼야 architecture의 설계 근거를 평가할 수 있다는 질문입니다.
- 실제 입력·출력 예시와 공개 저장소가 있어야 기술 주장을 검증할 수 있다는 점
- 가중치 없는 상징적·구조적 시스템이 실제 AI 모델과 어떤 역할 차이를 갖는지
- Stop the slop!
- Some example inputs and outputs would be more demonstrative rather than the insider lingo.
- Modeled on human brain component processes, or just invented from scratch? If the latter, what were the high-level functional requirements for the architecture? Thanks.
- Github repo?
- Can we try it out?
- But why? Because you hate AI?
- https://preview.redd.it/f3blkfcybxoh1.jpeg?width=1080&format=pjpg&auto=webp&s=8b9bf1fdac67f2c77504de8f2643d0b18d5b13d0
- Come check AetherHI out r/WyndInnovation
r/LanguageTechnology글 1건
표 문서의 Chunking 전략 비교 방법 ↗
고정 800 token chunk가 표의 헤더와 값을 분리해 orphaned number를 만들고, reranker가 잘못된 분기의 값을 올리는 문제가 제기됐습니다. 댓글은 최종 답변 groundedness만 보지 말고 검색된 문맥에 헤더와 값이 함께 있는지 별도 점수화하며, 표를 Markdown으로 파싱한 뒤 헤더를 각 행에 붙이고 parent table을 반환하는 방식과 gold cell lookup의 exact match를 권했습니다.
검색된 문맥이 올바른 표와 행을 포함했는지, LLM 답변이 그 문맥을 정확히 사용했는지를 분리 평가해야 한다는 입장입니다.
원시 800 token slice를 평가 단계에서만 보정하는 것은 한계가 있으므로, 표를 prose처럼 chunk하지 않고 구조화해 ingestion해야 한다는 비판입니다.
Braintrust나 Langfuse로 실험을 나란히 비교할 수 있지만, 먼저 헤더와 값의 동시 검색 여부와 표 ID 보존을 평가 기준으로 정의해야 한다는 조언입니다.
- 최종 답변 점수만으로는 헤더·값 분리와 같은 검색 실패를 포착하기 어렵다는 점
- 표의 구조와 시간 문맥을 보존하는 ingestion 및 평가 단위가 필요하다는 점
- query expansion이 산문 검색에는 도움이 되더라도 표 중심 질의에서는 끄는 편이 나은지
- I would separate this into two checks, did retrieval bring back the right table context and did the answer use it correctly? If you only score the final answer, you’ll miss a lot of chunking failures. Braintrust or Langfuse can help with the side by side runs but I’d define the table metric first.
- Have you tried scoring whether the header and value land in the same retrieved context? That seems more useful than only checking whether the final answer was grounded.
- Recall at k is not enough here. You can retrieve the right document and still lose the row header relationship.
- If query expansion is retrieving orphaned numbers, I’d test expansion off for table heavy questions. It may be helping prose and hurting tables
- Honestly you are fighting the wrong battle at the evaluation layer if you feed raw 800 token slices into your index. We burned weeks on this exact problem until we stopped chunking tables as prose. If a parser like Docling or LlamaParse converts tables to markdown, your parent child retrieval can index individual rows with the table header prepended to every single row, while returning the entire parent table or surrounding section to the llm context. That completely stops the reranker from hallucinating Q2 numbers for Q3 queries because the temporal context never gets severed from the cell For Braintrust don’t bother with manual span matching across arbitrary chunk boundaries. Just write a synthetic eval dataset of fifty gold cell lookup questions with expected json key value pairs, then run an exact match assertion on whether the retrieved parent metadata contains that specific table id before the llm even answers. You will see which ingestion strategy wins in about an hour
- Why does this thread feel infested with ai bots...
r/MachineLearning글 1건
Radar point cloud 분류의 혼입 변수 처리 ↗
자동차 radar point cloud 분류에서 range를 feature로 넣자 모든 K-fold와 최종 test의 F1이 올랐지만, 모델이 실제 class distribution 대신 거리와 반사 특성을 학습하는지 우려가 제기됐습니다. 댓글은 range별 F1을 보고 range holdout 또는 permutation으로 성능 증가가 유지되는지 확인하라고 했고, 다른 댓글은 RCS와 물체 크기의 상관 때문에 해당 신호가 실제 물리적 분류 단서일 수 있다고 덧붙였습니다.
Radar의 RCS가 거리와 물체 크기에 연결되므로 range가 분류에 유효한 실제 신호일 수 있다는 입장입니다.
학습·배포 환경의 range 분포가 다르면 range가 환경 편향으로 작동할 수 있으므로, 거리 구간별 F1과 range 제거·순열 검증 없이 feature를 신뢰하기 어렵다는 입장입니다.
- range별 성능과 분포 변화에 대한 별도 stress test가 필요하다는 점
- range가 물리적으로 타당한 분류 신호인지 환경 편향인지
- For a given radar, maximum detection distance is very dependent on the RCS, line the forth root. RCS for many real world objects is highly correlated with its size. So your model is probably learning it right
- yeah bin the test set by range and report F1 per bin, then hold range out or permute it and see if the gain sticks. if train and deploy have different range mixes only keep the feature after that check.
r/mlops글 1건
권한 검사를 통과한 뒤 에이전트의 직접 tool 호출 차단 ↗
댓글은 원시 함수가 import 가능하면 앞단 검사가 보안 경계가 아니며, sandbox에서 직접 접근을 차단하거나 함수 내부에 검사를 넣어야 한다고 했습니다. 표준 tool calling에서는 backend orchestrator가 JSON 의도를 해석해 호출하지만 bash나 Python shell을 주면 경계가 사라지므로, 외부 RPC·HTTP endpoint와 downscoped ephemeral JWT, DB transaction 내부의 원자적 권한 검증이 필요하다는 조언이 나왔습니다.
실제 도구를 외부 RPC·HTTP 서비스로 분리하고, child agent에는 특정 scope만 담은 짧은 수명의 JWT를 발급하며, 최종 tool 실행 시 DB에서 권한을 원자적으로 확인해야 한다는 입장입니다.
bash나 interactive Python을 같은 sandbox에 주면서 원시 함수를 import할 수 있게 두면 permission check는 우회 가능하므로 실질적인 경계가 아니라는 비판입니다.
일반 JSON tool calling과 임의 코드 실행은 위협 모델이 다르며, 전자는 orchestrator가 호출을 통제하지만 후자는 프로세스·서비스 격리가 필요하다는 구분입니다.
- 원시 함수와 임의 코드 실행 경로를 에이전트와 같은 프로세스에 두면 앞단 검사만으로는 부족하다는 점
- 최소 권한, 외부 서비스 경계, 실행 시점의 원자적 검증이 필요하다는 점
- the check is just one path, and if the raw function's still importable you've just got a polite suggestion not a security boundary. you'd need to actually sandbox the execution so the agent literally can't reach the function directly, or put the check inside the function itself so it's impossible to bypass.
- **AI usage disclosure** Hi u/Real_KingZeotic — 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.*
- Well... You have permissions on the bash tool (or better yet don't have one) to keep them from running arbitrary code right? Agents can only interact with the world with the tools given. If you give it a tool to let it bypass permissions, then it's just a matter of time before it does.
- You might be mixing up two different execution models here If your agent is doing standard tool calling, the model never touches your Python runtime directly, it just returns a json payload with an intent, and your backend orchestrator parses that and decides what to invoke. The isolation breaks the second you give the agent an arbitrary code execution sandbox like a bash tool or an interactive Python shell. If the target functions live inside that same sandbox, you basically have zero perimeter. The sane way people run this in prod is keeping tools as external rpc or http endpoints behind an api gateway, completely outside the execution container For sub-agents, treat them like untrusted microservices by minting downscoped ephemeral jwts with specific scopes rather than inheriting full ambient authority. That also kills the stale state problem, since the tool itself verifies permissions and locks the resource atomically right inside the db transaction when the payload arrives, instead of relying on a vibe check upstream
용어 해설
- 메모리 계층(Memory Hierarchy)
- — SSD·RAM·GPU를 하나의 계층으로 보고, 모델 가중치와 실행 데이터를 실행 경로에 맞춰 서로 다른 저장장치 사이에서 이동시키는 구조입니다. 모든 가중치를 VRAM에 올리지 않아도 되는 것이 핵심입니다.
- 프로세스 격리(Process Isolation)
- — 에이전트가 실행되는 프로세스와 실제 부작용을 일으키는 함수를 분리하는 방식입니다. 별도 프로세스나 RPC 경계를 두면 에이전트가 원시 함수를 직접 import해 권한 검사를 우회하기 어려워집니다.
- 멱등성 키(Idempotency Key)
- — 외부 결제나 환불 요청에 고유 식별자를 붙여 동일한 작업이 재시도돼도 부작용을 한 번만 처리하도록 돕는 값입니다. 프로세스 장애 뒤 요청 결과가 기록되지 않은 상황에서 중복 실행을 줄이는 데 쓰입니다.
- Temperature 0
- — 토큰 선택의 무작위성을 낮추는 생성 설정입니다. 그러나 연속 배칭의 수치 연산 순서와 파일 시스템·도구 출력이 달라지면 같은 프롬프트에서도 에이전트 실행 경로가 달라질 수 있습니다.
- Parent-Child Retrieval
- — 작은 자식 단위로 검색하면서 더 큰 부모 문맥을 함께 반환하는 검색 방식입니다. 표의 각 행에 헤더를 덧붙이고 전체 표나 주변 절을 LLM 문맥에 넣으면 셀 값과 열·기간 관계가 끊기는 문제를 줄일 수 있습니다.
- Durable Claim
- — 작업 소유권을 영속 저장해 동시 재시도를 막는 실행 제어 방식입니다. 다만 소유자가 장애로 사라지면 작업이 영구 대기할 수 있어 lease·heartbeat·소유권 이전·fencing이 함께 필요합니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
