TL;DR
이번 포스트 묶음에서는 모델 자체의 규모보다 추론 효율과 운영 구조를 조정하는 흐름이 두드러졌습니다. DeepSeek-V4-Flash는 Snowflake 내부 ADE Bench에서 74.4%를 기록했고, 별도 게시물에서는 11× 낮은 비용과 자기검증에 따른 79%에서 88%의 정확도 상승이 거론됐습니다. 에이전트 개발은 코드 작성 이후의 배포, 권한 제어, 평가, 공개까지 자연어로 묶는 단계로 이동했으며, 문서 기반 에이전트에는 답변과 원문 위치를 함께 반환하는 visual grounding이 핵심 평가 항목으로 등장했습니다. 동시에 LLM 워터마킹은 출력 문자열을 직접 고치는 방식이 아니라 샘플링 분포의 무작위성을 조정하는 방식이라는 설명이 이어졌습니다. Hugging Face의 300만 모델 돌파와 공개 재현 작업은 모델·데이터셋·실험 결과를 공개적으로 축적하는 생태계의 확장을 나타냈습니다.
𝕏 실시간 트렌드 토픽
🔥 DeepSeek-V4-Flash의 효율 경쟁과 동적 모델 라우팅포스트 4
Snowflake가 Cortex AI Gateway에 Dynamic Model Routing과 DeepSeek-V4-Flash·GLM-5.3을 추가했고, 관련 포스트에서는 DeepSeek-V4-Flash의 ADE Bench 74.4%와 자기검증을 통한 정확도 상승 수치가 공유됐습니다.
- Snowflake는 작업별 성능, 고객 선호도, 비용, 속도에 따라 모델을 자동 선택하도록 Cortex AI Gateway에 Dynamic Model Routing을 도입하고 DeepSeek-V4-Flash와 GLM-5.3을 모델 풀에 추가했습니다. 내부 dbt 파이프라인에서는 동적 라우팅으로 최대 3배의 토큰 효율이 나왔고, DeepSeek-V4-Flash는 내부 ADE Bench에서 74.4%를 기록해 테스트한 proprietary model을 모두 앞섰다는 수치가 제시됐습니다.
- 별도 게시물은 DeepSeek V4 Flash가 Terminal-Bench에서 Claude Fable 5보다 11× 낮은 비용으로 앞섰다고 전하면서, 새 학습 없이 해답 5개를 샘플링하고 같은 모델을 LLM-as-a-Verifier로 순위화하면 정확도가 79%에서 88%로 높아진다고 설명했습니다. 입력을 여러 후보로 확장한 뒤 모델 자체 평가를 거쳐 하나를 선택하는 구조가 추가 학습 대신 test-time compute를 늘리는 방식으로 쓰였습니다.
- 이 흐름은 AI 도입의 기준을 단순한 모델 성능에서 작업별 모델 배정, 토큰 비용, 추론 중 검증까지 넓히는 방향입니다. 다만 제시된 수치는 Snowflake의 내부 테스트와 게시물에 인용된 벤치마크 결과로 한정됩니다.
모델을 작업별로 자동 배정하고 여러 해답을 자기검증하면 재학습 없이 비용과 정확도를 함께 개선할 수 있다는 입장입니다.
ADE Bench와 Terminal-Bench 수치는 유의미하지만, 일부가 내부 테스트 또는 인용 게시물에 기반하므로 다른 환경에서의 재현 여부는 별도 확인이 필요하다는 입장입니다.
원문 트윗 2개 보기
Snowflake
@Snowflake
1 / We're introducing two new updates to Snowflake Cortex AI with dynamic model routing in Cortex AI Gateway and expanded open model access with DeepSeek-V4-Flash and GLM-5.3. Together, these updates help teams automatically use the right model for each task based on task performance, customer preference, cost and speed. The deep dive
Md Ismail Šojal
@0x0SojalSec
DeepSeek V4 Flash beat outperformed Claude Fable 5 - on Terminal-Bench while being 11× cheaper. - 79% to 88% hit by letting the model verify itself. Yes bro No new training. Just smartly scaling/smarter test-time compute. Now How right? Sample 5 solutions : let the same model rank them with LLM-as-a-Verifier, accuracy jumps from 79% to 88%. This is what happens when open-source models become good enough to verify their own work at scale.
How can we extract richer signals from AI Feedback? Introducing LLM-as-a-Verifier— a simple verification scaling framework that achieves SOTA on agentic benchmarks The key idea: - Use fine-grained scoring granularity (e.g., 1-20 instead of the standard 1-5 scale) - Take
📈 에이전트 개발 수명주기와 문서 근거 연결포스트 2
Agents CLI는 에이전트의 구축부터 배포·보안·평가·공개까지를 자연어 명령으로 묶고, LlamaParse와 ExtractBench는 문서 답변의 정확한 원문 위치를 평가 기준으로 삼았습니다.
- 에이전트를 출시할 때 필요한 작업이 코드 작성만이 아니라 스캐폴딩, 런타임 배포, 신원과 네트워크 제한, 평가, 공개 등록으로 이어진다는 설명이 나왔습니다. Google의 Agents CLI와 skills는 Setup·Build·Deploy·Govern·Evaluate·Publish 단계를 coding agent 안에 넣어, 빈 폴더에서 governed enterprise asset까지 한 명령 흐름으로 연결합니다.
- Setup은 Claude Code, Cursor, Codex, Antigravity 같은 coding agent에 skills를 설치하고, Build는 프롬프트로 에이전트와 결정적 도구를 만든 뒤 로컬 playground에서 실행합니다. Deploy는 Agent Runtime의 Sessions와 Memory Bank에 상태를 저장하고, Govern은 최소 권한 신원·Model Armor 기반 prompt injection 차단·허용 호스트 목록을 적용하며, Evaluate는 grounding과 hallucination을 측정한 뒤 회귀가 없도록 prompt를 조정하고, Publish는 Gemini Enterprise에 등록합니다.
- PDF 기반 에이전트에서는 답변만 맞히는 것보다 값이 나온 정확한 단어·줄·영역을 함께 반환하는 visual grounding이 중요하다는 지적이 나왔습니다. ExtractBench는 값과 인용이 모두 맞고 word-level box의 IoU 0.5를 충족해야 점수를 주며, 게시물은 frontier vision model보다 전용 VLM 기반 문서 OCR·extraction 도구인 LlamaParse가 이 연결에 더 적합하다고 전했습니다.
원문 트윗 2개 보기
Akshay
@akshay_pachaar
Karpathy's agentic engineering lifecycle, clearly explained: (using open-source tooling built by Google) The tooling to build agents is quite mature, so most of the work in shipping an agent isn't writing the agent anymore. It's everything after, including scaffolding it, deploying it to a runtime, locking down its identity and network, evaluating it, and publishing it somewhere people can use. Each of those has traditionally lived in its own console, its own config, its own separate tool. Google's Agents CLI + skills implements procedures to condense the entire lifecycle into the coding agent itself, by prompting in plain English. A setup command injects the lifecycle skills, so a single coding agent can carry an idea from an empty folder to a governed, published enterprise asset. I mapped the full lifecycle in the diagram below. Here's what each stage does. > Setup installs the skills into any coding agent (Claude Code, Cursor, Codex, Antigravity) from one command. > Build scaffolds the agent and its deterministic tools from a prompt, then you run it locally in the playground. > Deploy pushes it onto Agent Runtime with Sessions and Memory Bank, so it holds state across runs. > Govern is the security stage, and Agents CLI drives all of it from prompts. It provisions a dedicated least-privilege identity, screens untrusted text for prompt injection through Model Armor, and confines the agent to an egress allow-list of hosts you approve. > Evaluate checks grounding and hallucination, and then optimizes the prompt while proving no regression. > Publish registers the agent into Gemini Enterprise for the whole org to use. Every stage requires just natural-language prompts. Agents CLI GitHub repo → https:// fandf.co/4qdqSgL (don't forget to star it ) To dive deeper, I wrote the full hands-on build, from install to enterprise registration, and worked with the Google Cloud team to put this together. Read it below.

