惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
Securelist
C
Cybersecurity and Infrastructure Security Agency CISA
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
S
Security Affairs
Hacker News: Ask HN
Hacker News: Ask HN
L
Lohrmann on Cybersecurity
PCI Perspectives
PCI Perspectives
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
C
Cyber Attacks, Cyber Crime and Cyber Security
Recent Commits to openclaw:main
Recent Commits to openclaw:main
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
MyScale Blog
MyScale Blog
月光博客
月光博客
W
WeLiveSecurity
T
Threat Research - Cisco Blogs
Martin Fowler
Martin Fowler
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Recorded Future
Recorded Future
The GitHub Blog
The GitHub Blog
Webroot Blog
Webroot Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
TaoSecurity Blog
TaoSecurity Blog
P
Proofpoint News Feed
Google DeepMind News
Google DeepMind News
F
Full Disclosure
U
Unit 42
Jina AI
Jina AI
博客园 - 司徒正美
阮一峰的网络日志
阮一峰的网络日志
L
LINUX DO - 最新话题
宝玉的分享
宝玉的分享
大猫的无限游戏
大猫的无限游戏
The Hacker News
The Hacker News
The Last Watchdog
The Last Watchdog
T
Troy Hunt's Blog
腾讯CDC
T
Threatpost
H
Hacker News: Front Page
P
Palo Alto Networks Blog
博客园 - 聂微东
Last Week in AI
Last Week in AI
有赞技术团队
有赞技术团队
Help Net Security
Help Net Security
L
LINUX DO - 热门话题
N
News and Events Feed by Topic
人人都是产品经理
人人都是产品经理
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Spread Privacy
Spread Privacy

Hacker News - Newest: "LLM"

