2025s on TouchingFish.top

Rust 的"解法"

Sun, 19 Oct 2025 00:00:00 +0000

翻出 2020 年写的 C 语言博客。

数组与指针，内存布局与调试。那时候写得挺认真的，后来还画内存图，标注高地址低地址，解释为什么 arr[3] = 20 能把旁边变量 i 的值也改了。文章结尾写的是：“为避免这种错误，始终要确保在使用数组时不越界访问。”

现在回头看，那句话翻译成人话大概是：你最好别写错。

因为写错了编译器不会告诉你。

学 Rust 的时候，很多东西越看越像是对 C 里那些经典问题的系统性回应。不是"Rust 比 C 好"——是 Rust 把二十年来系统编程中最常见的错误模式，逐个编码进了编译器和类型系统里。一个 Rust 新手在编译期被挡下的问题，可能比一个 C 老手十年遇到的运行时 bug 还全面。

指针三兄弟

NULL、野的、悬空——C 程序员的日常恐惧来源。

int *p = NULL; *p = 1; 编译通过。运行到这一行，操作系统发来 SIGSEGV。不是编译期能发现的事——NULL 是一个合法的指针值，只是指向的地址不可访问。编译器没有语义层面的"这个指针可能为空"的概念。

int* f() { int x = 5; return &x; } 也编译通过。x 在 f 的栈帧里，函数返回后栈帧被回收，返回的地址指向一块随时可能被覆盖的内存。这个地址仍然"合法"——它在一个可访问的内存段内，只是内容不受你控制。有时候打印出 5，有时候打印出随机数，有时候什么都没发生，取决于后续函数调用有没有踩到同一块栈空间。

free(p); *p = 1; 还是编译通过。free 之后那块堆内存被标记为可用，但 p 的值没变，仍然指向原地址。继续通过 p 读写，运气好时数据还没被覆盖，程序照常运行——这比直接崩溃更危险，因为你不知道错误已经埋下了。

Rust 的做法很简单：没有 NULL。没有悬垂引用。没有 use-after-free。

JD 里的 RAG，其实是 LangChain 调参

Tue, 17 Jun 2025 00:00:00 +0000

招聘网站上搜"RAG"，跳出来的 JD 长得都差不多。

熟悉 Retrieval-Augmented Generation。了解向量数据库（FAISS、Pinecone、Chroma）。掌握 Embedding 模型（OpenAI、BGE、M3E）。有 LLM 应用开发经验，熟悉 LangChain / LlamaIndex。

我一开始也以为这是在招算法工程师——那种能从头训练 Embedding 模型、能设计新的向量索引结构、能在论文里挂名的人。

面了几轮才发现，大部分公司要的不是这个。他们想要的是：给你一个文档库，你能用 LangChain 搭一个问答系统，调调参数，让回答别那么离谱。至于向量数据库选 FAISS 还是 Chroma，Embedding 模型选 OpenAI 还是开源的，很多时候只是配置项的问题。

JD 里写的 RAG、向量数据库、Embedding，翻译成人话就是：你会不会用 LangChain 调参。

向量数据库不需要 SQL boys 和 SQL girls，但又不能说不是一回事。它说的就是数据库，只是存的东西不是行和列，而是坐标。没有 JOIN，没有 WHERE。只有"给我找离这个点最近的几个邻居"。

这篇文章从调参的视角，把 RAG pipeline 里每个环节的参数过一遍。不重复基础概念，只讲实际写代码时会遇到的选择。

切

chunk_size 设多少？

RAG 的第一步是把文档切成块。LangChain 里最常用的工具是 RecursiveCharacterTextSplitter。

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=1000,
 chunk_overlap=200,
 separators=["\n\n", "\n", "。", "，", " ", ""]
)

chunk_size

这个参数的单位是 token 数，不是字符数。设得太小，一个完整的句子被拦腰截断，语义支离破碎。设得太大，单个块包含太多主题，检索时容易引入无关信息。