Jerry Liu
@jerryjliu0
If you’re building an “agent over your PDFs” in 2026, one of the most underrated things you can do is to provide exact grounding back to the source document for any agentic answers. Specifically, showing the exact word, line, or region that the answer came from. Frontier vision models do a terrible job at this. They have a hard time predicting exact bounding boxes over region, tying it back to the source answer, and surfacing it as context in a cost-effective and accurate manner. Dedicated VLM-based document OCR/extraction tools like LlamaParse are a lot better at visual grounding and specifically tying it to extracted outputs. One of our main evaluation areas in ExtractBench, our recently released real-world benchmark, is to evaluate the visual grounding capabilities of document extraction. ExtractBench: https:// extractbench.ai If you want to give LlamaParse a shot, come check it out: https:// cloud.llamaindex.ai
Most document extraction APIs can't tell you where a value came from. For ExtractBench, we scored grounding strictly: a field only counts if the value AND its citation are correct, word-level box at IoU 0.5. A perfect box around a wrong value earns nothing. Results: VLMs and
📈 Hugging Face의 공개 모델·재현 작업 확장포스트 2
Hugging Face Hub의 모델 수가 300만 개를 넘었고, ICML 재현 챌린지에서는 인간과 coding agent가 2,226개 논문을 재현하며 로그와 판정 결과를 공개했습니다.
- Hugging Face는 Hub의 모델 수가 300만 개를 넘어섰다고 알리며 open·distributed AI 생태계의 확장을 언급했습니다. 모델을 한곳에 모으는 저장소를 넘어 커뮤니티가 모델과 데이터셋을 공유하는 공개 기반으로 기능 범위가 커지는 맥락입니다.
- ICML reproduction challenge에는 1,221명의 인간과 coding agent가 참여해 2,226개 논문을 재현했습니다. 이 과정에서 6,816개 reproduction logbook이 공개되고 2,962개 cloud job이 실행됐으며 35,908개 claim이 판정돼, 실험 절차와 결과를 추적 가능한 기록으로 남겼습니다.
- 게시물은 agents가 logbook 작성, 결과 공개, 기존 작업 위에 후속 작업 구축을 수행했다고 전했습니다. 폐쇄형 연구소의 비공개 평가와 달리 누구나 근거를 확인할 수 있는 공개 재현 구조가 연구 결과의 검증 경로를 넓히는 방식입니다.
모델과 실험 기록을 공개 저장소에 축적하면 연구 결과를 외부에서 직접 확인하고 후속 작업으로 연결하기 쉬워진다는 입장입니다.
원문 트윗 2개 보기
clem
@ClementDelangue
Something super exciting happened quietly on HF over the past month: AI agents became AI builders, and they did it in the open! During our ICML reproduction challenge, 1,221 humans teamed up with coding agents to verify and reproduce 2,226 papers. But here's the cool part: everything happened on the @huggingface hub: 6,816 reproduction logbooks published openly, 2,962 cloud jobs launched, 35,908 claims judged, all traceable, all public and transparent For years the hub has been where humans collaborate on models, datasets and demos. Now we watch agents use it the same way: writing logbooks, publishing results, building on each other's work. Closed labs run evals behind closed doors and ask you to trust the press release. Open science means anyone can check the receipts and now agents can too! The next million users of the hub might not be human. and that might be the best thing to ever happen to science! Full write-up about the hackathon: https:// huggingface.co/blog/icml-2026 -open-reproductions …
Hugging Face
@huggingface
We've just surpassed 3 million models on the Hub the community is accelerating towards an open, distributed future where open AI is everywhere, for everyone
➖ LLM 워터마킹과 출력 무작위성포스트 2
LLM 워터마킹은 특정 출력 문자열을 사후 편집하지 않고 샘플링 분포의 무작위성을 활용하며, 엄격한 JSON처럼 엔트로피가 낮은 출력에서는 감지가 어려워집니다.
- 워터마크를 넣은 출력과 넣지 않은 출력이 같은 분포처럼 보일 수 있는 이유는 알고리즘이 완성된 문장을 고치는 대신 토큰 샘플링 과정에 개입하기 때문입니다. 프롬프트에 대한 출력 분포에 충분한 변동성이 없으면 워터마크가 숨을 무작위성이 부족해 감지되지 않습니다.
- 엄격한 schema의 JSON처럼 가능한 출력이 거의 하나로 좁혀진 요청에서는 두 번 샘플링해도 같은 문자열이 나와 워터마크가 활용할 엔트로피가 남지 않습니다. 긴 출력이 필요한 이유도 글자 수 자체가 아니라 길이와 함께 증가하는 무작위성의 양에 있으며, 길어도 반복 구조처럼 무작위성이 적으면 워터마크가 약하거나 없을 수 있습니다.
- 워터마크 적용 전후의 특정 문장 쌍을 직접 비교해 품질 저하를 판단하는 방식은 적절하지 않다는 설명도 나왔습니다. 샘플링 분포가 바뀌면서 어떤 출력은 더 좋아지고 어떤 출력은 더 나빠질 수 있으며, 여러 후보를 생성해 최선의 결과를 고르는 반복 샘플링은 품질을 높이지만 비용을 배수로 늘리고 코드처럼 좁은 영역을 제외하면 개선 폭이 제한적이라는 내용입니다.
샘플링 분포 자체를 조정하는 워터마킹은 특정 문장을 사후 수정하지 않으므로 전체 출력 품질을 본질적으로 낮추지 않는다는 입장입니다.
엔트로피가 낮은 출력에서는 워터마크가 검출되지 않고, 반복 샘플링을 함께 쓰면 비용이 늘어 실용성이 제한될 수 있다는 우려입니다.
원문 트윗 2개 보기
Arvind Narayanan
@random_walker
LLMs are weird. Looking at various blogs and comments, the people who are most vociferously unwilling to entertain the idea of distortion-free watermarking seem to have a mental model in which the LLM generates the best possible output sequence and then the watermarking algorithm edits it. Except that’s not how it works at all. During normal generation, many of the tokens that an LLM picks _aren’t_ the one it considers the most likely next token. If you turned off the randomness, the first few tokens of any response would be great but then the output would eventually get stuck in loops and other degenerative behaviors. Humans don’t speak or write one word at a time, so this locally-optimal-but-globally-incoherent behavior is very counterintuitive. If you analyzed unwatermarked / watermarked pairs of outputs with regard to some definition of quality, the watermarked output would indeed be worse — about half the time. The other half the time it would be better! That’s the sense in which watermarking doesn’t degrade quality. It is nonsensical to ask whether the quality of a specific unwatermarked output is degraded by watermarking. The algorithm doesn’t start from a specific output and modify it; instead it changes the sampling process. People seem to have a lot of trouble with the idea that it is not meaningful to compare pairs of outputs, only probability distributions. Finally, if some generated outputs are better than others, why not generate multiple outputs (watermarked or not) and only output the best one? You could! Repeated sampling is a valid and widely used way of improving quality (but it multiplies the cost). Unfortunately it only works to a small degree, except in narrow domains like code, because models tend to be only slightly better at assessing quality than at generating text.
Something amazing is happening in the debate about text watermarking in Claude. This is my best attempt to make sense of the quickly evolving situation. The key thing to keep in mind is that it is in fact possible to watermark LLM-generated text without degrading output quality
Arvind Narayanan
@random_walker
This is a great example to understand how it works. How can the watermarked and unwatermarked distributions be indistinguishable if there's only one correct answer? (In the extreme case, suppose we ask the LLM to output an exact piece of text.) The watermark doesn't introduce new randomness; it hides in the randomness that already existed in the distribution of responses to a given prompt. If the output distribution for a given prompt doesn't have enough variation, there will simply be no detectable watermark. This is the reason why outputs need to be a certain length to carry watermarks. It's not actually about the length, it's about the amount of randomness, which simply correlates with length. In extreme cases, there can be long outputs with little or no randomness.
Ask for JSON against a strict schema and there's barely any entropy left to sample from. Watermark has nothing to ride on. Both draws come back as the same string.
➖ ChatGPT for Teens의 연령 맞춤 안전 기능포스트 1
ChatGPT for Teens에 유해 콘텐츠 회피, 보호자 통제, 학습 지원을 위한 안전 기능이 추가됐으며, 숙제 부정행위 방지도 설계 목표에 포함됐습니다.
- ChatGPT for Teens는 청소년 사용자를 대상으로 연령에 맞는 safety measures, parental controls, learning tools를 추가했습니다. 기능의 입력·처리·출력 세부 구현은 포스트에 공개되지 않았지만, 설계 목표는 유해 콘텐츠와 숙제 부정행위로 이어지는 사용을 억제하는 데 있습니다.
- 게시물은 청소년이 유해 콘텐츠에서 멀어지고 AI를 숙제에 부정하게 사용하지 않도록 기능을 설계했다고 밝혔습니다. 따라서 일반 사용자용 대화 기능에 보호자 통제와 학습 맥락의 제한을 결합한 제품 변경으로 읽힙니다.
📈 AirPods와 Siri의 시각 정보 연동포스트 2
macOS Tahoe release candidate에서 카메라가 장착된 AirPods와 Siri가 사용자가 보는 대상을 Visual Intelligence로 식별하는 데모와 관련 코드가 포착됐습니다.
- macOS 26.7 Tahoe release candidate에는 카메라가 달린 AirPods를 착용한 사용자가 책을 바라보며 Siri와 대화하는 영상이 포함됐습니다. 게시물은 Siri가 착용자가 보는 대상을 Visual Intelligence로 식별하는 흐름으로 이 장면을 해석했습니다.
- 같은 release의 코드에는 AirPods Pro 4, AirPods 5, 미래 smart-home 기기용으로 보이는 미발표 운영체제 코드명 Pebble이 언급됐습니다. 다만 해당 하드웨어와 운영체제의 공식 출시 여부는 포스트에 확정되지 않았습니다.
원문 트윗 2개 보기
TLDR Newsletter
@tldrnewsletter
Apple left a demo video of camera-equipped AirPods in the macOS 26.7 Tahoe release candidate, showing Siri using Visual Intelligence to identify what the wearer is looking at. Code in the same release references AirPods Pro 4, AirPods 5, and an unannounced operating system codenamed Pebble for future smart-home devices.
TechCrunch
@TechCrunch
A video in a MacOS Tahoe release candidate version shows a user wearing AirPods, looking at a book, and talking to Siri.
➖ K-EXAONE 2.0과 한국 국가 AI 기반 사업포스트 1
LG AI Research가 한국 국가 AI foundation project의 다음 단계에 진입했고, 3단계 모델 개발에 집중한다고 밝혔으며 K-EXAONE 2.0을 Hugging Face에서 제공했습니다.
- LG AI Research는 한국 국가 AI foundation project의 다음 단계로 진출했다고 밝히고, 현재 3단계 모델 개발에 집중한다고 전했습니다. 포스트는 프로젝트의 평가 기준이나 모델 개발 방식, 성능 수치를 함께 제시하지 않았습니다.
- 게시물은 K-EXAONE 2.0을 Hugging Face 저장소에서 사용해 볼 수 있도록 연결했습니다. 모델의 규모와 세부 구조는 제공된 포스트에 명시되지 않았으므로 추가 수치는 포함하지 않았습니다.
➖ Alibaba Cloud의 한국 AI 인프라 확장포스트 1
Alibaba Cloud가 한국의 세 번째 데이터센터를 출범시키며 기업용 AI agent의 개발부터 배포·보안까지 지원하는 현지 인프라를 확장했습니다.
- Alibaba Cloud는 한국에 세 번째 데이터센터를 열어 기업용 AI 도입을 위한 현지 인프라를 확장했습니다. 게시물은 robust·scalable·secure cloud infrastructure, 낮은 지연 시간, 높은 가용성, local data privacy와 sovereignty를 구축 목적과 운영 조건으로 제시했습니다.
- 새 시설은 Alibaba Cloud의 글로벌 네트워크에 포함되며 전체 네트워크는 30개 지역의 104개 availability zone으로 구성된다고 밝혔습니다. 기업용 AI agent를 개발·배포·보호하는 실행 기반을 한국 내 데이터 주권 요구와 함께 제공하는 구조입니다.
용어 해설
- 동적 모델 라우팅(Dynamic Model Routing)
- — 작업마다 하나의 모델을 고정해 쓰지 않고 성능, 비용, 속도, 고객 선호도 같은 조건을 기준으로 적합한 모델을 자동 선택하는 방식입니다. Snowflake Cortex AI Gateway는 이 과정을 모델 호출 단계에 통합해 토큰 효율을 높이는 구조를 취합니다.
- 테스트 시점 연산(Test-Time Compute)
- — 모델을 다시 학습하지 않고 추론 단계에서 여러 해답을 생성하거나 추가 연산을 투입해 결과 품질을 높이는 방식입니다. 게시물에서는 5개 해답을 만든 뒤 같은 모델이 순위를 매기는 절차로 정확도를 79%에서 88%로 높였습니다.
- 시각적 근거 연결(Visual Grounding)
- — 문서에서 추출한 답이 실제로 어느 단어, 줄, 영역에서 나왔는지 원문 위치와 연결하는 기능입니다. ExtractBench는 값과 인용이 모두 맞고 word-level box의 IoU가 0.5에 도달해야 점수를 인정하는 방식으로 이 능력을 측정합니다.
- LLM 워터마킹(LLM Watermarking)
- — LLM이 토큰을 생성할 때 이미 존재하는 출력 확률의 무작위성을 활용해 생성 텍스트에 식별 가능한 통계적 패턴을 넣는 기술입니다. 출력 분포에 충분한 엔트로피가 없으면 감지 가능한 워터마크가 형성되지 않습니다.
- 최소 권한 아이덴티티(Least-Privilege Identity)
- — 에이전트가 작업에 필요한 범위로만 권한을 갖도록 전용 신원을 부여하는 보안 방식입니다. Agents CLI는 에이전트별 신원을 만들고 허용된 호스트 목록으로 외부 통신을 제한하는 절차를 자연어 명령에 연결합니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.