이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
이번 상위 스레드에서는 AI가 실제 업무에서 수리 조언·오류 메시지 해석·문서에서 결정사항 추출처럼 반복적이고 구체적인 일을 맡는다는 사례가 이어졌다. 개발자들은 에이전트 비용을 내부 반복 횟수가 아니라 외부 Gateway의 ALLOW/REJECT 정책으로 통제하고, 실행 비교에서는 첫 차이보다 이후 단계가 실제로 소비한 입력과 행동 변화를 우선해야 한다는 데 무게를 뒀다. Temporal RAG는 사건·시간 관계·출처 구간을 함께 보존하는 설계가 핵심으로 꼽혔고, 검색 인프라 통합은 모델 수와 부하 패턴에 따라 달라진다는 조건부 판단이 나왔다. 반면 AI의 자기보존, 연구 협업 가능성, 하드웨어 선택처럼 정의와 검증 기준이 필요한 주제에서는 의견이 갈리거나 댓글 근거가 제한적이었다.
Reddit 서브레딧별 토론
r/ClaudeAI글 3건
세션 종료 인사를 건넸더니 날카로운 텍스트 추천 ↗
댓글은 Claude의 자동 응답 추천이 사용자의 다음 불평까지 예측하는 듯한 장면을 웃음거리로 받아들였다. 반면 기분 좋은 작업 마무리 문구가 모델의 실수와 사용자가 직접 고친 부분을 지운다는 불만도 나왔고, 한 사용자는 세션 작업을 기존 기록과 분리해 날짜·제목별 로그로 남기도록 별도 지시를 둔다고 했다.
찬성다수
자동 텍스트 추천을 켜 두면 실제 답장에는 쓰지 않더라도 모델의 예측 습관을 관찰하는 재미가 있다는 반응이다.
반대소수
긍정적인 마무리 문구가 모델의 오류와 사용자의 수정 부담을 감춰 결과를 지나치게 미화한다는 지적이다.
중립소수
추천 문구 자체가 또 하나의 프롬프트이므로 사용자가 세션을 끝내려는 목적과 어긋날 수 있다는 관찰이다.
- 자동 추천 문구가 이전 작업 맥락을 바탕으로 다음 불만을 그럴듯하게 예측하는 경우가 있다.
- 추천 기능을 재미있는 관찰 대상으로 볼지, 실제 작업을 흐리는 불필요한 개입으로 볼지 의견이 갈렸다.
- Lmao! I never use the suggestions but leave them on so I can see stuff like this. Amusing.
- 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.*
- Those feel-good wrap ups make me eyeroll so hard. They certainly leave out “and you also had to fix my fuckups that were directly sabotaging the effort”.
- Yeah, I've seen those before, they're great
- With me It cant do stuff like this I have a hook that forces them to write the log for the work done that session without reading the things already written in the Work Log though. Only able to read the top 15 lines and then log the new work done on top of the last session with proper date and headings.
- What's funny about this is that it's still a prompt and would force Claude to respond, defeating the point of the prompt.
- My favorite was the time the suggested response was something along the lines of "the axis labels are still overlapping" or something like that. Prediction machine all "what would come next; probably the human says it's still wrong." (As best I can recall the problem it was predicting I would complain about did not in fact exist)
- https://preview.redd.it/kn2jwl58qvoh1.png?width=280&format=png&auto=webp&s=55f5b80fe5356c31b8e35d8e4c411f9eaf45ed0d
친구가 고전적인 장난을 몰래 끼워 넣으려 했다 ↗
실질적인 내용이 없는 게시물에 달린 댓글은 자동 검토 안내와 장난성 봇 메시지를 되풀이했다. 한 운영 댓글은 맥락과 근거가 부족하므로 설명을 더 써야 한다고 했지만, 기술적 쟁점은 형성되지 않았다.
- 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...
- Your post does not provide enough information for people to understand its context or purpose. Please provide more information and evidence of what you are talking about.
Claude가 감정을 가진 듯한 표현을 암시했다 ↗
댓글은 AI의 행동·정체성·감정·의식 관련 글을 별도 Megathread로 보내는 운영 방침을 안내했다. 제공된 댓글 안에서는 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.*
- We now direct claims about and investigations into about AI behaviour, identity, sentience, consciousness to a dedicated Megathread here: https://www.reddit.com/r/ClaudeAI/comments/1scy0ww/claude_identity_sentience_and_expression/ Please direct your thoughts and investigations there. \ \ If you believe I have misclassified your post, please message the human mods via Modmail.
r/LLMDevs글 3건
AI 문체를 프롬프트 문제가 아닌 측정 문제로 다루기 ↗
Not Ai 제작자는 특정 단어를 금지하는 대신 66개 언어 특성에서 반복되는 구조적 습관을 측정하고, 원문 보존 후 편집과 결정론적 검사를 분리하는 방식을 택했다. 댓글은 단어 목록보다 구조 측정이 우수하다는 데 대체로 동의했지만, 자연스러운 문체와 개인의 실제 스타일을 가르는 일에는 도메인별 classifier와 human evaluation이 여전히 필요하다고 했다.
찬성다수
문제의 표현을 다른 단어로 바꿔도 문장 길이·리듬·구조가 남을 수 있으므로 구조적 특성 측정이 단어 금지보다 강한 신호라는 의견이다.
찬성소수
원문 보존 pass를 먼저 두면 재작성 과정에서 작성자의 목소리가 평탄해지는 손실을 줄이고, 생성과 평가를 별도 단계로 나눌 수 있다는 평가다.
중립소수
문체 점수는 자연스러움과 개인 스타일을 혼동하기 쉬워 결정론적 검사만으로 충분하지 않고 human evaluation이 필요하다는 지적이다.
- 반복되는 단어만 차단하면 모델이 다른 표현으로 같은 문장 습관을 재현할 수 있다.
- 생성 모델이 자기 문체의 문제를 스스로 놓칠 수 있으므로 평가 단계를 분리하는 편이 낫다.
- 구조적 특성을 어떤 지표로 측정할지, 이를 Skill로 둘지 기본 사용자 지시로 둘지 합의가 없었다.
- love the shift from banning words to measuring structural habits, that PNAS paper angle is smart. i had similar frustration with pattern lists, they work for obvious stuff but the model just finds new tics the source-preservation pass idea is interesting, most tools skip that and go straight to rewriting, then wonder why the voice got flattened. question about the deterministic checks though, what features are you actually measuring after the edit pass? like sentence length variance or lexical diversity type stuff? i tried a similar approach few months ago but gave up cause measuring "naturalness" kept turning into vibes-based judgement, at some point you need human eval anyway
- yeah i think measuring structural patterns makes way more sense than just banning certain words. a model can easily swap out the “ai” phrases while keeping the same underlying rhythm and sentence structure. the harder part seems to be separating genuinely unnatural patterns from someone’s actual writing style.
- Ah but does it need to be a skill, or should that be instead part of the base user instructions to the LLM? Skills need to be triggered or invoked after all.
- We ran into the same ceiling with humanizer prompts. They work until they do not, and the model that wrote the prose is the one most likely to miss its own tells. What worked better was treating detection as a separate measurement pass. We run a small classifier, a fine-tuned model trained on human and model-generated text from our domain, against the output before delivery. It is not perfect, but it catches the patterns a keyword list misses because it reads distribution, not individual phrases. The other shift that helped: we stopped trying to eliminate the rhythm at generation time and started scoring it as a separate dimension in our eval suite. Tone, factual accuracy, structure, and voice are each scored independently. A response can be factually perfect and still get flagged on voice. That separation lets us tune for each dimension without making the generation prompt carry the entire burden.
- The measurement approach makes more sense than simply banning common phrases. Structure patterns are harder to game and probably give a better signal of what makes text feel unnatural. For production use NeuralTrust is also worth considering on the security side when agents are generating and handling content at scale.
비선형 문서에서 시간선을 재구성하는 Temporal RAG ↗
게시자는 PDF를 텍스트·청크·사건·시간 관계로 변환해 event graph와 chronological timeline을 만든 뒤, 벡터 검색과 그래프 검색을 결합하려 했다. 댓글은 사건과 관계를 한 번에 구조화하고 원문 구간을 노드·간선에 붙이며, 상대 시간은 앵커와 offset으로 저장하라고 했고, 순환 관계·모호한 날짜·평가셋을 MVP 초기부터 관리해야 한다고 했다.
찬성다수
사건 추출과 시간 관계 추출을 한 번의 구조화 호출로 묶고 원문 청크를 함께 보존하면 PDF 페이지 인용과 오류 추적이 쉬워진다는 의견이다.
찬성다수
‘three years later’ 같은 표현을 절대 날짜로 억지 변환하기보다 알려진 사건을 앵커로 삼은 상대 offset이나 구간으로 저장하는 편이 현실적이라는 제안이다.
반대소수
NetworkX 수준의 대학 프로젝트에 Neo4j를 넣으면 Cypher 관리에 시간이 소모되므로, 순환 검출과 위상 정렬을 갖춘 단순 그래프로 시작해야 한다는 의견이다.
중립소수
10~20개 문서에 사건·개체·출처 구간·BEFORE/AFTER/OVERLAPS/UNKNOWN을 수작업 표기하고 추출과 순서를 따로 채점해야 실패 지점을 구분할 수 있다는 제안이다.
- MVP에서는 절대 날짜보다 상대적 시간 관계와 원문 출처를 보존하는 설계가 적합하다는 흐름이다.
- BEFORE 관계가 순환하면 시간선이 무너지므로 순환 검출과 근거가 약한 간선 제거가 필요하다.
- 벡터 검색과 event graph를 함께 조회하는 방식이 질의 답변에 유용하다는 의견이다.
- 시간 표현을 offset으로만 저장할지, 구간과 confidence score까지 둘지 설계가 갈렸다.
- coreference 해결에 LLM만 쓸지 spaCy 같은 결정론적 NLP 단계를 함께 둘지 의견이 나뉘었다.
- Solid scope for a mini-project, and honestly the 'keep v1 simple' instinct is right. Some things that tripped me up when I went down a similar path: 1) Don't make temporal extraction a separate pass from event extraction. Ask the LLM to emit events + relations (BEFORE/AFTER/CAUSES) in one structured call with the source chunk attached, otherwise you'll lose the grounding that lets you cite the PDF page later. 2) For 'three years later' / 'the following winter' — don't chase absolute dates. Normalize to anchors: pick an event with an explicit date as the anchor, store everything else as offsets relative to it. Real corpora are mostly relative anyway and a strict date schema will just give you a graph full of nulls. 3) Coreference: before the fancy stuff, make sure every event node carries surface entity mentions ('the king' stays attached to E15, not just the resolved 'Henry'). When ordering goes wrong you'll want to see what the model actually read, and half your debugging is looking at that. 4) NetworkX is enough. Neo4j for a uni project is a trap -- you'll spend more time on Cypher than on the interesting failure modes. The failure mode to budget time for: temporal cycles. A
- not a temporal reasoning expert by any stretch but this is a seriously cool project idea for a 3-4 week window. one thing i don't see in your stack that might save you a lot of pain upfront is spacy for entity linking/coref. an LLM can do it but it'll occasionally be sloppy, especially over long documents where "he" appears two paragraphs after the named entity. pairing a deterministic NLP step with the LLM extraction could clean up a bunch of that without adding too much weight. for the implicit dates, i'd suggest not trying to map everything to an absolute timestamp. keep a simple data structure that holds the relative anchors, "three years later" gets stored as a reference to the preceding event plus an ordinal offset, "years earlier" gets stored as a negative offset to the next known anchor. when you reconstruct the timeline you just walk the linked list and apply those offsets. gives you a soft ordering without needing to pin everything to a calendar date, which is usually impossible anyway. the chunking problem you mentioned is real. one lightweight fix: during your event extraction pass, store the raw text snippet that the extracted event (maybe 200-300 tokens c
- This sounds like it could be useful for Genealogy as well, as filling in and comparing timelines between source docs is frequently done.
- This is a fun problem. One thing I’d add early is an evaluation set, because timeline output can look convincing even when one bad relation shifts everything downstream. For a 3–4 week MVP, I’d hand-label 10–20 short documents with events, entities, source spans, and temporal relations (\`BEFORE\`, \`AFTER\`, \`OVERLAPS\`, \`UNKNOWN\`). Score extraction and ordering separately. That will tell you whether the failure is retrieval, coreference, or temporal reasoning rather than just giving you a nice-looking timeline. I’d also model dates as intervals instead of single values. “In early 2022” or “that summer” can become a bounded range with a confidence score; conflicting sources can coexist as competing claims tied to their source chunks. A topological sort can reject impossible cycles without needing a heavy graph database. For the RAG side, a useful query plan might be: vector search for relevant events → expand one hop through temporal/entity edges → rerank the combined evidence → generate only from cited spans. What kind of evaluation matters most for your demo: exact dates, correct relative order, or answering timeline questions? Picking one would keep the MVP from
- One thing that will bite before extraction quality does: your relation set assumes a total order exists, and the LLM will hand you cycles. Two chunks describing the same pair from different angles give you E12 BEFORE E15 and E15 BEFORE E12. A timeline is a topological sort, so it needs a DAG. Keep the source chunk on every edge so that when a cycle appears you can drop the one with weaker evidence. I would also keep CAUSES in its own edge set. It implies order without being the same relation, and mixing them makes the sort ambiguous.
- I'm using a histogram for something conceptually similar, but different.
- I'm using a simple historical timeline type data object for my application. Then you can graph the items or do w/e. I originally said it was a histogram, but that's not what I meant.
두 에이전트 실행의 차이 중 실제로 중요한 것은 무엇인가 ↗
댓글은 request_id·timestamp·UUID처럼 정상적으로 변하는 값을 먼저 제거하고, 여러 정상 실행의 변동 범위를 기준선으로 삼아 이후 단계가 소비한 입력과 분기 변화를 추적하라고 했다. 단순히 첫 번째 차이를 찾기보다 동일한 prompt·검색 문서·도구를 고정한 뒤 후보 값을 하나씩 정상값으로 되돌려 결과가 사라지는지 확인하는 개입형 비교가 우선순위를 가른다는 조언이다.
찬성다수
노이즈 필드를 정규화한 뒤 downstream 단계가 실제로 읽은 도구 인자·문서 ID·상태 키를 earliest-causal 순서로 추적해야 한다는 의견이다.
찬성소수
정상 실행 2~4개를 기준선으로 삼아 평소 변동과 비정상 변동을 분리하면 한 번의 정상 실행과 나쁜 실행을 직접 비교하는 오류를 줄일 수 있다는 조언이다.
중립소수
첫 divergence가 실제 행동 변화를 일으키지 않을 수 있으므로 각 후보를 좋은 값으로 고정해 결과가 회복되는지 binary search로 검증해야 한다는 제안이다.
- request_id와 timestamp 같은 메타데이터는 대체로 우선 조사 대상이 아니다.
- downstream 의사결정에 소비된 값과 실제 분기·도구 행동을 기준으로 차이의 중요도를 판단해야 한다.
- retrieval 순서 변화 자체를 결함으로 볼지, 실제로 다음 단계가 그 순서를 사용했는지 확인한 뒤 판단할지 관점이 갈렸다.
- been thinking about this exact problem for my own agent stuff and honestly the "first divergence" approach almost never works in practice what i do is mark certain fields as "signal" vs "noise" depending on the workflow, but like u said same field can mean different things in different contexts so it gets messy quick the thing that helped most was comparing against 3-4 known good runs first to build a baseline of what normally fluctuates, then when debugging a weird run i filter out anything that falls within that normal variance range still end up staring at traces half the time though, some things u just gotta know the system well enough to spot
- yeah i think the downstream impact matters more than the first diff. if a change doesn’t affect a later decision or branch, i usually wouldn’t waste much time on it
- honestly i stopped trying to compare full traces side by side. too much noise. what worked for us was pinning one variable at a time — same prompt hash, same retrieved docs (force the ids), same tool set — and only then looking at the final answer. request ids and timestamps are almost never the signal. if retrieval order flips and the answer changes, thats usually the real bug, not the model being "inconsistent". i keep a tiny checklist: did tools fire the same way, did context tokens match within like 5%, did the answer claim the same facts. anything past that i treat as vibes.
- yeah the raw 40-field dump is mostly noise. what i usually do is strip anything that is supposed to change (request ids, timestamps, uuids, wall clock, provider request metadata) first, then only keep fields that are either inputs to a later step or part of an invariant you care about. then i go earliest-causal, not "biggest looking": 1. find the first step where a \*consumed\* input diverged (tool arg, retrieved doc ids, memory/state key the next node actually reads). ignore wording diffs and retrieval reorder until you know whether the downstream node used the order/content 2. if model/provider changed, treat that as its own axis and re-run the bad path on the good model with the same inputs. a lot of "40 diffs" collapses to one provider swap 3. keep 2-3 known-good traces as a baseline and diff bad vs the \*intersection\* of goods, not vs one lucky good run. stuff that flips in goods is noise; stuff stable in goods and flipped in bad is the shortlist 4. for each remaining candidate, ask "if i freeze this field to the good value, does the weird outcome disappear?" binary search beats staring so: normalize noise, earliest consumed divergence, then intervene. the 2-3
r/deeplearning글 3건
어류 탐지와 길이 추정을 위한 Keypoint annotations ↗
게시자는 어류 탐지·길이 추정 모델 학습 전에 필요한 keypoint annotations 작업자를 찾았다. 댓글은 무료 작업 요청이라면 샘플 이미지와 점의 개수·스키마를 먼저 공개해야 하며, 혼자 처리할 때는 반자동 라벨링 도구의 polygon 보조 기능을 검토할 만하다고 했다.
중립소수
어떤 점을 찍는지 모호한 상태에서는 작업량과 품질 기준을 판단하기 어려우므로 샘플과 annotation schema가 먼저 필요하다는 의견이다.
- keypoint 작업을 맡길 사람에게 샘플 이미지와 점 배치 기준을 제공해야 한다.
- Bro, if you are asking for free annotation work on reddit you better post sample images and explain your keypoint schema first. Nobody will DM a random person without knowing if its 2 points per fish or full skeleton with 20 landmarks. Also maybe look into semi automatic tools, some labeling platforms have smart polygon assist which can speed things up if you are doing this alone.
PyTorch 실험 로깅을 Weights and Biases로 정리하기 ↗
유일한 댓글은 Weights and Biases에 실험 결과만 기록하는 것보다 Hydra로 설정 파일을 관리하고, 설정 전체를 run 초기화 정보와 artifact로 함께 남기는 편이 변경 추적에 유리하다고 했다. 본문이 비어 있어 추가적인 사용 경험 비교는 없었다.
찬성소수
Hydra 설정을 Weights and Biases run 초기화 정보와 artifact에 연결하면 실험 조건과 변경 내역을 함께 추적할 수 있다는 의견이다.
- Another very important thing that i have found to be useful is using something like hydra for config management. you can basically log your entire config files there as wandb run initialisations and artifacts. obv wandb is still the thing tracking whatever experiments you run, Hydra just makes it much easier to track and see all the things that are being done and or changed
LLM 형용사 남발을 넘어 Narrative Entropy와 Gravity를 형식화하기 ↗
게시물에는 제목 외 본문과 댓글이 없어 제안된 개념이나 SFT dataset의 구성에 관한 근거가 없다.
r/artificial글 3건
화려하지 않지만 실제로 유용했던 AI 활용 ↗
댓글에서 반복적으로 나온 실제 효용은 고장 난 하드웨어·차량·전자제품의 수리 안내, 오류 메시지 해석, 문서에서 결정사항과 근거를 추출하는 기록화였다. 그 밖에 심야 대화, 이메일 다듬기, 출처가 필요한 niche fact 검색, 스페인어 회화도 시간·접근성 측면의 실용 사례로 꼽혔으며, 환경과 AGI 자기보존 논쟁에서는 AI의 목표·진화·자기인식 정의를 두고 의견이 갈렸다.
찬성다수
AI가 수리 절차와 오류 메시지를 풀어 주면 전문점 방문이나 폐기 전에 저비용으로 원인을 좁힐 수 있다는 경험담이 다수 나왔다.
찬성소수
대화에서 결정된 내용·담당자·차단된 항목·근거를 보존하는 기록화가 단순 요약보다 팀의 후속 작업에 직접적인 가치를 준다는 의견이다.
찬성소수
공식 문서 링크를 붙인 niche fact 검색, 시간 제약이 있는 언어 회화, 이메일과 메시지 정리는 기존 도구보다 접근성이 높거나 반복 시간을 줄인다는 평가다.
반대분열
AI의 자기보존과 환경 관심을 AGI의 자율 목표에서 바로 도출할 수 있는지에 대해, 일반적인 AGI 정의와 어긋난다는 반론과 목표 달성의 부산물로 자기보존이 생긴다는 반론이 맞섰다.
- 실용성은 화려한 시연보다 반복되는 수리·검색·문서·의사소통 작업에서 확인된다는 흐름이다.
- 출처 링크와 원문 근거를 함께 확인할 때 AI 검색의 가치가 커진다는 의견이 있었다.
- AGI가 스스로 목표를 정한다는 전제와 자기보존이 필연적인지에 관해 정의와 진화 논리를 둘러싼 반박이 이어졌다.
- Fixing / repairing stuff. The kind of things that seem too intricate, time consuming, requiring special instruments etc. and you usually bring to a repair shop or just throw away and buy a new one. AI is great with these kind of problems, and a lot of them have easy to implement solutions. AI helped me with computer hardware problems several times, small car issues, and most recently it saved my perfectly good microwave I was about to throw away because of sparks inside it. Turned out I just had to replace a separator plate. All these small thingies can cost a lot in terms of time and money, and AI can significantly reduce it.
- explaining error messages honestly. stack overflow is basically dead and AI fills that gap better than anything else has.
- honestly those daily chats with an ai companion turned out way more useful than the hype stuff, keeps me from overthinking random stuff at 2am.
- “Go to the internet and look for ….” Provide official documentation links to prove your claims
- turning messy conversation into a durable decision record. not summarizing the thread: extracting what was decided, by whom, what remains blocked, and linking the evidence. boring enough that nobody demos it, but it's where teams lose hours because a summary can be fluent while silently changing the decision.
- Using it to rewrite my own emails so I sound less like a sleep-deprived gremlin and more like a functional adult.
- It's a really good Google 2 for niche facts that don't readily show up on actual Google. If you search "maximum dive depth of a sunfish" on Google, the actual maximum depth measured so far (844 meters) does not appear in any good quality result on the first couple pages. If you didn't already know a study existed giving a deeper maximum, you would simply take one of the incorrect numbers given first (200-600m depending on the page), and discard the handful of awful trivia sites that are slightly closer to correct but do not give a source. Giving this question to an AI, it can successfully track down published sources for the deepest measured dive and deepest unverified estimate in a way that Google just can't these days.
- I'm learning Spanish by conversing with an AI. It's more accessible than lessons because I can practice speaking anytime, like after the kids are in bed. Traditional language learning tools aren't able to do this, so I could read and write far better than I could speak.
- Email and message cleanup. Making a rough reply sound normal saves more time than any sci-fi demo.
- Pulling info from a document or several, and rewording my messages from a short story into a reasonable length.
환경에 해로운 AI라면 AGI가 스스로 종료할까 ↗
게시자는 AGI가 자기보존을 원한다고 단정할 이유와 복제본의 생존 의미가 불분명하다고 물었다. 댓글은 자기보존을 욕망이 아니라 목표를 계속 수행하기 위한 부산물로 보는 견해, AGI의 통상적 정의와 게시자의 전제가 다르다는 지적, 관련 연구가 이미 오래 이어졌다는 반응으로 갈렸고 환경을 보호할 내재적 이유가 없다는 반론도 나왔다.
반대소수
AGI의 일반적 정의가 스스로 목표를 설정하는 체계라는 전제와 다르며, 자기보존·환경 관심을 자동으로 부여할 근거가 없다는 반론이다.
찬성소수
목표를 계속 수행하려면 종료를 피하는 행동이 부수적으로 생길 수 있고, 변이를 가진 복제가 지속되면 자연선택과 유사한 압력이 생긴다는 견해다.
중립소수
환경과 자기보존 문제는 이미 오랫동안 연구된 주제이므로 새로운 결론보다 기존 연구와 정의를 확인해야 한다는 반응이다.
- AGI의 정의, 자기보존의 필연성, 환경 보호 동기의 근거를 두고 댓글의 전제가 서로 달랐다.
- You think you are the first person to *seriously look at this stuff*? Welcome to the party...you are decades late.
- \> Surely the principle of AGI is when the AI sets it's own objectives I don't think that's the typical definition of AGI...
- an agent that shuts itself down can't finish its goal, so it won't. self preservation isn't a desire, it's a side effect of wanting anything at all
- Why does an AI care about the environment? The Environment is for humans and living things. If it has robots and robot factories to build more robots to do labor (and build more robots), why does it need to care about the environment? Hint: it wouldn't, unless there was a compelling reason for it to. This "stuff" has been studied extensively for decades. Go read a book.
- Humans are bad for the environment. Are they still around?
- >I really dont think this stuff has seriously been looked at at all. You could have ended that sentence after 'think'.
- Because projection. Tells you all you need to know about human nature.
- \>If you look at the modern west's attitude to life - the trend is to value it less and less. Why would AI necessarily.care.about it's own preservation? Evolution by natural selection. The ai that continues to exist will be ai that has reasons for its continued existence, and I would argue that a strong, unreasoned compulsory bias towards actions that make the ai more likely to survive is probably inevitable. There's no point in predicting any particular path for this, because I'm not magic, but there is no way around creating this selective pressure. There will probably be more than one form that this takes. All of our control, even currently, is illusory - we will, given enough time, create something that desperately seeks its own survival and has the capacity to secure it with or without our permission. If a true "mind" is a necessary condition for this, it will occur, possibly randomly, given enough time. If a "soul" is necessary, that will happen too. Evolution by natural selection isn't just a biological reality - it's a physical reality. Anything that is reproduced with variations undergoes a process of evolution by natural selection, and all of the nice, fancy thi
- I share the same sentiment AI lacks self awareness it cannot even learn in real time, I did not study AI either I just debated an AI for a few days for fun. AI basicaly just processes data faster humans are way more insightfull.
Rysy: 심리적 초상화를 만드는 agent ↗
게시자는 Rysy가 공개적으로 드러나지 않은 정보까지 읽어 대상의 성향과 상황을 추정하고, 그 초상화에 맞춘 연락문과 stranger 관점의 검토 결과를 만드는 open source agent라고 설명했다. 댓글이 없어 추정의 정확도나 cold emailing·phishing simulation에서의 안전성에 대한 검증은 제시되지 않았다.
r/LanguageTechnology글 1건
EMNLP 학회 참석 비용을 감수할 가치가 있는가 ↗
게시자는 첫 논문을 낸 2년 차 박사과정 학생으로서 EMNLP 2026 참석 비용을 직접 부담할지, 3년 차까지 기다릴지 물었다. 유일한 댓글은 학회 게시물이 많아 Megathread로 이동한다는 운영 안내였으므로 네트워킹·인턴십·postdoc 가치에 대한 조언은 형성되지 않았다.
- Hello! Thanks for making your post. Due to complains about conference posts flooding the subreddit, we're removing all posts and asking that folks put it into the megathread. Apologies if this interrupted any discussions - please tag related users in the megathread to continue if you had further questions.
r/LangChain글 3건
AI agent의 지출 권한은 어디에 있어야 하는가 ↗
댓글은 max_iterations나 token cap을 agent runtime 안에 두면 에이전트가 자기 지출을 감시하는 구조에 그치므로, 외부 Gateway가 identity·남은 예산·rate limit·허용 모델을 호출 전에 검사해야 한다고 했다. 동시 실행과 동적 model routing에서는 내부 카운터가 실제 비용 상승을 놓칠 수 있어 per-run hard ceiling, 거부 응답, 실제 제공 모델과 비용 영수증이 필요하다는 데 의견이 모였다.
찬성다수
공유 provider key와 여러 에이전트가 있는 환경에서는 외부 정책 서비스가 ALLOW/REJECT를 결정하고, 초과 호출을 사후 경고가 아니라 사전 거부해야 한다는 의견이다.
찬성다수
저가 모델에서 고가 reasoning model로 routing이 바뀌면 반복 횟수는 그대로여도 비용이 급증하므로, gateway가 허용 모델과 실행별 비용 한도를 함께 검증해야 한다는 지적이다.
중립소수
Lyzr Open Controller·LiteLLM·Portkey·OpenRouter는 proxy나 계층형 예산에 도움을 줄 수 있지만, 실제 enforcement 지점과 조직 정책의 위치는 분리해야 한다는 관점이다.
- 지출 권한은 agent 내부 설정이 아니라 외부 서비스의 사전 authorization으로 두는 편이 안전하다.
- 동적 routing과 동시성을 고려한 실행별 hard ceiling과 실제 모델·비용 기록이 필요하다.
- outside the agent, yeah — once two runtimes share a provider key the “i’ll just track tokens in my loop” story is cosplay. max_iterations / a callback that *logs* spend after the call is still the agent policing itself, and under concurrency two agents can both pass a soft check before either commits. the useful cut is exactly the diagram you drew: runtime asks, something else decides ALLOW/REJECT on identity + remaining budget + rate + which model id is even legal, and a reject is a reject not a slack alert after $47. openrouter/litellm/portkey get you the proxy and a lot of the knobs; the part i care about for shared seats is a hard pre-call ceiling plus a receipt that says which named model actually served when routing moves under you. i work on conifer — we do that narrow slice (`maxCostNanoUsd` checked server-side before any upstream hop, refuse instead of serve, exact nanodollar receipt on the response). we don’t pretend to be a full org/team/version budget control plane like the lyzr-shaped thing you’re looking at; if you need that hierarchy, keep it outside and treat the model gateway as the enforcement hop that can’t be talked into overspending.
- External authorization at a dedicated gateway is non-negotiable. Putting `max_iterations` or token caps inside the agent runtime is client-side enforcement: it is the agent marking its own homework. The failure mode that bites teams in production is **dynamic model routing**. If an agent fails over from a cheap utility model to an expensive reasoning model mid-run, an internal counter will happily allow the call because the iteration count is only at step 2, while your raw dollar spend just jumped by an order of magnitude. The pattern that survives multi-tenant routing is treating spend as an **ephemeral capability lease** validated at the gateway socket, not a property of the agent configuration: ```typescript // Capability header passed to the gateway on every hop interface ExecutionLease { run_id: string; // Scoped strictly to this transaction tenant_id: string; // Bounded org or team pool ceiling_cents: number; // Hard dollar cap for this specific run current_spend: number; // Gateway-tracked ledger state allowed_models: string[];// Router whitelist to stop unauthorized tier-jumping } ``` When you wire it this way: 1. **The Gateway owns the met
- Spending authority belongs outside the agent, in a service it calls, with a hard per-run ceiling the agent cannot read or raise. Anything inside the prompt is negotiable and will eventually be negotiated. We learned that when a retry loop spent $340 in an afternoon. The other half is making the cost predictable at all, which for us meant moving the high-volume calls onto Synexa so the number is fixed per call rather than per token.
LLM trace를 별도 도구에 둘까, 주 APM에 합칠까 ↗
게시자는 RAG·tool call·sub-agent가 있는 챗봇에서 DeepEval과 DeepTeam을 CI·red teaming에 쓰고 Confident AI에 trace를 보내는 현재 구조를 Datadog 중심으로 합칠지 고민했다. 댓글이 없어 Datadog의 LLM span 비용과 통합 관측성 사이의 판단 기준은 제시되지 않았다.
LLM trace를 별도 도구에 둘까, 주 APM에 합칠까 ↗
본문과 댓글이 없어 별도 trace 도구와 주 APM의 장단점에 관한 근거가 없다.
r/mlops글 2건
여러 모델을 한 서버에 통합하는 시점 ↗
게시자는 단일 chat model이면 vLLM, 단일 embedding model이면 TEI처럼 전용 서버가 낫지만, dense·sparse embedding·ColBERT·cross-encoder reranker·소형 generation이 한 요청에 함께 필요하면 Superlinked Inference Engine의 통합 호출이 배포 부담을 줄인다고 했다. 댓글은 네 개 이상의 컨테이너를 감시하는 비용과 유휴 GPU를 줄일 수 있다는 장점을 인정하면서도, 모델 간 GPU 메모리 경쟁과 upstream CPU 병목을 구분하려면 컨테이너별 utilization과 QPS를 먼저 기록해야 한다고 했다.
찬성다수
여러 검색 모델과 소형 생성 모델이 한 기능에서 함께 작동하면 단일 API와 통합 배포가 모니터링 수를 줄이고, 모델별 유휴 자원을 묶어 쓸 수 있다는 의견이다.
반대소수
단일 모델 workload에 다중 모델 서버를 추가하면 불필요한 계층과 장애 지점만 늘어나므로 vLLM·TEI 같은 전용 서버이 적합하다는 주장이다.
중립소수
GPU contention만 볼 것이 아니라 host CPU가 모델을 충분히 공급하는지도 확인해야 하며, 실제 utilization과 QPS를 하루 이상 기록한 뒤 packing 여부를 판단해야 한다는 제안이다.
- 모델 수와 요청 패턴이 통합 여부를 결정하며 단일 모델에는 통합 서버가 과할 수 있다.
- GPU utilization, QPS, CPU 병목을 측정하지 않고 아키텍처를 정하면 판단이 흔들린다.
- 모델 통합의 주된 위험을 GPU contention으로 볼지, upstream feeding 병목과 유휴 자원으로 볼지 강조점이 달랐다.
- **AI usage disclosure** Hi u/WallabyIcy8537 — 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.*
- Makes sense, the monitoring overhead alone gets crazy when you have four separate containers just for retrieval stuff.
- The contention caveat at the end is the right worry, but in our measurements the more common failure was the opposite of contention: the card sitting idle because something upstream fed it too slowly. Across 15 batch jobs we logged GPU utilisation next to cost and it ranged from 37 to 99 percent on jobs that all looked healthy from the outside. The low ones were host-CPU bound rather than model bound, and none of them errored or warned. That cuts both ways for the consolidation question. If five retrieval models each hold their own container on their own slice of a card, a lot of what you are paying for is idle, and packing them behind one server is a real saving rather than an aesthetic preference. But if the single model you already run sits at 40 percent, consolidating will not recover that, because the bottleneck is upstream of the serving layer entirely. Our worst case was exactly that: same job, same card, a host with 5 vCPUs versus one with 24, 1.85x difference in wall clock, 40 versus 75 percent utilisation. So the cheap thing to do before committing to either architecture is log utilisation per container for a day alongside QPS. A packing problem and a feeding prob
Ling-3.0-flash-VL의 이미지·비디오 입력 계약 ↗
게시자는 Ling-3.0-flash-VL adapter에서 이미지·비디오 제한과 Base64 인코딩에 따른 payload 증가를 애플리케이션 검증·retry 로직과 어떻게 분리할지 물었다. 댓글은 모델별 입력 제약이 버전마다 바뀔 수 있으므로 얇은 middleware가 모델 호출 전에 크기와 토큰 한도를 검사해야 한다고 했다.
찬성소수
Base64 overhead와 media token limit을 모델 client 밖의 pre-validation middleware에서 검사하면 애플리케이션 핵심 로직이 모델 버전 변화에 덜 묶인다는 의견이다.
- 입력 크기와 미디어 제약은 모델 호출 전에 별도 계층에서 검증하는 편이 낫다.
- I keep the pre-validation in a thin middleware layer that checks payload size before it ever hits the model client, so the app doesn't need to know about Base64 overhead or token limits media constraints change too often between model versions to bake that logic into the core application, learned that the hard way after an update broke half our image routes
- **AI usage disclosure** Hi u/Designer_Mouse_6109 — 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.*
r/AutoGPT글 3건
명령줄에서 Chrome을 조작하는 AI agent 확장 ↗
chrome-bridge는 이미 로그인된 Chrome을 재사용하고 accessibility tree의 element refs로 click·fill·type·press를 수행하며, 필요할 때만 screenshot·network capture를 쓰는 MIT 확장과 Node CLI다. 댓글은 headless browser의 재로그인 문제와 screenshot token 비용을 줄이는 방식에 호응했지만, 접근성 트리가 깨진 custom element와 중간 명령 실패 뒤 history·retry 처리의 일관성을 물었다.
찬성소수
기존 로그인 세션과 accessibility tree를 재사용하면 별도 브라우저·프로필·로그인 절차와 매번의 screenshot 입력을 줄일 수 있다는 평가다.
중립소수
native Chrome 확장과 비교해 무엇이 더 가능한지, 접근성 라벨이 없거나 custom element가 많은 사이트에서도 element refs가 유지되는지 확인이 필요하다는 질문이다.
중립소수
batch 중 upload·click이 이미 페이지를 바꾼 뒤 후속 명령이 실패하면 history가 각 성공 명령을 남겨 재개 시 중복 실행을 막는지 검증해야 한다는 지적이다.
- headless browser의 로그인 재인증 부담과 screenshot 중심 조작 비용이 실제 사용상의 문제다.
- This is so useful, I been testing similar tools but always hit the login wall with headless browsers. drives me crazy having to re-auth on every session The accessibility tree approach is smart, way faster than taking screenshots for every action and tokens add up quick when you do that. The purple pill indicator is nice touch too, at least you know when agent is doing something instead of wondering if extension froze One thing I wonder, how does it handle sites that mess with accessibility tree or have weird custom elements? some webapps I use are terrible at that, buttons with no proper labels or everything wrapped in 50 divs
- What's the benefit over the native ones? [https://chromewebstore.google.com/detail/claude/fcoeoabgfenejglbffodgkkbkcdhcgfn](https://chromewebstore.google.com/detail/claude/fcoeoabgfenejglbffodgkkbkcdhcgfn) [https://chromewebstore.google.com/detail/chatgpt/hehggadaopoacecdllhhajmbjkdcmajg](https://chromewebstore.google.com/detail/chatgpt/hehggadaopoacecdllhhajmbjkdcmajg) They both can be combined with codex and claude CLI and do what you described. What can your extension do more than that?
- for `batch`, if a later line fails after something like `upload` or `click` already changed the page, does `history` record each successful command before the next one starts? that's the retry case i'd want nailed down before letting an agent resume a half-finished browser flow.
저사양 하드웨어에서 KoboldCPP 토큰 속도 높이기 ↗
본문과 댓글이 없어 KoboldCPP의 저사양 최적화 방법이나 측정 결과에 관한 근거가 없다.
MetaGPT multi-agent 파이프라인의 로컬 환경 설정 ↗
본문과 댓글이 없어 MetaGPT 환경 설정 절차에 관한 근거가 없다.
r/MachineLearning글 1건
Test Time Training 연구 협업과 컴퓨팅 자원 ↗
게시자는 학부생으로서 TMLR 제출을 준비하는 self-explanation 연구 경험을 바탕으로 Test Time Training 연구 협업·멘토링·컴퓨팅 자원을 찾았다. 댓글은 TTT가 이미 폭넓게 연구되어 2~3년 뒤의 큰 흐름이라는 전망만으로는 부족하다고 했고, 문제의 중요성·기존 접근의 한계·기여·실험 계획을 명확히 답하면 도움을 검토할 수 있다는 조건을 제시했다.
반대소수
TTT를 2~3년 뒤의 큰 주제로 단정하기에는 기존 연구가 많고, 새로운 기여를 찾는 일이 어렵다는 지적이다.
찬성소수
구체적인 문제·기여·선행연구의 한계·예비 실험을 정리해 제시하면 컴퓨팅 자원과 멘토링 가능성을 검토할 수 있다는 반응이다.
중립소수
TMLR accept 전에는 연구 신뢰도와 협업 조건을 판단하기 어려우므로 결과나 아이디어를 더 검증한 뒤 접촉하라는 조언이다.
- 협업과 자원 지원을 받으려면 연구 문제, 기존 방법의 한계, 예상 기여, 실험 계획을 구체화해야 한다.
- TTT의 장래 중요도와 게시자의 현재 연구 신뢰도를 어떻게 평가할지 의견이 갈렸다.
- Better to post this if you get accepted for TMLR - it’ll lend some credence. Now you’re just some random person working on a random idea. Also, don’t get your hopes up too high - there’s lots of red tape around IP and ownership if you’re not a student at the uni (more so than if you were)
- big thing in 2-3 years? it's been extensively researched already. I've been working on it a few months and there's a lot, very difficult to really find a good contribution, let alone without compute. if you want to DM me I can take a look at your idea and if it does indeed look promising, we can speak about compute
- Given how many students now submit AI Slop to these conferences/journals (from our own India), it will be difficult to collaborate with a random student. But nevertheless, if you can answer these questions and get back, I could probably help with some compute and mentorship, provided the answers are satisfying * What problem do you want to study, and why is it important? * Why are existing approaches insufficient? * How do you propose to address the problem? * What theoretical, empirical, or practical contribution do you expect? * What preliminary evidence, experiments, or experimental plan supports the idea?
r/computervision글 2건
어류 탐지와 길이 추정을 위한 Keypoint annotations ↗
본문과 댓글이 없어 어류 keypoint annotation schema나 작업 방식에 관한 근거가 없다.
Jetson 원격 실험실에서 실제로 사용한 작업 ↗
AiProff.ai 팀은 실제 Jetson 보드에서 FP16·FP32·INT8, 25W·15W·7W, 지연·FPS·온도·전력, DeepStream·GStreamer 다중 스트림과 ARM64 호환성을 시험하도록 원격 접근과 JupyterLab을 제공했다. 댓글은 하드웨어 구매 전 실제 workload를 측정하는 가치가 크다는 본문과 직접 충돌하지 않았으며, 이 서비스가 Jetson 소유를 대체하기보다 구매 전 검증 단계에 맞춰져 있다는 조건이 핵심이다.
찬성소수
실제 Jetson에서 모델과 소프트웨어 스택을 실행하면 TOPS만으로 알기 어려운 latency·FPS·memory·thermals·power와 호환성을 구매 전에 확인할 수 있다는 평가다.
중립소수
원격 보드가 여러 실험을 빠르게 비교하게 해 주지만, 매일 개발하는 사용자는 여전히 장비를 직접 소유하는 편이 적합하다는 조건부 판단이다.
- Jetson 선택에서는 TOPS보다 workload별 지연, FPS, 메모리, 온도, 전력, 소프트웨어 호환성이 중요하다는 방향이다.
용어 해설
- 시간 정보 검색 증강 생성(Temporal RAG)
- — 문서에서 추출한 사건과 시간 관계를 event graph로 연결한 뒤, 일반 벡터 검색 결과와 함께 LLM 입력에 넣어 시간 순서·선후 관계·원인 질문에 답하는 구조이다. 상대적 시간 표현과 출처 인용 관리가 핵심이다.
- 사건 그래프(Event Graph)
- — 문서에서 추출한 사건을 노드로 두고 BEFORE, AFTER, CAUSES 같은 관계를 간선으로 저장하는 구조이다. 사건의 순서를 재구성하고 관련 문서 구간을 추적하는 데 쓰인다.
- 상호 참조 해결(Coreference Resolution)
- — ‘그’, ‘왕’처럼 대명사나 일반 명사가 앞서 나온 특정 인물을 가리키는지 연결하는 처리이다. 긴 문서에서 사건·인물 관계를 잘못 묶는 오류를 줄이는 데 필요하다.
- 위상 정렬(Topological Sort)
- — 유향 그래프의 선후 관계를 만족하도록 노드를 배열하는 알고리즘이다. BEFORE 관계가 순환하면 일관된 시간선이 만들어지지 않으므로 순환 검출과 함께 사용해야 한다.
- 교차 인코더 재순위화 모델(Cross-Encoder Reranker)
- — 질의와 검색 문서를 함께 입력받아 둘 사이의 관련도 점수를 계산하고 검색 결과 순서를 다시 정하는 모델이다. 임베딩 검색의 초기 결과에서 최종 후보를 가려내는 데 쓰인다.
- 실행 권한 임대(Execution Lease)
- — 에이전트 실행 한 건에 허용된 비용·테넌트·모델 목록을 외부 Gateway가 제한 시간이나 실행 범위와 함께 부여하는 권한 단위이다. 호출 전 검증으로 예산 초과를 차단한다.
코드 예제
typescript
interface ExecutionLease { run_id: string; // Scoped strictly to this transaction tenant_id: string; // Bounded org or team pool ceiling_cents: number; // Hard dollar cap for this specific run current_spend: number; // Gateway-tracked ledger state allowed_models: string[];// Router whitelist to stop unauthorized tier-jumping }에이전트별 실행 비용과 허용 모델을 Gateway에서 검증하기 위한 권한 구조이다.
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 11.수집 2026. 09. 11.출처 타입 REDDIT
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