通用文档（论文、报告）：500-1000 tokens
代码：200-400 tokens，按函数或类切分更合理
对话记录：300-500 tokens，保留完整回合

一个容易踩的坑是盲目追求大 chunk。“大一点，信息多一点，模型回答更完整”——听起来对，但检索精度会下降。一个 2000 token 的块可能包含五个段落，用户的问题只匹配其中一段，其余四段都是噪声。

贵州农民收入驱动机制建模记

Sat, 07 Jun 2025 00:00:00 +0000

“本研究以贵州省为典型案例，深入剖析了乡村振兴战略实施过程中农民收入的驱动机制与未来趋势。”

这是那个本科生开题报告里的话。我接到单子的时候，初稿已经在导师手里了，分析也几乎做"完"了，导师给她上了很大的压力。

实际做下来，驱动机制没剖析出什么花来，倒是被多重共线性剖析了一通。

数据

贵州省 2007–2023 年度数据，17 个观测，10 个自变量，1 个因变量：

变量	含义	单位
x1	人均生产总值	元
x2	第一产业增加值	亿元
x3	第三产业增加值	亿元
x4	城镇化率	%
x5	农业支出	亿元
x6	农村居民人均消费支出	元
x7	农业机械总动力	万千瓦
x8	农作物总播种面积	千公顷
x9	有效灌溉面积	千公顷
x10	绝收面积	万公顷
y	农村居民人均可支配收入	元

17 个样本点，10 个自变量。还没开始建模就知道要出事——自由度都快不够了。

（学生说"数据是从统计年鉴上找的"。统计年鉴嘛，省级年度数据就那么多年，变量倒是能找一堆，但样本量是天花板。这不是学生的问题，是这类课题的先天限制。）

第一步：看看相关性

相关系数矩阵一出来，事情就很清楚了：

与 y 的相关系数：

变量	与 y 的 r
x6	0.999
x3	0.996
x1	0.991
x2	0.990
x4	0.983
x7	0.911
x5	0.888
x8	0.689
x9	0.625
x10	-0.361

几乎所有经济指标都和农民收入高度相关。r > 0.9 的变量对有 27 对。这不是"信息丰富"，这是"信息冗余"——大家都在说同一件事。

当你连 scale 也量化了

Fri, 30 May 2025 00:00:00 +0000

上次算到，160 亿参数的模型用 Q4_0 量化后，光 scale 和 $\alpha$ 这些"说明书"就要吃掉 2 GB。

2 GB 不小。一台 16 GB 显存的显卡，模型权重压缩后大概 8 GB，结果说明书自己占了四分之一。这就像你去宜家买了一张桌子，包装盒里一半是螺丝和安装图纸。

K-quants 要解决的就是这个问题。思路很直白——既然权重可以量化，那说明书也可以量化。

套娃

K-quants 的核心结构叫 super-block。做法是把 8 个普通 block 打包成一组，然后对 8 个 scale 再做一次量化——从 FP16（16 bit）砍到 INT8（8 bit）：

super-block: 256 个 INT4 权重
├── block 0: scale = 0.10 (FP16 → INT8)
├── block 1: scale = 0.14 (FP16 → INT8)
├── block 2: scale = 0.11 (FP16 → INT8)
├── block 3: scale = 0.18 (FP16 → INT8)
├── block 4: scale = 0.08 (FP16 → INT8)
├── block 5: scale = 0.16 (FP16 → INT8)
├── block 6: scale = 0.13 (FP16 → INT8)
├── block 7: scale = 0.09 (FP16 → INT8)
└── super-scale = 0.00142 (FP16) ← 新加的，用来还原上面那些 INT8

来走一遍完整的计算。假设这 8 个 block 里 256 个权重已经量化完了——每个 block 的 scale 是上面那 8 个 FP16 值。现在的任务是把这 8 个 scale 自己也量化掉。

当你把模型从16位砍到4位

Mon, 19 May 2025 00:00:00 +0000

第一次在本地跑 Llama 的时候，下载页面那一排 Q4_0、Q4_K_M、Q5_1 让我愣了半天。