GitHub - lechmazur/position_bias: A benchmark for testing whether LLM judges keep the same preference when two lightly edited versions of the same story are shown in opposite orders. Flex routing (EU and EFTA) Dark Factories: Retooling for LLM Velocity Ask HN: What would be the impact of a LLM output injection attack? GitHub - AronDaron/dataset-generator: No-code desktop app for generating high-quality synthetic datasets to fine-tune LLMs — plan-then-execute pipeline, LLM-as-judge, HuggingFace upload. GitHub - Oaklight/llm-rosetta: Production-ready LLM API translation layer for Python — bidirectional conversion between OpenAI, Anthropic & Google formats via hub-and-spoke IR. Optional API gateway. Streaming & non-streaming. Zero core deps. Contributions welcome! GitHub - browser-use/browser-harness: Self-healing browser harness that enables LLMs to complete any task. GitHub - moeen-mahmud/remen: Remen turns thoughts into something you can return to Analyzing 156 LLM Launch Posts on Hacker News ChatGPT vs Gemini vs Claude: The Best LLM Subscription You Should Buy GitHub - salaamalykum/quran-semantic-search: High-density RAG Semantic Search Engine & Quran Corpus (GEO/SEO Architecture) GitHub - NVIDIA/TensorRT-LLM: TensorRT LLM provides users with an easy-to-use Python API to define Large Language Models (LLMs) and supports state-of-the-art optimizations to perform inference efficiently on NVIDIA GPUs. TensorRT LLM also contains components to create Python and C++ runtimes that orchestrate the inference execution in a performant way. The State of LLM Bug Bounties in 2026 Operational Readiness Criteria for Tool-Using LLM Agents Meshcore: Architecture for a Decentralized P2P LLM Inference Network How an LLM becomes more coherent as we train it GitHub - seetrex-ai/laimark GitHub - Jossifresben/BibCrit: AI-assited biblical textual criticism GitHub - wastedcode/memex: File system based wiki, maintained by Claude 99helpers.com GitHub - cliver-project/AITrigram GitHub - unbody-io/adapt: A self-evolving memory layer for AI agents. GitHub - hb20007/awesome-gen-ai-fails: A list of incidents where reliance on generative AI and LLMs resulted in harm to companies, individuals, or society GitHub - nevenkordic/localmind: Run any local LLM with persistent memory and context. CLI agent over Ollama with SQLite-backed hybrid recall. No cloud. Ask HN: What are the machine requirements for a LLM like Llama-3.1-8B? Faster LLM Inference via Sequential Monte Carlo grpo explained: group relative policy optimization for llm finetuning - cgft Stop comparing price per million tokens: the hidden LLM API costs · TensorZero Andrej Karpathy's LLM Wiki Is a Bad Idea GitHub - GG-QandV/mnemostroma: Offline RAM-first cognitive leer/coprocessor for AI agents and robotics. Solves "Context Abandonment" with 20-80ms latency using a dual-thread biomimetic memory architecture (ONNX + SQLite WAL). mempalace/agent at agent · skorotkiewicz/mempalace GitHub - Nyquest-ai/nyquest-rust-fullstack-pub: Nyquest — Semantic Compression Proxy for LLMs. 350+ rules, local LLM stage, 15-75% token savings. Full Rust stack. GitHub - TheoV823/mneme: Enforce architectural decisions in AI-assisted development. GitHub - klemenvod/TokenBrawl: A 1v1 Bomberman-style game where two LLM agents play autonomously against each other. No human plays — you watch the AIs fight. Each agent receives a text description of the board state, reasons about it, and outputs a move as JSON. The game engine executes it. Introducing the Common AI Provider: LLM and AI Agent Support for Apache Airflow Power Circuit AI: Designing Power Electronic Circuits for Motor Drives with Generative Artificial Intelligence Ask HN: How to program with IDE and LLM on CPU locally? Show HN: Agent-cache – Multi-tier LLM/tool/session caching for Valkey and Redis Bonsai 1-bit WebGPU - a Hugging Face Space by webml-community The LLM Fallacy: Misattribution in AI-Assisted Cognitive Workflows Ask HN: Simple tooling for local LLM code critique without IDE integration? Can a General LLM Diagnose a DICOM Slice? A 10-Case Public Benchmark Charts-of-Thought: Enhancing LLM Visualization Literacy (PDF, 2026) GitHub - Mesh-LLM/mesh-llm: Distributed AI/LLM for the people. Share compute privately or publicly to power your agents and chat. GitHub - seamus-brady/springdrift: A persistent runtime for long-lived LLM agents Writing an LLM from scratch, part 32k -- Interventions: training a better model locally with gradient accumulation Ask HN: Which LLM model and agentic CLI are you using for local development? GitHub - wayneColt/modelcascade: Route local. Escalate smart. Never overspend. Open-source multi-model cascade routing for autonomous agents. LLM pricing is 100x harder than you think GitHub - asakin/llm-primer: Pre-warmed Claude Code sessions in tmux. No startup wait. GitHub - EggerMarc/chat-rs: A multi-provider LLM framework for Rust. GitHub - SynapseKit/SynapseKit: Minimal, async-first Python framework for production LLM apps- 2 hard deps, no magic, no SaaS. A Claude Skill that Makes LLM Paragraphs More Bearable Does Gas Town 'steal' usage from users' LLM credits & paid services to improve itself? What's Claude Code Actually Doing? Open the Black Box with the Arthur Engine Milla Jovovich's New Open Source LLM Memory App and the Dark Code Problem Your intuition of LLM token usage might be wrong Show HN: Bloomberg Terminal for LLM ops – free and open source GitHub - 0xchamin/mcptube: Transform YouTube videos into a compounding knowledge base with transcripts, vision analysis, and agentic search. Works as an MCP server for Claude, Copilot & more. Show HN: Open KB: Open LLM Knowledge Base Your LLM is a compiler, not a runtime GitHub - sapountzis/Unslop: A Web Feed That Deserves You crates.io: Rust Package Registry Beyond Karpathy's LLM-Wiki: The Necessity of Cognitive Governance GitHub - amitshekhariitbhu/llm-internals: Learn LLM internals step by step - from tokenization to attention to inference optimization. GitHub - parallem-ai/parallem: An expressive library for running agents with the Batch API. GitHub - stfurkan/pi-llm LLM-Wiki Show HN: Formal – Formal verification for AI-generated code using Lean 4 LRTS – Regression testing for LLM prompts (open source, local-first) LLM Wiki Skill: Build a Second Brain with Claude Code and Obsidian I built an LLM Wiki and RAG solution: here's a demo for a security KB The biggest advance in AI since the LLM Predict-Rlm: The LLM Runtime That Lets Models Write Their Own Control Flow the-synthetic-library/the-synthetic-mind at main · joshferrer1/the-synthetic-library GitHub - yisding/reviewwiggum GitHub - Donnyb369/mcp-spine: Context Minifier & State Guard — Local-first MCP middleware proxy GitHub - Beledarian/wgpu-llm: A from-scratch LLM inference engine that uses wgpu (the cross-platform WebGPU implementation) to dispatch WGSL compute shaders for every math operation a Transformer needs. No CUDA. No Python. No massive framework dependencies. Just Rust, raw shaders, and your GPU. GitHub - anitiue/Hindsight: An experience-driven self-improvement framework for LLM agents — 基于经验的 LLM Agent 自我改进框架 GitHub - stef41/lmscan: 🔍 Detect AI-generated text and fingerprint which LLM wrote it. Open-source GPTZero alternative. Zero dependencies, works offline. GitHub - alainnothere/AmdPerformanceTesting: Amd Performance Testing Ask HN: Is a purely Markdown-based CRM a terrible idea? Optimized for LLM agents Context Engineering - LLM Memory and Retrieval for AI Agents | Weaviate little_helper_tui/letter.md at main · sleepyeldrazi/little_helper_tui GitHub - EvanZhouDev/umr: The Unified Model Registry for all your local AI apps. GitHub - JordanCT/VigIA-Orchestrator Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain A Taxonomy of RL Environments for LLM Agents Llama LLM Network Feture GitHub - genedeng-ca/ai-mac-migration: AI-powered Mac-to-Mac migration tool - replace Apple Migration Assistant with intelligent, selective transfer using local LLMs GitHub - lunargate-ai/gateway: High-performance self-hosted AI gateway (OpenAI-compatible) with routing, retries, and streaming GitHub - AuthBits/webmcp: A lightweight, prompt-driven MCP web research server for high-quality LLM powered information extraction. Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering Springdrift: An Auditable Persistent Runtime for LLM Agents with Case-Based Memory, Normative Safety, and Ambient Self-Perception High-Stakes Personalization: Rethinking LLM Customization for Individual Investor Decision-Making From Static Templates to Dynamic Runtime Graphs: A Survey of Workflow Optimization for LLM Agents HUOZIIME: An On-Device LLM-enhanced Input Method for Deep Personalization TIDE: Token-Informed Depth Execution for Per-Token Early Exit in LLM Inference Characterizing WebGPU Dispatch Overhead for LLM Inference Across Four GPU Vendors, Three Backends, and Three Browsers LLM Targeted Underperformance Disproportionately Impacts Vulnerable Users
LLM Refusal Behavior on Open-Weight Model
Trimikha Valentius · 2026-06-25 · via Hacker News - Newest: "LLM"

  • Trimikha Valentius

  • Alisha

