검색 색인 교체부터 AI 실행 검증까지, 자동화의 경계와 실패 신호

현재 AI 경쟁 상황 ↗

본문은 “lol” 한 단어에 그쳤고, 댓글도 AutoModerator와 서브레딧 봇의 자동 안내뿐입니다. 추가 맥락이나 근거가 부족해 실질적인 찬반 주장과 합의점을 확인할 수 없습니다.

• u/AutoModerator ▲1Your 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.*
• u/ClaudeAI-mod-bot ▲1Post 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.)

완전히 끝난 상태 ↗

본문과 댓글 모두 실질적인 내용이 없으며, AutoModerator의 게시물 검토 안내만 남아 있습니다. 스레드에서 논점을 추출할 근거가 없습니다.

• u/AutoModerator ▲1Your 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.*

Embedding 모델을 무중단으로 교체하는 방법 ↗

embedflow는 기존 Embedding 색인에서 K개 문서를 가져와 새 모델로 재순위화함으로써 전체 벡터 재생성을 건너뛰는 방식입니다. 댓글에서는 10억 문서 처리에 약 108일이 걸릴 수 있다는 문제의식과 접근법의 단순성에는 호응이 있었지만, K를 어떻게 정하고 50만~100만 문서보다 훨씬 큰 데이터셋에서도 품질이 유지되는지는 아직 검증이 필요하다는 의견이 나왔습니다.

• u/Novel_Maize7934 ▲3oh this is clever. skipping the full reindex and just reranking top-k from the old model's results is such an obvious-in-hindsight move, surprised more people aren't already doing this the 108 days figure on 1B docs is wild, even at 50M it's still days of downtime most places can't afford. curious how you're determining K though, is there a heuristic or is it just trial and error per model pair been burned by embedding upgrades before, had to explain to the team why search quality tanked for a week while we rebuilt everything. might give this a spin on our qdrant setup and see if it holds up on our weird legal docs
• u/leschnoid ▲1Quite an interesting approach. How is retrieval quality Across large document sets though ? The 50 you said you tested are tiny compared to the problem it’s build to solve…

다른 개발자가 전체 앱을 읽지 않아도 노드를 추가할 수 있는 그래프 상태 구조 ↗

LangGraph의 하나의 공유 TypedDict가 커지면서 새 노드가 허용된 필드와 downstream 영향까지 모두 파악해야 하는 문제가 제기됐습니다. 댓글에서는 상태를 노드가 아니라 기능별 조각으로 나누고, 노드별 읽기·쓰기 계약과 네임스페이스를 코드로 강제하면 필요한 범위만 이해해도 된다는 패턴이 제시됐습니다.