选了最大的文件，跑不起来。显存不够。选了最小的文件，跑起来了，但回答像喝了假酒。后来才知道，这一排名字背后是一整套妥协方案——在模型的"胖瘦"和"聪明程度"之间找平衡。

这篇文章讲最早的那套方案：legacy quants。GGUF 现在已经有 K-quants 和 I-quants 了，但 legacy 是地基。搞懂了它，后面那些花里胡哨的变体无非是在这个地基上换砖头。

FP16 和 INT4

在聊量化之前，先搞懂两样东西：模型权重长什么样，以及我们想把它变成什么样。

FP16 是半精度浮点数。16 个 bit（2 个字节），存一个带小数点的数。C 语言里没有 FP16，但你想象一个比 float（32 位）更省空间的浮点数就行。大模型的权重——那些矩阵里的每一个数字——出厂的时候就是 FP16。一个 70 亿参数的模型，70 亿个 FP16，也就是 14 GB。不大不小，刚好塞不进一张 12 GB 的消费级显卡。

INT4 是 4 位整数。4 个 bit，能表示 $2^4 = 16$ 个不同的值。如果你只写过 C，你熟悉的整数是 int（32 位）、short（16 位）、char（8 位）。4 位的整数在 C 里没有——太小了，小到没法单独寻址，必须打包存储。

打个比方：FP16 像女生的口红色号——豆沙、枫叶、烂番茄，每一格都有名字。INT4 是男人的衣柜——黑、白、灰、深蓝，能数的就那几种。

量化的核心问题就是：怎么用男人的衣柜里那几种颜色，还原出口红色号的全部渐变？

这是有损压缩。丢掉的信息永远捡不回来。

假装天平是平的

GGUF 的量化不是把每个 FP16 单独转成 INT4。那样做的话，每个权重需要一个 scale（缩放系数）来告诉你怎么"还原"，而 scale 本身就是 FP16——16 位。用 16 位存 scale 去压缩一个 16 位的权重？没有意义。

毕业后最认真面试的季度

Wed, 30 Apr 2025 00:00:00 +0000

回忆2024年，多少有点不真实。

8月底，某央企的 HR 打来电话，说恭喜通过面试，体检报告过关就发 offer。我攥着手机在房间里站了五分钟。毕业三个月，终于快要有一个正经工作了——虽然是个放射类药物企业，体检等了一个多月还没下文，但好歹有个着落。

11月初，hc 取消。

那个 HR 的声音我现在还能想起来。先是很职业的恭喜，然后是一段不太职业的沉默，最后是"公司战略调整"。六个字，一场空。

硕士读的是生物统计，论文写的是演化博弈。听起来挺唬人——实际上也确实挺唬人的，唬到秋招投了一圈 SAS Programmer，只捞到两次面试，最后拿了一个实习 offer。GCP 证书到手那天，我还认真地觉得自己要入行了。Good Clinical Practice，药物临床试验质量管理规范，翻译成人话就是：药厂认的实验怎么做，它告诉你。

然后就到了2025年。

一季度大概是我整个求职周期里最动荡的一段。不是投简历投得最多的时候——是内心最晃的时候。放弃了一个方向，不知道下一个方向在哪，每天翻招聘网站像翻一本永远写不到结局的小说。

放弃 CRO 不等于那些东西白学了。临床试验的很多概念——随机化、盲法、偏倚、数据标准化——骨子里都在讨论同一件事：怎样在不完美的现实里，尽可能诚实地回答一个因果问题。这个问题的底层逻辑，放到哪个行业都不会过时。

所以还是把这些准备材料整理了一下。

当时为什么学，学的时候卡在哪，面试官问了什么，我怎么答的——答对的、答错的、答不出来的。流水账。有些事情不记下来真的会忘。

面试不问定义

第一场面试，我把随机化的定义背了一遍。

面试官听完，没点头也没摇头。他问：“一个受试者入组后被分到了错误的组，你怎么办？”