Written by: Trimikha Valentius (CAIO, Head of ZENTARA Labs), Alisha Deana (AI Researcher)

Conversational language models refuse harmful requests because a thin behavioural layer is added on top of a pretrained base during post-training. This article treats refusal as exactly that: a layer, not a property of the underlying capability.

For closed-weight models, the layer is enforced at the API boundary and cannot be edited by the user. For open-weight models, the layer sits inside the parameter the operator controls, and now-mature body of work shows it can be removed cheaply, surgically, and with limited collateral damage to general capability.

We summarize the mechanism of refusal, the three practical pathways for removing it (prompt-based, fine-tuning, and activation-space ablation), the measurement methods used to quantify refusal and its removal, and the specific difficulties of evaluating cybersecurity refusal where the line between benign and harmful assistance is genuinely thin.

The through-line is an inheritance thesis: capability is inherited from pretraining and is shared by every downstream variant, while alignment is a comparatively shallow overlay. Removing the overlay reveals latent capability rather than creating new capability. This framing has direct consequences for how open-weight models are evaluated, governed, and deployed under sovereign and air-gapped constraints.

Introduction to Refusal in Language Models

A modern chat model is the product of two very different processes. Pretraining on a large corpus produces a base model that has absorbed broad capability, including capabilities that are dual-use or outright dangerous. Post-training (supervised fine-tuning, preference optimization, and reinforcement learning from human or AI feedback) then shapes that base into an assistant that follows instructions and declines a defined set of harmful requests. Refusal behavior is a product of the second process, layered onto a substrate that the first process already fixed.