• u/locbuilds ▲1what worked for us once the graph got past \~10 nodes and a second person started touching it: stop treating state as one app-wide bag, and treat it as a few subsystem bags that get merged. concrete pattern: 1) split the TypedDict into slices by ownership, not by node. like \`RouterState\`, \`RetrievalState\`, \`HITLState\`, \`ExecutionState\`. each slice owns a small set of keys. nodes declare "i live in this slice". a new node almost never needs to read the whole schema, just its slice + maybe 1-2 shared keys (run\_id, user\_id, status). 2) enforce read/write contracts in code even though LangGraph wont. we wrap nodes so each one gets a tiny view object / pydantic model with only the fields it listed, and writes go through an updater that rejects unknown keys. CI fails if a node imports the full AppState. that sounds annoying once, then it saves every PR review. 3) namespace keys aggressively: \`retrieval.docs\`, \`hitl.pending\_action\`, \`exec.last\_error\`. flat \`docs\` / \`error\` / \`result\` names are how you get silent collisions when two subsystems invent the same field. python TypedDict can still be flat under the hood, the dots are just naming disciplin

CPU에서 1.5ms로 실행되는 오픈소스 환각 탐지기 ↗

본문과 댓글이 비어 있어 환각 탐지기의 작동 방식이나 성능을 뒷받침하는 토론 근거가 없습니다.

Embedding 모델 간 무중단 마이그레이션 ↗

embedflow는 기존 색인의 후보 문서를 새 Embedding 모델로 재순위화해 전체 backfill을 생략하는 방식입니다. 댓글에서는 추천 모델의 warm-start와 비슷한 발상이라는 긍정 평가가 있었지만, K가 충분한지 판별하는 기준과 대규모 문서셋에서의 안정성이 반복해서 질문됐습니다.

• u/Prudent-Season8041 ▲2This is clever, reminds me of how you can warm-start a new recommendation model by re-ranking from the old one's candidates. The tricky bit is always figuring out when K is "sufficient" without just brute forcing it every time. Do you have any heuristics for picking K based on the model pair or dataset size
• u/SuperChingaso5000 ▲1Really interesting solution. I don't have the hardware for this, but I still thank you for putting it up on github and sharing your insights with us.
• u/BSmithA92 ▲1How are you guys estimating your K?

도메인 간 LLM 추론을 위한 추측과 비판 그래프 ↗

35B Qwen을 고정한 wrapper가 Toulmin 구조의 근거·전제·주장·반박 그래프를 만들고, 단기 작업 기억과 지속되는 reasoning map을 분리하는 구조입니다. 댓글에서는 주장부터 세우고 반박하는 흐름과 Gods-eye-view 관찰 계층을 긍정적으로 봤지만, 실제 실행에서 반박 노드가 충분히 사용되는지는 확인이 필요하다는 의견이 나왔습니다.

• u/StarchyDefection ▲2Saw the diagram and the wrapper idea is pretty neat, the two memory split reminds me of how I try to keep my meal prep organized on Sundays, separate containers for stuff that stays good vs stuff I gotta use quick. The claim-first approach makes sense, easier to tear down a bad guess than start from nothing. Curious how much the rebuttal nodes actually get used in practice, sometimes those end up as dead weight in argument maps. Also the Gods-eye-view for a text adventure is a cool way to debug without poking at the model weights directly. Might have to give the writeup a read later when I'm not staring at a screen all day.

AI harness로 ROS 2 스택을 통해 로봇 제어하기 ↗

시뮬레이션의 harness가 느린 고수준 추론을 맡고, ROS 2의 Nav2·MoveIt 제어 루프가 20–50Hz로 실행되며, 그 사이의 L3가 동사를 실제 호출로 변환합니다. 유일한 댓글은 느린 판단 주기와 빠른 제어 루프를 나누는 구조가 적절하고 L3 추상화가 깔끔하다고 평가했습니다.

• u/Radiant_Durian_5546 ▲1always thought the slow clock high level reasoning paired with a fast control loop is the real sweet spot for this stuff, that L3 abstraction layer is a clean way to handle it

부분 관측 의사결정 문제로 보는 black-box LLM 모니터링 ↗

외부 LLM의 내부 상태를 볼 수 없으므로 프롬프트·응답·평가 점수·refusal·지연·사용자 피드백 같은 관측값으로 원인을 추정해야 한다는 문제입니다. 댓글에서는 hidden state를 세분화하고 제공자·설정 변경과 evaluator noise를 별도로 기록해야 한다는 의견이 나왔으며, POMDP는 이론적으로 맞지만 실제 팀에서는 관측 모델과 제한된 행동 공간이 더 큰 난제라는 반론도 있었습니다.

• u/BackgroundPlayful610 ▲2The framing around hidden state granularity is the part that actually matters here. I've seen too many monitoring setups where "model degraded" is treated as a single flag, and the on-call person has to manually figure out if it's a real regression or just a Tuesday afternoon traffic shift. What trips people up is how the same observation chain can look identical for completely different root causes. A spike in refusal rates could be a safety policy update, or it could be your user base suddenly asking about sensitive topics because of something in the news. The monitor can't tell the difference unless you've designed the belief state to distinguish between those. I'd push back slightly on the POMDP framing being the right level of abstraction for most teams though. The action space in practice is usually pretty constrained, page someone, roll back, gather more data, do nothing. The bigger challenge is getting the observation model right so you're not constantly waking people up for nothing. Curious how you're thinking about the evaluation side of this. Synthetic injection of known failure modes, or replaying historical incidents with the monitor's decisions compared ag
• u/AutoModerator ▲1**AI usage disclosure** Hi u/Particular-Roof4257 — 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.*
• u/Ali-WAIL ▲1The ambiguity between the observed signal and the underlying state is the part I find most interesting here. If two hidden states can produce almost the same observations but would justify different actions, how are you thinking about the decision boundary? Would you let the system act once the belief in one state becomes strong enough, or explicitly model the cost of acting on the wrong explanation and sometimes keep gathering evidence instead?
• u/IndividualTop3675 ▲1Framing this as a POMDP is intellectually satisfying and probably the right theoretical lens, but the practical challenge that will dominate your design is that the belief update step requires some prior over state transition probabilities that you almost certainly don't have access to, since provider update schedules, policy change timing, and capability regression rates are proprietary and opaque in ways that make your belief state more of a structured heuristic than a principled posterior.
• u/alexpran ▲1A quality gate on an LLM app reported a regression: one case dropped from 5/5 to 2/5. Every hypothesis on your list was checked, provider change, prompt, config, input drift. All identical. Fifteen minutes later the same case was 5/5 again with nothing touched. The true state was "the evaluator moved", and the observation was indistinguishable from "narrow capability regression" until we had a second sample. What we do now maps onto your framing more literally than I expected: * Two of your hidden causes are made observable by construction. Provider or config changes are recorded with the reference (a hash over model, temperature, prompt, tools), so a change there is read from the record, not inferred from behaviour. That removes the two easiest confounders before any belief update. * Evaluator noise is measured, not assumed. Each case is scored several times on the accepted version and the spread is stored. A new observation inside that spread updates nothing. * The "gather more evidence" action has a stopping rule: a drop beyond the spread gets re-sampled once; if it persists it's treated as real, if it vanishes it's logged as a draw and not re-run again, because re-running unt

실패 전 AI·agent 실행에서 가장 이른 신호 ↗

댓글에서는 최종 오류보다 앞서 나타나는 도구 반복, 지연 증가, 조용한 재시도를 실패 신호로 꼽았습니다. 대응으로는 임계값을 넘은 실행을 계속 복구하기보다 중단 후 새 context window에서 재시작하거나 경로를 바꾸는 방식이 선호됐고, 어떤 신호가 가장 빠른지에 대해서는 환경별 차이가 있었습니다.

• u/Initial_Passion5039 ▲2latency creep before any real failure is such a tell. had one where the agent started taking 50ms longer per tool call and everyone shrugged cause it was within thresholds. twenty minutes later it was in a doom loop calling the same endpoint on repeat with a busted payload. if i'd caught it right when the drift started i would've just killed the run and restarted with a fresh context window. those half-corrupted states are never worth salvaging.
• u/Cool-Reflection6130 ▲2tool repetition is the most likely scenario for me, it usually means the first call didn't return what it expected, and it's just stuck in a local loop before the output even looks wrong.
• u/AutoModerator ▲1**AI usage disclosure** Hi u/Ali-WAIL — 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.*
• u/Creative_Credit_5413 ▲1Retry count, not latency. In our traces a run that ends badly starts accumulating silent retries about ninety seconds before anything else moves; latency creep shows up later, and by then it's already looping. We alert on retries-per-minute crossing three and it catches roughly two-thirds of the doom loops early enough to matter. What I'd change knowing that: kill and restart, don't intervene. Half our manual interventions made it worse. We read this off Synexa's request logs; OpenTelemetry spans work the same.
• u/vint_age14 ▲1OP for me The earliest sign is usually repetition without an explicit error - the agent starts revisiting the same state or calling the same tool with slightly different inputs. At that point the run can still look completely healthy but probability of failure is already climbing. I'd rather set a loop/step threshold and reroute or stop early than burn tokens waiting for the eventually timeout.

모델 문제처럼 보였지만 실제 원인은 아니었던 실패 ↗

댓글 사례에서는 backup endpoint 전환, 제공자의 동일 모델명 아래 checkpoint 교체, stale tool 응답, 반복 호출에 따른 작은 장애 증폭이 모델 오류처럼 보였습니다. 따라서 최종 답변이 아니라 처음 잘못된 trace 지점과 실제 제공된 모델·도구 응답을 확인해야 한다는 방향이 우세했습니다.

• u/Ancient_Zombie6375 ▲2Model was returning garbled Spanish and everyone assumed it was a prompt thing, turns out the retry logic was swapping in a backup config that pointed at a completley different endpoint mid-run.
• u/AutoModerator ▲1**AI usage disclosure** Hi u/Sensitive-Parsnip-12 — 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.*
• u/Ali-WAIL ▲1One case I’ve been looking at is amplification rather than the model itself being the failure. A tool/dependency can be only mildly degraded in isolation, but the execution path keeps revisiting it. At the run level it then looks like the whole system — or even the model — has degraded badly, while most of the impact comes from repetition amplifying a smaller downstream problem. That’s made me increasingly cautious about attributing a bad run from any single trace signal.
• u/Creative_Credit_5413 ▲1Ours was a silent checkpoint swap. Output quality fell off a cliff in June and three people spent a week on prompts. The provider had swapped the served weights mid-week under the same model name. The trace looked perfect — no errors, normal latency, plausible-but-wrong answers. We only caught it with a nightly golden-set diff. Part of why we moved to Synexa is that it versions what you're actually calling. Langfuse would have caught it too if we'd been running it.
• u/Immediate_Debate_991 ▲1Tool calls are a sneaky one. We had a bad answer that looked like reasoning had gone sideways, then following the run in Braintrust showed the tool response itself was stale. Since then I try to trace the first point where the run becomes wrong instead of starting from the final output.

실패 없이 잘못된 실행을 어디서부터 디버깅할까 ↗

단일 오답 사례를 고른 뒤 정상 실행과 실패 실행의 trace를 거꾸로 비교하고, raw tool call과 모델 입력을 확인하는 접근이 가장 실용적이라는 댓글이 높은 지지를 받았습니다. 보조 의견에서는 upstream telemetry, 데이터 형식 변화, 외부 업무 상태까지 확인해야 하며 단일 사례 과적합은 피해야 한다는 지적이 나왔습니다.

• u/PassengerForward51 ▲9I usually start by picking a single concrete example of a wrong output and tracing it from the final result backward. It's boring but it works. Looking at the raw tool calls and model inputs for that one case usually shows me where the model hallucinated a plausible-looking number or skipped a step that didn't throw an error. For the tooling side I built a little utility that diffs the traces between a good run and a bad run for the same input. Not flashy but it saves me from scrolling through two logs side by side at 11pm.
• u/MaxDev0 ▲1I have a very cautious style of programming where I inspect all the variables, well all the important ones as I code, so I don't really encounter this issue, but I did when I started and that's how I developed this style, now if I ever do, I just throw in 100 print statements, read the values and close my eyes for 5 mins and I'll likely solve it
• u/bugz_bunnny ▲1When pipeline jobs complete without throwing runtime errors but generate silent discrepancies downstream, the failure usually originates in upstream process telemetry rather than model architecture. Static logging catches crashes, but it misses procedural drift and subtle data format alterations across interacting systems. In enterprise environments, pairing pipeline orchestration with continuous process discovery tools (such as Skan or Celonis) helps trace the exact sequence of cross-application user interactions and inputs, making it much easier to pinpoint the semantic break.
• u/howtorewriteaname ▲1overfit a single instance. if that doesn't work, your model can't learn. if that works, overfit 100 instances. if that doesn't work, you have a fitting problem. overfit 10k instances. if that works, then start to see if you generalize

black-box LLM 능동 모니터의 자동화 경계 ↗

ACCEPT·INVESTIGATE·REJECT의 세 상태에서 이상 징후가 있을 때 추가 probe를 실행하되, 조사 예산과 종료 조건이 없으면 결정을 영구히 미룰 수 있다는 점이 쟁점이었습니다. 댓글에서는 고정된 probe 횟수 뒤 반드시 수용 또는 거부를 선택하고, 외부 부작용은 사람에게 넘겨야 한다는 의견이 강했으며, 기준 모델과 자기 일관성을 함께 측정해 모델 변화와 noise를 분리하자는 방법도 제시됐습니다.

• u/ObsceneInterval11 ▲1The investigate state is the right instinct but it's tricky to make useful in practice. What I saw was teams ending up with basically two thresholds, one fast and noisy that sends things to investigate, and another slower one that actually triggers alerts after the probes come back the hard part is knowing when to stop investigating. You can just keep adding probes forever and never feel confident enough to call it
• u/Zain ▲1The bit that kept eating cycles for me was open-ended INVESTIGATE with no exit. I hard-cap the probe budget. After N rounds you either have a concrete blocking item you can point at, or you accept and move on. Vague unease never gets to lower the score by itself. Every drop has to map to a listed finding. An earned clean pass is as useful as catching something, and spinning more probes just to look thorough is the failure mode.
• u/Emergency-Edge-4154 ▲1i killed the investigate state in production. It sits between accept and reject so teams treat it as a place to park decisions indefinitely. i gave probes a fixed number of rounds. When the counter hits zero the system executes accept or reject based on what it has. No extensions. Budget exhaustion forces an output. I watched operators use investigate to postpone ownership. The loop ran until someone lost interest. Hard caps stop that behavior. Every score drop maps to one failure condition from a list. If the evidence links to nothing on the list, the monitor outputs accept. I deleted everything else
• u/TensionCompetitive11 ▲1I'd draw the line at anything with an external side effect. The monitor can page a human, throttle request rate, or pause the pipeline, but it shouldn't be sending messages, making purchases, or touching anything customer facing on its own judgment, because a black box monitor watching a black box model has two layers of uncertainty stacked on each other. Spending extra budget to probe when something looks off is fine and honestly underused, most people don't bother re querying with variations to see if a weird response was noise or a real shift. Where it gets interesting is behavioral drift against a baseline, since a slow drift is much easier to miss with humans in the loop than a sudden refusal spike, so that's probably where autonomous probing earns its keep the most.
• u/romanrose200 ▲1The most useful thing I can offer on "unusual versus meaningful" is that the drift signal is two signals wearing a trenchcoat, and separating them makes INVESTIGATE far more decidable. When you compare today's output against a frozen reference, a divergence can mean the model moved or it can mean the model got noisier. Those have different causes and opposite responses, and a single divergence number cannot tell them apart. So measure both: today's model against the frozen reference, and today's model against itself, several runs on the same probe inputs at your production sampling settings. Self-consistency widened, divergence from reference up: the provider changed something in serving, temperature handling, a quantised deployment, a speculative decoding change. The model is not worse in the sense of knowing less, it is less repeatable, and your downstream determinism assumptions are what actually broke. Self-consistency flat, divergence from reference up: the model genuinely moved. This is the one worth paging someone over. Both flat but a specific stratum diverging: prompt sensitivity or distribution shift on your side, not theirs. That decomposition costs y

Motion Detection만으로 차량을 탐지하는 방법 ↗

고정 카메라에서 전통적 Computer Vision만으로 차량을 찾는 방법을 두고 Background Subtraction, Optical Flow, ego-motion 보정, ROI 마스크와 blob tracking이 비교됐습니다. 단순한 정지 카메라와 희소 교통에서는 background subtraction이 가능하지만, 카메라 흔들림·겹침·조명 변화가 있으면 Optical Flow와 far-feature 기반 warp, 시간 누적 displacement가 더 적합하다는 의견이 우세했습니다.

• u/jfc123_boy ▲7I think you want something like this: [https://arxiv.org/html/2507.13628v2](https://arxiv.org/html/2507.13628v2) Basically, the idea is to compute the optical residuals that do not match the Field of Expansion. But I assume that it works best for forward motion only (such as the examples that you showed).
• u/xX_MissMiau_Xx ▲5So for your reference system it is very similar if you are stationary or moving. So starting with the case of you being stationary ist a good way to start and seperatinv the problem into two sections. Then adding your movement is just a few changes. One could use corner detection and then triangulation to get the 3D space. You then could calculate so called cluters with physical boundies by combining through cluster movement. If you now have the clusters per vehicle you can start with moving your own reference system. There are probably other (and better) ways to do it but that could be an option.
• u/Mechanical-Flatbed ▲3Since the camera is fixed, there's no need to evaluate the entire frame when you can make the code focus on just a specific region. You could draw a manual mask that excludes certain regions from where you're certain no car will ever be in. Like the sky for example. Or the upper sides of the building. You can genuinely ignore the top half of the image because there's zero chance of any cars being there. Should help with reducing false positives.
• u/Fun-Pick-2964 ▲1When camera is mounted, there is chances of jittering, and others. Best approach is to use optical flow.
• u/LeapOfMonkey ▲1Forget MOG, it is not meant for such thing, all will be moving on the screen it wont learn background. Dense or sparse but dense optical flow that is for sure, you can improve it with larger patches, descriptors etc but this will be the main thing. Next is your own ego motion, ransac+pnp should be good enough. Remove everything that matches your ego motion, the rest will be moving objects (cars or people) and some noise. Depending on density you can attach to edges (waterfall, dbscan, etc). If you want instance segmentation you need to ransac each group separately, where things will get tricky, unless you have dense and reliable optical flow. Generally the optical flow or any dense feature matching will be the weakest spot. Especially for finer segmentation, it will be difficult to get nice features in enough quantity without training ML optical flow, or using a trained one and fast enough. You can do a lot offline, if you have a lot of time for processing.
• u/RTiKh ▲1Tough task. Maybe you could share some more details on the data that you are using? Is the camera moving? Do you know the location where the video is recorded? If you have multiple passes through the same neighborhood, you would have better chance of separating the environment from the objects. Do you need to run your application live? Do you need to \_detect\_ the vehicles or label/outline them. Without knowing the details, I would go with feature detection (descriptors don't need to be rotation invariant for your task) and use some kind of bag of words to build sets of object descriptors. From those sets I would try to distinguish vehicles from everything else.
• u/Dry-Snow5154 ▲1For very simple cases (sparse traffic, clear view, no occlusions), background subtraction and blob tracking is ok. I've done it for high-rise CCTV over a highway and it worked fine. For harder cases with occlusion and noise very likely it will never work reliably. Unless you hard-code every imaginable parameter per scene (road bounds, car size, avg speed, etc). DL is there for a reason.
• u/vahokif ▲1Just out of curiosity, why do you need oldschool CV for this?
• u/simran_ai_logs ▲1Optical flow can be recommended for this
• u/Flyward_Aerospace ▲1Half the thread thinks your camera moves and you are saying it is static, which usually means a pole or mast mount that sways a few pixels. That is the worst case for background subtraction, because the apparent shift scales with depth, so the heavy machinery near you moves far more than the road behind it and no single homography fixes both. What worked for us was fitting the warp on far features only, then thresholding on net displacement over a couple of seconds instead of per frame, since machinery jitter averages out over that window and a car does not.

스크린샷 이해에 적합한 무료 오픈소스 AI 모델 ↗

댓글에서는 Qwen3.8 계열과 Gemma4 계열, Qwen·Llama를 제공하는 Groq가 후보로 언급됐지만, 실제 OCR·UI 이해·질의응답 성능을 비교한 근거는 부족합니다. 본문이 요구한 로컬 실행과 속도 조건을 충족하는 단일 모델에 대한 합의도 없습니다.

• u/beedunc ▲3Qwen3.8.
• u/fuzzysingularity ▲1Qwen3.8-27b. You can feed it full videos too, and the more fine grained the better. We have some free credits if you want to play around with a few different models: https://www.vlm.run/gateway
• u/Smartyboyz ▲1You can use Groq provider any any model such as Llama, qwen, etc.
• u/tamnvhust ▲1qwen 3.8, mage-vl
• u/lehoang318 ▲1I think Gemma4 family is a good fit

PyTorch가 AMD GPU를 인식하지 못할 때의 ROCm 수정 가이드 ↗

ROCm 설치, PyTorch ROCm wheel, 환경 변수, 검증 절차와 일반 오류를 다룬다는 게시물입니다. 댓글 작성자는 Radeon 6700 XT에서 같은 false error를 겪었고 환경 변수 순서가 원인이었다고 밝혔지만, 더 넓은 해결책 비교는 없습니다.

• u/TheAstonishingSperm ▲1man this bring back memories, spent two weeks thinking my 6700xt was broken because of that same false error. the environment variables part is what tripped me up, had them in wrong order

AI coding agent 대화와 상호작용을 분석하는 방법 ↗

본문과 댓글이 비어 있어 AI coding agent 분석 방법에 대한 근거가 없습니다.

지속적이고 재생 가능한 Rust 기반 AI agent runtime ↗

본문과 댓글이 비어 있어 runtime의 구조나 장단점을 확인할 수 없습니다.

Agentic coding이 집중 상태를 없앴는가 ↗

여러 agent를 동시에 돌리면 개발자가 깊은 실행자에서 조정자와 검토자로 바뀌어 context switching을 감수해야 하는지가 쟁점입니다. 댓글에서는 한 명의 writer와 read-only 병렬 agent, 쓰기 권한 경계, 고정된 검토 창구가 집중을 보존한다는 방법이 나왔고, agent가 실제로 실행되는 것과 계속 결정을 요구하며 방해하는 것을 구분해야 한다는 의견이 많았습니다.

• u/stupidreformer ▲5I think flow mattered a lot more when you were holding the whole system in your head. Now you're more like a dispatcher, and the agents are the ones doing the deep focus. It scratches a different itch, not the same calm immersion but you still get into a rhythm once you trust the agents to not spit out garbage every third prompt.
• u/Zain ▲1Juggling only hurts when more than one agent can write. I keep one writer and run the others read-only in parallel from different model families, neither sees the other's notes. Then I'm verifying findings against the repo instead of merging three half-done patches. That dispatcher rhythm works on the hard stuff too because you're adjudicating, not rewriting the same file three ways.
• u/WhaleDepth ▲1Me in flow state. Ding! Message in Teams: Hi It sits there for minutes, slowly eroding my flow state. I am irritated by thinking where’s the rest of the message. Multiple agents are not the problem. Not to me at least.
• u/JaseciLabs ▲1Discipline about who gets write access won't stop two agents from touching the same thing, it's going to be the codebase marking what's actually delegated and to whom at the function level. Then verifying findings against the repo stops being a memory exercise about who was doing what, the boundary's just visible in the code itself.
• u/eddzsh ▲1flow didn't die, the unit shrank. eight minutes directing, then a hard cut into deep work when the agent is stuck on something you have to feel yourself.
• u/Prudent-Ad4509 ▲1Getting into tunnel-visioned focused flow and getting out of it to check the larger picture have always been two critical counterparts. Long stretches of automated agentic coding, especially when focused on deep research and accuracy and on minimization of code changes, helps with the second part a lot. Focused flow is still good for planning, results evaluation, and course correction.
• u/Crescitaly ▲1I'd separate agents running from agents interrupting. Three independent tasks can run quietly; one agent asking for a decision every minute can destroy a review session. A useful experiment would be fixed review windows, with immediate interruptions only for genuine blockers, then compare accepted changes and rework rather than prompts sent. The constraint might be how many decisions you can evaluate carefully, not how many jobs can run in parallel.
• u/Cautious_Chicken_604 ▲1Agentic coding has no flow state. Only frustration. Constant frustration punctuated with periods of boredom.
• u/SawToothKernel ▲1Flow state only lasts for one ticket at most. I've done 4 tickets today.
• u/and_pf ▲1From my side the honest answer is driven by hardware before flow state. I run a single RTX 5090 with 32 GB VRAM serving models through Ollama, so I can't keep multiple large models loaded at once for agentic coding — the VRAM decides when a run has to pause, and I have no multi-GPU or cloud setup to fall back on. Everything I experience with agentic coding is bounded by what fits on that one card, so the break that interrupts the work is usually a hardware limit rather than the abstract flow-state question. It makes me wonder how much of the hand-wringing about flow only applies once you're past a single-GPU ceiling.

workflow 디버깅에서 단계를 배제할 만큼 강한 증거 ↗

정상 입력·도구 인자·응답·latency·schema만으로 단계를 건강하다고 판단해도 되는지가 쟁점입니다. 댓글의 다수 의견은 이런 정보가 지정된 실행만 입증할 뿐 실제 값의 정확성, downstream 전달, 외부 상태, fallback provenance까지 보장하지 않는다고 했으며, rate-limit 문구를 성공 응답으로 기록한 SDK 사례와 stale·empty 입력 사례가 근거로 나왔습니다.

• u/WarmFlow1192 ▲2The input/output matching like you listed is usually enough for me to move on, unless the failure is something subtle like a logic error that only shows up in combination with another step Had one case where the step was returning correct schema but the content was slightly off in way that only mattered three steps later, now I at least spot-check the actual values not just the structure Trace lies sometimes too, seen cases where the recorded output didn't match what downstream actually received because of some serialization bug in the middleware
• u/Initial-Cycle-4566 ▲2Your list proves the step ran correctly as specified. It does not prove it was right, and that gap is where the ones that fooled me live. Two things actually clear a step for me. First, a downstream read-back: confirm the next step consumed the same bytes, not just that this step emitted them. Schema-valid output that the next step parses differently, or silently coerces, is invisible per-step because both look green - which is exactly the serialization case WarmFlow1192 describes above. Second, an invariant asserted outside the model's own output: the booking it says it made exists in the database, the row count is what it should be. Anything that only checks the model's self-report is checking the wrong thing. The failure that looks healthiest in production is a step that succeeded against stale or empty inputs. Right shape, wrong world. A tool returns a valid empty result, the model narrates confidently around it, schema passes, latency normal, no retries. Asserting on non-emptiness and row counts catches more of those than any amount of trace inspection. Provenance earns its keep specifically if you have fallbacks. If the primary model rate-limits and you quietly fall back,
• u/Zain ▲1Schema match and a clean successful response has fooled me before. I only clear a step when something that never saw the first run can pin the claim to the actual repo or a known-good reference. Preferably a different model family, read-only. If both flag the same underlying fact, that is enough. Vague unease is not. And if a later pass finds worse problems than the previous one, the fix itself is the bug.
• u/TensionCompetitive11 ▲1No, that's not enough, and it's the mistake I see most often. Expected input, expected tool, expected arguments, and a successful response only tells you the step did what it was supposed to do given what it received, it says nothing about whether what it received or produced downstream was actually correct in context. I ran the SWE-bench harness locally at one point and found the grader counts XFAIL as a pass, and on Windows CRLF line endings silently break the eval script while the report still says the gold patch applied, so now I don't trust a green result anywhere until I've read the actual run log. To rule a step out you need to check the output against the next step's actual usage of it, not just that the step returned something plausible looking on its own.
• u/Low_Rush_8535 ▲1your first list would have ruled out the exact step that broke us. expected input, expected tool, successful response, schema-valid output, no exceptions. the sdk returned subtype=success, and the content of that "successful" response was a rate limit message. everything in the trace said healthy. the work simply hadn't happened. what changed after: we log the response body alongside the status instead of treating content as opaque, and what decides whether a step ran is terminal state in the db rather than what the step reported about itself. the other one from around the same period — usage on a six-subagent run came back as input=23, output=11236. plausible-looking fields, impossible number, and nothing flagged it because nothing asserts that a number should make sense. i don't have a general rule though. each of those got a specific check bolted on afterwards, and i couldn't tell you what the next one will be.
• u/Low_Rush_8535 ▲1your first list would have ruled out the exact step that broke us. expected input, expected tool, successful response, schema-valid output, no exceptions. the sdk returned subtype=success, and the content of that "successful" response was a rate limit message. everything in the trace said healthy. the work simply hadn't happened. what changed after: we log the response body alongside the status instead of treating content as opaque, and what decides whether a step ran is terminal state in the db rather than what the step reported about itself. the other one from around the same period — usage on a six-subagent run came back as input=23, output=11236. plausible-looking fields, impossible number, and nothing flagged it because nothing asserts that a number should make sense. i don't have a general rule though. each of those got a specific check bolted on afterwards, and i couldn't tell you what the next one will be.

소프트웨어 직업이 보여준 미래의 일자리 모습 ↗

AI가 소프트웨어 개발자를 실행자에서 robot manager와 결과 검토자로 바꾼다는 게시물에 대해, 댓글은 빠른 correctness feedback loop가 소프트웨어를 먼저 바꾼 핵심 이유라고 봤습니다. 반면 검토는 독립적인 고난도 기술이며 회사가 기존 인원 모두를 reviewer로 남기지 않고 소수 검토자만 둘 수 있다는 반론도 강했습니다.

• u/oliver_dev ▲21I'd argue it went first because of the feedback loop, not because it's text. You can run the output and find out in seconds whether it's wrong. Most jobs don't have that. If you can't check the work cheaply you can't let a model do it at volume, you just move the bottleneck to review. So the next ones to change are probably the jobs with a fast correctness signal, not the ones that look most like writing.
• u/the_ElementaryRe ▲4Yeah the hardest part is realizing that "reviewing and guiding" is a completely different skill set than doing the thing yourself, and most people are going to flounder when they can't just muscle through it anymore.
• u/Seattleman1955 ▲3It's a tool just like calculators, computers, software. You are just more productive and you don't have to do every little thing youself. People are upset that manufacturing line jobs have mostly left or been automated but does anyone today really want to do those 50s assembly line jobs? I don't think so, yet people still have jobs. Does any mortgage banker really want to do amortization schedules by hand? Today when something around the house needs to be fixed, before you call someone you generally get on YouTube to see if it's something you can easily do yourself. Using Gemini, for example, is similar. It's what I go to first especially with some new gadget that isn't working correctly, there is no useful manual and who wants to be on a help line with a company for hours over and over. Gemini is much better and easier. It should improve over time. When I first got a personal computer it did little. Then came the internet but initially it was limited as well. Now we can't live without it. If a tool takes your job away, it wasn't a great job. If it just helps you to be more productive at your job by taking away some of the tedious tasks, great. Most farmers had to find new
• u/Xaue_RWA ▲2the skill gap is harder than it sounds though, verifying what the robot produced in a domain where you used to execute is different from verifying in a domain where you have no execution background at all, and it may take really long time for u to do this
• u/presentofai ▲2the 'we all just become robot managers' framing is cope. companies aren't going to keep everyone as a reviewer, they keep one reviewer where there used to be ten. the job doesn't transform, it thins out.
• u/Straight-Analyst6149 ▲1The manager of automated output role you're describing already exists in a few fields that predate LLMs, like post editing machine translation or reviewing automated QA flags in manufacturing. The interesting thing from that existing data is that it's a genuinely hard skill to teach, a lot of people either rubber stamp the output because it looks plausible or over correct everything because they don't trust it, and neither failure mode is rare.
• u/arthaudm ▲1software went first because the feedback loop is instant - code compiles or it doesn't, tests pass or they don't. jobs where quality takes months to measure will transform slower & weirder, because nobody can tell if the agent output was good until long after. the part that transfers: taste becomes the job, execution becomes review. which part of your own work has already flipped?
• u/Correct_Emotion8437 ▲1As a developer, I don’t think so. Coding is well suited to AI - it’s a language and nobody cares if it looks funny because they don’t see it. But I have not found AI to be anywhere near as good at other tasks. Analyze a business idea or a property purchase or do a financial analysis….and the results are nicely formatted but no more reliable than a Google search.
• u/LazyTunnel ▲1Managing output ends up taking as much mental energy as doing it yourself. You spend most of your time catching stuff that looks right at first glance but is subtly wrong once you check the logic.
• u/diya_desai ▲1I think the hard part will be knowing what to give AI and checking if it did it right.

병원과 은행의 보안을 지키는 사람들의 AI burnout ↗

본문이 비어 있고 댓글은 paywall 불만과 일부 인용문에 한정돼 있습니다. 약 16,000개 회사에서 CISO가 상반기 할당 업무의 절반 정도만 끝냈다는 인용과, AI가 보안 업무를 줄이기보다 저품질 alert를 늘릴 수 있다는 의견이 있었지만 전체 기사 맥락은 확인할 수 없습니다.

• u/jonydevidson ▲1Paywalled.
• u/florinandrei ▲1paywall garbage, no full text in comments, have a downvote
• u/Redebo ▲1What’s an AI burnout? Is this when AI puts too much power to the wheels for the traction they have on the surface they’re sitting on?
• u/smackson ▲1> across roughly 16,000 companies, chief information security officers completed only about half of their assigned tasks in the first half of the year, creating a mountain of “zombie work” that never gets done and a feeling of powerlessness that contributes to burnout. I don't know about C-suite titles, but this is a management strategy that cuts across all positions and most sectors, but especially software. The feeling of "completion" is *not allowed* in many workplaces, because they are s#!t at thinking long term and feeling overwhelmed makes the coders and testers and designers work nights and weekends.
• u/presentofai ▲1the dirty secret is ai doesnt cut the security workload, it just spits out ten times more low quality alerts for the same burned out humans to triage

ARM 칩이 더 널리 쓰이지 않는 이유 ↗

댓글의 다수는 ARM이 데이터센터에 이미 널리 쓰이며, AI 연산의 주된 전력 소비는 CPU가 아니라 GPU라는 점에 동의했습니다. Nvidia GB200 NVL72의 Grace CPU처럼 ARM CPU가 시스템 운영을 맡아도 실제 training과 inference는 specialized GPU·TPU·NPU가 수행하며, commodity ARM 플랫폼 표준화가 남은 과제라는 보완 의견이 있었습니다.

• u/Zo0x78 ▲11They are already very prevalent in datacenters, so much so that ARM themselves are working on their own chip when they've always just licensed IP before - big money in high core count low power chips for millions of agentic tasks.
• u/Spra991 ▲4They are prevalent, the [Nvidia GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) that has been used to train OpenAIs models contains Grace CPUs, which are ARM based CPUs. But those are mostly just for running the OS. The actual training and inference isn't done on generic CPU, but on specialized GPUs/TPUs/NPUs. ARM doesn't have anything in that area, outside of what powers your smartphone.
• u/katoptronophile ▲2Our right to bear ARMs should not be infringed.
• u/Karyo_Ten ▲1All AI datacenters are using ARM chips since that's what you get when you by NVL72 racks with 72 Blackwell Ultra GPUs (and 72x7 ARM cores). But they aren't really doing any compute, the GPU is doing everything.
• u/presentofai ▲1the premise is kinda off, the power hog was never the CPU. its the GPUs doing the actual compute, so x86 vs arm barely moves your datacenter bill when nvidia is burning most of the watts
• u/GenericAlert ▲1Cuda, I think.
• u/Ill-Accountant-9941 ▲1I'm using Grace-Blackwell at home (for inference) it is very energy efficient.
• u/NeuralFiber ▲1Basically all android phones. All Iphones. All Mac and macbook for years. Many datacenters. A whole bunch of entry windows laptops. Much hardware like routers, drones,... Google told me it's around 250M x86 vs 25B arm. So already 100 times more arm then x86. That seems plenty prevalent
• u/diagrammatiks ▲1what? how could they be more prevelant? they are used everywhere.
• u/techzilla ▲1ARM lacks a proper standardized platform which is actually implemented in commodity hardware. Does it have a viable, general purpose platform? Yes, the SBBR, but can we buy commodity hardware with it? No.