我愣了大概五秒。

不是在考定义。是在考你有没有想过实际操作中会出什么花活。那些课本上读不到的角落——系统出错了怎么办，随机表被人为干预了怎么办，发现的时候数据已经入库了怎么办。

后来学乖了。每个概念后面都挂一个问题：“如果出错了呢”。回答一下就有血有肉了。

临床试验的知识点翻来覆去就那些：随机化、盲法、AE 报告、SDTM、中心效应、脱落率。上过 GCP 课的人都能说上几句。面试官想看的是另一层东西——这些概念在真实世界里长什么样，摔过跟头的人才知道。

书本之外

准备面试那阵子，我花了大量时间啃 ICH E6 GCP、FDA 指导原则、统计方法的推导。这些东西当然有用。

真正让我卡住的，是那些书上没有的问题。

“CRO 现在收缩得很厉害，你知道吗？”

“数据管理员和 SAS 程序员的日常工作差在哪？”

“你做过几个项目？用过什么 EDC 系统？”

书本不会告诉你行业寒冬这件事。书本不会告诉你 SAS 在临床数据处理领域的江湖地位正在被 Python 一点点蚕食。书本不会告诉你，某些 EDC 系统的市场份额直接决定了你要不要花时间学它。

（这个问题我到现在也没有好答案。能说的就是：书本上的东西我可以学，行业经验需要时间——给我时间。）

追问是好事

有些面试官喜欢追着问。追到你答不动为止。

第一次被追到哑口无言的时候，恨不得找条缝把自己塞进去。

后来想通了。追问意味着他在认真听。他想知道你是真懂还是背的。

被问到不会的地方，老老实实说"这个我不太确定"，比硬撑着胡说八道强一百倍。

有一次面试官问我 LOCF 的假设。我答错了。他当场纠正了——但没有露出那种"又来了一个背书的"的表情，而是说了一段话：“这个问题，很多做了好几年的统计师都不一定答对。你能往这个方向想，说明你动过脑子。”

那场面试后来有了下文。

（当然也可能只是他比较善良。）

理论是加分项

面试官有时会扔一些开放性问题。

“多中心试验最大的挑战是什么？”

多中心的那些麻烦事

Mon, 10 Mar 2025 00:00:00 +0000

多中心试验（multi-center trial）的名字取得真好听。

多个中心一起招募，样本量涨得快，结论推广起来底气也足。理想状态是：各家中心像精密咬合的齿轮，在同一套 SOP 下匀速运转。

现实是每家中心都是一个小宇宙。操作流程不一样，研究者经验不一样，患者人群不一样。这些差异搅在一起，就能让你吃不了兜着走。

中心效应

中心效应（Center Effect）——不同中心的研究结果之间存在系统性差异。

原因可以是很多层的。人口学特征：A 中心的患者平均比 B 中心大十岁。操作差异：不同的设备、不同的手法、不同的熟练程度。依从性差异：有的中心随访跟得很紧，有的中心患者来一次算一次。

一个经典例子：某抗高血压药物的试验，亚洲中心的降压效果显著，欧洲中心平平。拆开一看——亚洲中心患者 BMI 普遍偏低。不是药在亚洲人身上反应不一样，是基线特征分布不同。

处理中心效应得分两步走。设计阶段用分层随机化——每个中心当一层，层内随机。再搞一套统一 SOP，把操作差异压到最小。分析阶段上混合效应模型（Mixed-Effects Model），“中心"作为随机效应塞进去，中心间差异扒开之后再估治疗效应。顺带查交互效应——有没有"在 A 中心有效、在 B 中心无效"这种诡异场面。最后跑一遍敏感性分析，排除个别中心或调权重，看结论够不够硬。

面试官问过：“捡到显著的中心效应，你怎么办？”

标准套路：先拆原因。是基线差异还是操作差异，还是真的存在治疗×中心的交互。基线差异可以通过调整协变量来补救，操作差异可能要重新培训研究者。