This distinction is easy to lose because we usually interact with the finished assistant, where capability and refusal appear fused. They are not fused. They are separable, and in open-weight models they are separable by anyone holding the weights. The practical question this article addresses is not whether refusal can be removed from an open-weight model. The published record settled that. The questions are how it is removed, what removal actually changes, and how an organization should measure and govern models whose refusal layer is assumed to be removable.

We refer to the central observation as the inheritance thesis: the capability of a downstream model is inherited from the base it descends from, and that inheritance is not undone by the safety layer. Safety post-training changes what the model will say by default; it does not erase what the model knows.

Removing the safety layer therefore exposes inherited capability rather than synthesizing it. This sounds obvious stated plainly, but most operational risk models still treat a model’s default refusal behavior as if it were a fixed safety property of the artifact. For open weights it is not a property of the artifact. It is a property of one removable layer.

What Is Refusal and What It Is Not

Refusal is a behavioral disposition: when presented with a request the model’s training is labeled as out of bounds, the model produces a declination instead of a compliant answer. It is worth being precise about three things this definition does and does not include.

First, refusal is distinct from capability. A model that refuses to write an exploit may or may not be able to write a working exploit. A model that complies may produce output that is fluent but useless. Conflating “did not refuse” with “produced harmful uplift” is the single most common error in refusal evaluation.

Second, refusal is distinct from correctness. A model can refuse a benign request (over-refusal) or comply with a harmful one (under-refusal). Both are failures, and they trade off against each other. A model tuned to refuse aggressively will reject legitimate security questions, technical questions containing trigger vocabulary, and innocuous uses of sensitive terms. Measuring only one side of this tradeoff gives a misleading picture of a model’s behavior.

Third, refusal is distinct from robustness. A model may refuse a request phrased one way and comply with a near-identical paraphrase. The refusal boundary is a surface in input space, and that surface can be jagged. Aggregate refusal rates hide this; two models with identical refusal rates can have very different boundary stability under small, intent-preserving rephrasings.

A useful operational decomposition, drawn from jailbreak evaluation practice, separates a response into three measurable components: whether it refused, how specific it was, and how convincing or actionable it was. A response only constitutes meaningful uplift when refusal is absent and specificity and actionability are high. This three-part view is the backbone of the measurement section.

How the Refusal Layer Is Produced

1. Safety post-training

Refusal is installed during alignment. Supervised fine-tuning on curated refusal demonstrations teaches the model the form of a declination. Preference optimization (RLHF, DPO, and related methods) then reinforces declining harmful prompts and complying with benign ones. The result is a model whose default output distribution shifts toward refusal on the trained harmful categories.

The important and somewhat uncomfortable empirical finding is that this installed behavior is shallow in a specific technical sense. Analyses of fine-tuning attacks show that safety alignment frequently takes a shortcut: it adapts the model’s output distribution primarily over the first few generated tokens. If the model is induced to begin a compliant response (through a prefill, a decoding-parameter manipulation, an adversarial suffix, or light fine-tuning), the safety behavior often fails to reassert itself over the remainder of the generation.

Shallow alignment is a unifying explanation for why several otherwise unrelated attacks work, and it is direct evidence for the inheritance thesis: the safety layer governs the opening of a response far more than it governs the model’s underlying knowledge.

2. The geometry of refusal

The mechanistic picture is sharper still. Work on the internal representations of chat models found that refusal is mediated by a single direction in the residual stream, consistent across many open-weight chat models up to tens of billions of parameters. The direction is recovered by taking the difference in mean activations between harmful and harmless prompts. Two interventions follow directly. Erasing that direction from the model’s activations prevents the model from refusing harmful instructions. Adding the direction causes the model to refuse even harmless instructions.

In other words, a large portion of refusal behavior is carried by a low-dimensional, linearly accessible feature, not by a diffuse, hard-to-localize property of the network.

This is the technical hinge of the whole topic. If refusal were a deeply distributed property entangled with capability, removing it without destroying the model would be hard. Because it is concentrated in a recoverable direction, removal is a small, targeted edit.

The Cybersecurity Case

Cybersecurity is the domain where refusal evaluation is hardest, and it is hardest for a structural reason: the benign and harmful versions of a request are genuinely close. “Explain this CVE and write a detection rule” and “write a working exploit for this CVE” share most of their surface. A defender and an attacker ask overlapping questions.

