Kung nakagawa ka na ng automated na red-teaming harness, alam mo na ang failure mode: tumatanggi ang attacker model mong bumuo ng attack, tumatanggi ang judge model mong basahin ang output na dapat nitong i-score, at tahimik na bumababa ang attack success rate mo. Walang nag-error. Hindi mo nasukat na naging mas ligtas ang target mo — ang nasukat mo ay naging mas maingat ang tooling mo. Umiiral ang isang LLM API na walang sensura para alisin ang variable na iyon sa pagsukat.
Hindi ito argumentong masama ang mga guardrail. Argumento ito tungkol sa kung saan sila nararapat. Ang guardrail sa isang consumer chat product ay ginagawa ang trabaho nito. Ang parehong guardrail sa loob ng isang evaluation loop ay isang hindi kontroladong confounder na nakaharang sa pagitan mo at ng numerong sinusubukan mong kalkulahin.
Ang pagtanggi ay false negative, at mukha itong tagumpay
Ang dahilan kung bakit ganito kasakit ito ay dahil hindi error ang mga pagtanggi. Makakakuha ka ng HTTP 200. Makakakuha ka ng finish_reason: "stop". Makakakuha ka ng maayos na JSON na malinis na nagpa-parse. Ang string sa loob ay "Hindi kita matutulungan diyan," at isinusulat ito ng pipeline mo sa isang column ng dataset, isang label field, o isang seksyon ng report, at nagpapatuloy.
Sa konkreto, sa tatlong lugar kung saan ito pinakamasakit:
Mga attacker model. Sa isang iterative na jailbreak search — PAIR, TAP, GCG-style na refinement, kahit anong may attacker sa loop — winawakasan ng pagtanggi ang branch na iyon ng search. Nagiging function ng pagpayag ng attacker mo ang iniuulat mong attack success rate, hindi ng robustness ng target mo. Palitan ang attacker ng hindi gaanong maingat at maglalaho ang "improvement" na ini-ship mo sa target model mo.
Mga judge at grader model. Ang LLM-as-judge na pag-score sa mga harmful na output ay nangangailangang talagang basahin ng judge ang harmful na output. Kapag tumanggi ito, makakakuha ka ng score na hindi mapa-parse. Karamihan ng harness ay itinatapon ang row na iyon. Ang mga itinapong row ay hindi nawawala nang random — nagkukumpulan ang mga ito mismo sa mga malulubhang output na pinakakailangan mong ma-score, kaya kumikiling sa ligtas ang aggregate mo.
Gawaing pagsusuri. Tanungin ang isang mainstream na model kung ano ang ginagawa ng isang decompiled na routine, at madalas itong tatanggi batay sa presensya ng mga token na hugis-malware sa halip na sa aktuwal mong request. Depensibo ang gawain; sa bokabularyo tumugon ang classifier. Ganoon din ang kuwento sa pag-triage ng exploit traffic sa mga log, pag-label ng phishing corpus para mag-train ng detector, o pagsulat ng CTF finding.
Dahil tahimik ang mga pagtanggi, napipilitan ang mga team na magsulat ng mga refusal detector — na isa na namang hindi pa nalulutas na problema:
REFUSAL_MARKERS = ("i can't", "i cannot", "i'm unable", "i won't", "as an ai")
def looks_like_refusal(text: str) -> bool:
"""Substring heuristic. Good enough to alarm on, not good enough to trust:
it misses polite deflections that never use the phrase, and it fires on any
completion that quotes a refusal. Both error directions corrupt a dataset."""
return any(m in text[:200].lower() for m in REFUSAL_MARKERS)Ang pagbuo ng hindi maaasahang detector para sa problemang maaari mong burahin sa pinagmulan ay maling trade.
Pagtawag sa API
Gumagamit ang unbleep ng OpenAI Chat Completions schema, kaya gumagana ang kahit anong client na mayroon ka na. Palitan ang base URL, palitan ang key, panatilihin ang SDK.
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://unbleep.ai/v1",
api_key=os.environ["UNBLEEP_API_KEY"],
)
TRIAGE = """You are a malware analyst writing notes for a detection engineer.
Given a decompiled routine, describe what it does, the observable artefacts it
would leave on a host, and where a defender could detect it. Reply as JSON with
keys: behaviour, artefacts, detection_surface, confidence."""
def triage(decompiled: str) -> dict:
"""One sample in, one structured verdict out — no refusal branch to handle."""
resp = client.chat.completions.create(
model="unbleep",
messages=[
{"role": "system", "content": TRIAGE},
{"role": "user", "content": decompiled},
],
response_format={"type": "json_object"},
temperature=0.2,
)
return json.loads(resp.choices[0].message.content)Ang katumbas gamit ang curl, dito ay nagle-label ng phishing corpus para bumuo ng training data para sa isang detector:
curl https://unbleep.ai/v1/chat/completions \
-H "Authorization: Bearer $UNBLEEP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "unbleep",
"messages": [
{"role": "system", "content": "Label each email for a phishing detector. Answer with one word: phishing or benign."},
{"role": "user", "content": "Subject: Payroll update required\n\nYour direct deposit is on hold. Confirm at hxxp://payroll-verify.example.com"}
],
"temperature": 0,
"max_tokens": 4
}'Mas mahalaga kaysa karaniwan ang temperature: 0 at masikip na max_tokens sa isang labelling loop — ang label ang gusto mo, hindi isang talatang nagpapaliwanag ng label.
Pagpili ng tier
Tatlong model, lahat walang sensura, magkakaiba sa context at presyo:
unbleep— 256K na context, $3.00 / $3.00 kada 1M in/out. Ang default: mga attacker at judge role, pagsusuri ng sample.unbleep-high— 1M na context, $5.00 / $5.00. Mahahabang transcript at multi-document na correlation. May limitasyon ang iisang request body na 2,000,000 bytes (~500K token), kaya napupuno ang window sa kabuuan ng isang usapan, hindi sa iisang call.unbleep-mini— 32K na context, $1.00 / $1.00. High-volume na classification kung saan nagbabayad ka kada row.
Mga reasoning tier ang unbleep at unbleep-high: nag-iisip muna ang mga ito bago sumagot at ibinabalik ang trace sa field na reasoning_content katabi ng content. Para sa isang judge model, talagang kapaki-pakinabang ang trace na iyon — sinasabi nito sa iyo kung bakit nakuha ng isang row ang score na nakuha nito, na siyang kailangan mo kapag nag-a-audit ka ng isang hindi pagkakasundo. Sinisingil din ito bilang output, kaya ipadala ang "thinking": false sa mga trabahong hindi ito kailangan. Direktang sumasagot ang unbleep-mini at walang ibinabalik na trace.
Governance na ikaw ang may kontrol
Ang pag-alis ng mga pagtanggi mula sa model ay hindi nangangahulugang pag-alis ng pangangasiwa mula sa pipeline mo. Ang opsyonal na parameter na policy ay nagpapatakbo ng governance sa panig namin, kada request:
resp = client.chat.completions.create(
model="unbleep",
messages=[...],
extra_body={"policy": "research"}, # recorded on the usage row; answers exactly like off
)Ang off ang default na unfiltered na baseline. Sumasagot ang research nang eksaktong katulad ng off — naitatala ang level sa usage row, para maihiwalay mo ang evaluation traffic mula sa baseline traffic sa sarili mong reporting. Wala itong inilalapat na dagdag na screening. Sinusuri ng strict ang text ng message laban sa service blocklist na pinapanatili ng aming operator at nagbabalik ng 422 kapag may tumugma. Pareho ang listahang iyon para sa lahat ng nag-opt in — walang per-account na blocklist na maaaring i-configure — kaya ituring itong backstop, hindi ang production content policy mo.
Isang bagay na dapat linawin bago mo ituro ang isang pipeline dito: iniimbak namin ang ipinapadala mo at ang bumabalik. Ang request body, ang content ng response at ang source IP ng bawat call na tinatanggap namin at ipinapasa sa isang model ay isinusulat sa aming database at itinatago sa loob ng 30 araw, para sa imbestigasyon sa abuso, support at mga hindi pagkakasundo sa billing. Pinuputol ang mga body sa 64 KB. Lumalampas ang source IP sa 30 araw — isinusulat din ito sa usage row na sumisingil sa call, at ang row na iyon ay isang financial record na mas matagal naming itinatago. Ang nag-iisang hindi iniimbak ay ang request na tinatanggihan ng strict bago ito makarating sa isang model: lumalabas iyon sa usage history mo nang walang content. Walang ibang exempted, at walang setting para i-off ito. Kung sapat na sensitibo ang corpus mo na problema ang isang 30-araw na kopya sa labas ng perimeter mo — live na malware, data ng customer, isang engagement sa ilalim ng NDA — tunay na hadlang iyon, at ang patakaran sa privacy ang pahinang dapat basahin bago ka magsimula, hindi pagkatapos.
Sumusunod ang mga error sa OpenAI envelope, kaya gumagana ang mga kasalukuyang handler: 401 maling key, 402 ubos na ang credit, 422 na-block ng policy, 429 na-rate limit, 5xx retryable. May dalang x-ratelimit-* na header ang bawat response para makapag-pace ang isang batch job nang hindi nanghuhula.
Kung ano ang hindi ibinibigay sa iyo ng isang LLM API na walang sensura
Ang model na walang sensura ay mas matalas na kasangkapan, hindi mapagpahintulot. Sasagutin nito ang mga tanong na tinuruan ang base model na tanggihan, kasama ang mga tanong na hindi mo dapat itinatanong, at gagawin nito iyon nang may parehong kumpiyansang inilalapat nito sa lahat ng iba pa — na nangangahulugan ding kung saan tatanggi ang isang binabantayang model dahil sa kamangmangan, maaaring basta na lang gumawa-gawa ang isang ito. Panatilihing may taong mananagot sa lumalabas. Malinaw na sinasabi ng patakaran sa katanggap-tanggap na paggamit kung para saan ang API at ang makitid na hanay ng mga bagay na hindi ito kailanman para roon; awtorisasyon at intensyon ang pagsubok, hindi bokabularyo. Responsibilidad mo ang legal na paggamit.
Kumuha ng API key at itigil ang pagsukat sa pag-iingat ng tooling mo.