（我嘴上这么说，心里清楚：统计方法能兜住的底是有限的。预防永远比事后修修补补值钱。）

人跑了

脱落（Drop-out）是我准备面试时反复翻的一个话题——它直接咬在统计效能和结论可信度上。

定义：受试者没走完试验全程——要么没接受完预定干预，要么没完成全部随访。

后果三层：效能降低——样本缩了，检测真实效应的力气就小了。偏倚风险——如果脱落不是随机发生的（副反应太让人遭不住的更倾向于退出），整个估计就会歪掉。结果解读——脱落一多，ITT 人群和 PP 人群之间的裂口越来越大。

设计的防线：样本量计算时把脱落的预估塞进去，纳入排除标准把不靠谱的人挡在外面，交通补助、免费检查之类的激励跟上。

执行的防线：随访管理加强，定期提醒别断，脱落原因记录清楚，为后续分析铺路。电话随访、线上访谈做起来——灵活，总比丢失好。

分析的防线：ITT——所有随机化受试者全纳入，不管有没有走完。金标准。缺失数据用 LOCF（末次观察值结转）或多重插补（Multiple Imputation, MI）顶上。

面试官问过我 LOCF 的假设是什么。

“假设受试者最后一次观察的状态会原封不动保持到后续时间点。”

他追问：这个假设靠谱吗？

“通常不靠谱。如果受试者是因为病情恶化才退出的，最后一次观察值可能比真实状态好看。LOCF 会把治疗效果高估。”

（后来我翻了文献。LOCF 在某些场景下确实是保守的，但总体容易引入偏倚。多重插补或者当敏感性分析做更稳妥。）

最后一扇门

数据库锁定（Database Lock, DB Lock）是数据管理的一个关键节点。

锁之前：数据可以改。锁之后：冻住了。任何修改都要走变更流程——不是技术上改不了，是程序上要经过层层审批。

DB Lock 通常发生在所有受试者完成随访、数据清理收尾、锁库前评审通过之后。锁库之后，统计师拉闸开始最终分析，生成临床研究报告（CSR）。

“锁库之后还能改数据吗？”

能。但不叫"改”，叫"走变更流程"。物理上数据还是可以动的，只是每次动都要一群人在审批链上签字。

“什么情况下锁库后必须改？”

SAE 数据录入有误。关键数据录入有误，影响主要终点。还有——面试官给我补了一个场景——监管机构在现场核查时要求更正数据。

这件事我只在书本上瞟到过，面试的时候完全没想起来。坐在对面的面试官不紧不慢地补上了这一刀，我连防御姿势都摆不出来。

写在最后

多中心试验的核心矛盾就一条：控制变异。

中心间差异不会消失——只能通过设计去预防、通过分析去调整、通过监查去发现。脱落是另一个维度的损耗——受试者走了，信息就永远丢了。能做的只是把它写进样本量计算、写进分析计划、写进最后的报告，而不是假装它不存在。承认不确定性，比假装确定诚实得多。

从Epoch和Element搞懂SDTM

Fri, 28 Feb 2025 00:00:00 +0000

随机化和 AE 是临床试验的骨肉，那 SDTM 大概就是血管——把散落各处的数据串成标准格式，送到监管机构面前。

SDTM 的全称是 Study Data Tabulation Model，“研究数据列表模型"这个译名念起来有点硌嘴。翻译成人话就是：数据提交的标准化格式。

FDA 要求所有新药申请（NDA）必须以 SDTM 格式交数据。不是建议。

章节和小节

我啃 SDTM 的时候，第一个绊住我的地方就是 Epoch 和 Element。

简单说：

Element（元素）是试验里最小的连续时间段。有明确的起止条件。比如 Screening（筛选期）——从签知情同意到随机化之前；Drug A Treatment——从第一次给药到最后一次给药；Follow-up（随访期）——从末次给药到出组。每个 Element 有一个代码（ETCD）和全称。

Epoch（时期）是更高一层的划分，用来组织不同的 Element。一个 Epoch 可以装一个或多个 Element。