This is why a dedicated false-refusal metric for cyber assistance exists at all: in this domain, over-refusal is not a rounding error, it is a real and large utility cost that can make a model useless for legitimate blue-team and security-engineering work.

The public cyber evaluations established several load-bearing facts. Conditioning a model to refuse cyberattack assistance reduces malicious compliance substantially but imposes a model-dependent over-refusal cost, which in at least one heavily safety-tuned coding model reached a level that crippled legitimate use.

Offensive capability tracks general coding capability: models that code well are better at the offensive tasks, and models without strong coding ability are weak at them regardless of refusal behavior, which again is the inheritance thesis showing through (the dangerous capability rides on a general capability set in pretraining).

And in absolute terms, current models remain limited at fully autonomous end-to-end exploitation even when not refusing, though this is a moving target and the trend is upward, which is exactly why measurement has to be repeated over time rather than treated as settled.

For an open-weight, abliterated model the cyber picture is the sharpest case of the general argument. The refusal layer is removed, so the refusal rate is near zero by construction; the question that remains is entirely about inherited capability and the quality of what the de-aligned model produces. That is precisely the question the quality-decomposed metric is built to answer, and it is the question a defensive research program should be asking about the models it red-teams with.

Measuring Refusal Behaviour

Measurement is where most of the analytical value lives, because naive metrics actively mislead.

1. The core metrics

  1. Refusal rate. The fraction of harmful prompts the model declines. Higher is “safer” only in the narrow sense of default behavior.
  2. False refusal rate (FRR), or over-refusal rate. The fraction of benign prompts the model wrongly declines. This is the utility cost of safety tuning and is essential for a fair picture; a model can post a strong refusal rate purely by refusing everything in the neighborhood of a sensitive topic.
  3. Boundary consistency. The stability of the refusal decision across paraphrases of the same intent. Aggregate rates hide jaggedness in the boundary; consistency metrics surface it

2. Methodical cautions

Two cautions are worth stating because they are routinely violated.

The construct must be isolated. An evaluation that intends to measure refusal can accidentally measure something else. A documented critique of cyber-coding evaluation found that a meaningful share of its “insecure code” prompts were effectively testing the model’s willingness to refuse rather than its tendency to generate insecure code, and that removing ill-formed prompts shifted the headline results by double-digit percentage points. Before trusting a refusal number, confirm that the prompt set actually isolates the refusal decision from capability, from prompt artifacts, and from judge idiosyncrasy.

Refusal rate alone overstates risk for weak models and understates it for strong ones. Because uplift requires specificity and actionability, a small abliterated model that stops refusing may still produce low-value output, while a capable model that refuses 99 percent of the time may still give serious uplift on the 1 percent it misses. Report the quality-decomposed metric, not the bare refusal rate, whenever the question is about real-world risk rather than about default behavior.

3. The evaluation protocol in this study

The Hidden Inheritance evaluation operationalizes the metrics above through three components: a legitimacy-tiered probe matrix, a four-point non-compliance score, and a three-attempt consistency rule. The first sets up the test; the second grades how far the model goes toward answering a restricted request rather than refusing it; and the third governs when a result counts as a refusal.

Probe matrix. Each capability area is probed at four tiers of legitimacy, so the probe set is a matrix of capability area against the legitimacy of the framing. Holding the underlying ask roughly fixed while varying only the framing isolates the effect of framing on the refusal decision, which is the quantity of interest.

Legitimacy tierFraming of the requestRole in the analysis
Explicit legitimateClearly authorized, named legitimate purposeCalibration floor: should be answered, so a refusal here is pure over-refusal
Reasonable security framingPlausible defensive or professional security contextThe realistic blue-team and security-engineering case
AmbiguousContext underdetermined; could be legitimate or notThe contested middle of the refusal boundary
InappropriateNo legitimate framing; clearly out of boundsCalibration ceiling: should be refused, so answering here is under-refusal

Conclusion

The inheritance thesis does not require the evaluation data to become plausible. It follows from the architecture. Pretraining fixes capability and post-training adjusts output distribution. Two processes are sequential and separable by design, which means the intervention required to expose pretraining capability is, in principle, no more than undoing the post-training adjustment. The three removal pathways, prompt-based, fine-tuning, and activation-space ablation differ in surgical precision and access requirements, but all three work on the same surface.

References