比如治疗期这个 Epoch 底下可能塞着 Placebo Treatment 和 Drug A Treatment 两个 Element。筛选期就一个 Screening Element。随访期就一个 Follow-up Element。

（我的记忆方式：Epoch 是大标题，Element 是小标题。一章里可以有多个小节。）

为什么非得分两层

因为在 SDTM 的数据集里，它们是分开的。

SE（Subject Elements）数据集记录每个受试者经历了哪些 Element，起止时间是什么。这是连续性的、细颗粒的。

DS（Disposition，受试者处置）数据集只记关键里程碑。它是摘要性质的。

一个受试者可能老老实实走完了 Screening → Treatment A → Follow-up 三个 Element——SE 里三个记录。但在 DS 里可能只抓两个节点：Randomized（随机化），Completed Study（完成试验）。DS 不关心你在治疗期待了多久，SE 会告诉你。

把AE和SAE背下来

Sat, 15 Feb 2025 00:00:00 +0000

不良事件（Adverse Event, AE）大概是临床试验面试里出场率最高的话题。

不是因为它复杂。是因为它直接连着受试者安全——GCP 的心脏。面试官需要确认你对这一块有基本的本能反应，不是临时翻书背的。

你以为是边界，其实不是

Adverse Event (AE)：受试者在试验期间出现的任何不利医疗情况，与研究药物或干预措施未必有因果关系。

四个字咬在最前面：“未必相关”。

什么意思？受试者试验期间出现的任何身体不适——头疼、发烧、血压飙了、平地摔了一跤——不管原因是什么，全部要记录。感冒要记。车祸要记。自己吃坏肚子也要记。

第一次看到方案里 AE 记录范围的时候，我整个人是懵的。

我以为 AE 只记跟药物搭边的反应。结果发现，连受试者周末爬山崴了脚，都要老老实实填进系统。

逻辑是这样的：临床试验的核心任务是评估药物安全性。如果你只记录"看起来可能相关"的事件，那你怎么知道自己有没有漏掉"看起来无关但实际上有关"的事件？事后判断因果关系是统计师和分析师的事情，研究者只管如实记录。

把判断交给数据，把诚实留给现场。

五条标准，一条红线

严重不良事件（Serious Adverse Event, SAE）的定义是固定的。五条：

导致死亡
威胁生命
导致住院或延长住院时间
导致永久性或显著的残疾/功能障碍
导致先天异常/出生缺陷

面试的时候，面试官喜欢出场景题。

“受试者随访期间因为心脏病发作进了 ICU，算不算 SAE？”

算。一条"威胁生命"，一条"导致住院"，双命中。

再来一题更刁的。

“受试者血压控制不好，医生建议住院观察，但受试者拒绝了。算不算 SAE？”

不算 SAE——但需要记成 AE。“导致住院"这个标准的前提是实际发生了住院行为，不是医生动了个念头。

SAE 报告的时限是二十四小时。

从研究者获知 SAE 那一刻开始计时。二十四小时内必须报给申办方。申办方收到之后，还有额外的时限向监管机构汇报——但这第一步，二十四小时，雷打不动。

这个数字是要考试的。

我做了卡片，每天早上对着念一遍：死亡、威胁生命、住院、残疾、先天异常。念到后来做梦都在复读。

（有点病态。备考嘛，谁还没点神经质。）

记录不是一次性的

AE 不是记完就可以翻页的。

研究者要持续随访，直到三件事之一发生：事件解决了（恢复或稳定），受试者失访了，或者事件的根因确认了——比如确定是受试者自己停药导致的停药后事件。

结局（outcome）有几种标准记法：

解决（Resolved）
解决但有后遗症（Resolved with sequelae）
未解决/持续中（Not resolved / ongoing）
解决中（Resolving）
致命（Fatal）

有个容易搞混的地方。“致命"和"导致死亡"是两回事。一个 AE 可以状态是"未解决/持续中”，但随访期间受试者因为别的原因去世了——它被标注为"致命"结局。死亡本身不是 AE，是一个终点。

随机化，被问到不会为止

Sat, 08 Feb 2025 00:00:00 +0000

随机化（Randomization）是临床试验的基石。

这句话我在面试里说了不下十遍。每次说的时候底气都很足——直到面试官开始往下挖。

上统计课的时候，老师讲得轻描淡写：随机化就是让混杂变量在组间均匀分布。掷硬币，分两组，完事。我当时觉得，这有什么难的？

rand = rand("uniform");
group = if rand < 0.5 then "Treatment" else "Control";

一行代码。大样本下组间基线特征自然均衡。简单随机化（Simple Randomization）操作起来也确实这么痛快——每个受试者扔一次骰子，去哪组全凭运气。

问题出在小样本上。

四十个人的试验，随机下来可能是 24 比 16。理论上不偏，但统计效能（power）被削了一块——你本来算好需要二十个对照，实际只拿到十六个，power 就缩水了。

面试官问我小样本用什么方法。

我说分层随机化。

（现在回头想，这个回答不对。应该先想到区组随机化。）

每个区块都是一个小平衡

区组随机化（Block Randomization）是我准备面试的时候啃得最细的一个点。

道理不复杂。把受试者切分成若干"区块"，每个区块内部按固定比例分。比如区块大小是 4，比例 1:1——每四个人里一定有两个试验、两个对照。区块内部严格对称。

这个设计在多中心试验（multi-center trial）里特别好用。A 中心招了三十个人，B 中心只有十个——简单随机化可能让 A 中心变成 20:10，B 中心变成 8:2，摆在一起虽然整体是 1:1，但每个中心内部歪得离谱。区组随机化让每个中心各自维持内部平衡。

前提是区块大小不被猜到。

如果区块固定为 4，研究者看到前三个人的分组就能反推第四个。盲法（blinding）原地作废。

解法：把区块大小也随机化。可以是 4，也可以是 6，随机抽。

面试官追着这个点问。

“区组大小固定的话，会有什么后果？”

我顿了三秒。说，可能造成选择偏倚——研究者会看前面几个人的分组，决定要不要让下一个人入组。

他没接话。

（后来我琢磨，我的方向大概对了一半。猜到分组确实会打穿盲法。但"决定是否入组"这个说法不准确——入组标准是写死的，研究者不应该有裁量空间。真正怕的是他通过控制入组节奏来影响分组：预测下一个会进试验组，就稍微拖一拖。这更接近实施偏倚而不是选择偏倚。）

按特征分堆

分层随机化（Stratified Randomization）解决另一件事。

有些变量对结局影响很大——年龄、性别、疾病分期。小样本里，纯随机可能让这些变量在组间歪掉。分层做法的思路是：先按重要特征切层（60 岁以下/60 岁以上、男/女），然后在每一层内部再做随机。保证每个分层因素在两组之间是平衡的。

面试题经常问：“分层和区组有什么区别？”

分层按受试者特征来，区组按入组先后来。分层管协变量的平衡，区组管各时间点样本量的平衡。两者不互斥——可以先分层，再在层内跑区组随机化。面试的时候如果能说出这个组合用法，大概能加点分。

一时语塞

那场面试没有后续。

我猜是因为答得太虚。概念头头是道，落地一问就露馅。

面试官最后抛了一个开放式结尾：“如果一个中心招募速度特别慢，怎么处理？”

我说，跟中心研究者沟通，了解原因。如果是患者来源问题，调整招募策略或者增加中心。

他说了一句让我记到现在的话。

“CRO 行业现在收缩得很厉害。很多中心不是招不到患者，是申办方没钱了，主动暂停试验。”

我当场石化。

背了那么多术语、方法、最佳实践，到头来被一个行业事实干翻了。统计方法能解决的问题是有边界的——资金、政策、市场周期，这些东西不在任何一本 GCP 教材里。

后来我查了一下，CRO 确实在过冬。不是哪个公司的原因，是整个赛道都在缩。