假如你正在做心理健康领域的文本挖掘，比如从社交平台公开语料中识别“注意缺陷多动障碍（ADHD）”相关症状，你会发现一个典型的工程困境：用户表达极其口语化，“脑子一团浆糊”“事情永远拖到最后”“明明想专注却坐不住”，这些句子和标准症状词表几乎没有重合词，传统关键词检索大概率直接漏掉；而如果把全部候选都交给大模型逐一打分，又面临推理成本、延迟和上下文长度三重压力。
eRisk 2026 Task 3 的“ADHD 症状句子”任务，本质上就是这样一个信息检索与排序问题：给定症状查询，从用户生成内容中找回相关句子。从团队方案 “DS@GT-ARC” 的题目看，它走的是一条值得单独拆解的技术路线——Sparse、Semantic 和 LLM Reranking 三段式管道。这篇文章不打算复述竞赛论文，而是把它当成一个完整 NLP 工程案例来分析：为什么要用混合召回，为什么要靠大模型兜底精排，管道里哪些环节最容易踩坑，以及一套能直接在自己数据集上跑起来的最小实现。
读完你会得到三个东西：一是对信息检索中 Sparse/Semantic/LLM Reranking 三件套的清晰理解，二是一套可复制的 Python 检索管道代码，三是心理健康文本场景下沉甸甸的工程建议。
1. 这篇文章真正要解决的问题
先说结论：ADHD 症状句子检索，表面看是一个文本分类或语义匹配问题，实际更贴近“句子级信息检索”。系统拿到的是某条症状描述（比如 inattention、executive dysfunction），要在一个很大的候选取证库里找出表达该症状的句子。难点有两个层面。
第一层是语义鸿沟。ADHD 人群的文字表达往往不直接使用 DSM-5 里的临床术语，而是用生活化、情绪化的语言描述体验。比如“我经常把作业拖到最后一刻才做”表达的是 procrastination 和执行功能障碍，但和“procrastination”这个词没有字面交集。经典 BM25 在这类场景下会大面积漏召回。
第二层是长尾工程成本。嵌入模型能部分缓解词汇鸿沟，但对“包含明显症状信号、需要结合语义语境判断”的句子，向量相似度并不总可靠。最理想的做法是把候选句子全部丢给参数量更大的 LLM 去判断，但在真实数据集上，候选量可能是几万甚至几十万条，逐条生成式打分的时间和 API 费用不可接受。
于是有了这条业界已经验证过多次的架构：先用稀疏检索和语义检索做高效召回，得到一个小规模的候选集合，再用 LLM 在候选集上做精细重排。DS@GT-ARC 方案的核心就是这个思路，它不是某个孤立技巧，而是一套可以复用到搜索、RAG、比赛任务上的通用范式。
什么样的读者最需要这篇文章？如果你在做 RAG 检索优化、对话系统知识召回、心理健康文本分析，或者想参加类似评测任务但不想从零试错，那么这篇文章里的概念拆解、管道设计和代码实现，能帮你少走很多弯路。如果你只想快速了解大模型重排序怎么做，第 5 节的代码可以直接复用。
2. Sparse、Semantic 与 LLM Reranking：三个关键概念
2.1 稀疏检索 Sparse Retrieval
信息检索里最早被大规模使用的就是稀疏表示。它的核心思路是对文本做词项切分，然后用词频、逆文档频率等统计量给每个词加权，最终用向量表示一篇文章，其中大部分维度是 0，所以叫“稀疏”。
BM25 是目前最经典的稀疏排序函数。它的公式里有两个关键参数：k1 控制词频饱和度，b 控制文档长度归一化程度。近义词“无法集中注意力”和“很难专注”在 BM25 看来是两套完全不同的词，它们的相似度为 0，这是稀疏检索的致命短板，即词汇鸿沟问题。
但稀疏检索依然被广泛使用，原因是三个字：稳、快、省。它不需要 GPU，不需要提前训练模型，对精确术语、专有名词、医学术语的匹配非常可靠。在健康文本场景下，“ADHD”“hyperfocus”“RSD”这类词，BM25 能精确命中。在一个混合检索管道里，BM25 的价值更多是保证底线召回，确保那些语义模型可能忽略的稀有词不被漏掉。
2.2 语义检索 Semantic Retrieval
语义检索的思路和稀疏检索完全不同。它不再依赖词面重合，而是把句子整体映射到一个稠密向量空间中，让语义接近的句子距离更近。常用实现是基于 Transformer 的嵌入模型，比如 Sentence-BERT、E5、BGE 系列。
以 Sentence-BERT 为代表的 Bi-Encoder 结构，查询和文档分别编码为两个向量，再用余弦相似度计算相关性。这种设计的优点是可以提前把文档向量化并建索引，查询时只需编码 query 一次，然后做向量检索，性能很好。它在很多场景下能克服词汇鸿沟，比如“脑子像浆糊”和“思维迟缓”虽然词面完全不同，但在语义空间里可能是相近的。
缺点是嵌入模型对领域数据敏感。通用预训练模型可能不理解 ADHD 相关的特殊表达、网络俚语和口语化症状描述。所以实际做语义召回时，要么选择在心理健康语料上继续训练过的模型，要么准备一批领域内相似样本做领域自适应微调。另一个问题是嵌入模型对否定、程度副词等细节不够敏感，“我没有注意力问题”和“我有注意力问题”的向量可能非常接近。
2.3 LLM 重排序 LLM Reranking
重排序阶段使用的 LLM，可以是闭源 API，也可以是本地部署的开源模型。它不再像 Bi-Encoder 那样把查询和文档分别编码，而是把查询和候选句子拼在一起，让模型直接判断相关程度。因为模型能看到完整上下文，所以它对语义细节、否定、反讽、隐含症状的判别能力明显更强，这就是“精排”的意义。
LLM 重排序在实现上大体有三种策略：
- Pointwise：让模型对每个候选句子独立输出一个相关度评分。逻辑最简单，适合第一版跑通。
- Pairwise：一次给模型两个候选句子，让它输出更相关的那一个。理论上精度更高，但比较次数多，总调用量成倍增长。
- Listwise：把多个候选句子一起输入模型，让它输出一个排序后的列表。性能最优但受上下文窗口限制。
从比赛和工程实践来看，先用 Pointwise 做初筛，再用 Pairwise 或 Listwise 做最后微调，是比较稳妥的节奏。考虑到候选集通常已经通过召回压缩到几十条以内，即使每条候选调用一次 LLM，成本也可控。
这里还要提一个容易混淆的点：Cross-Encoder（交叉编码器）经常被混进“LLM Reranking”。两者思路类似，都是把查询和文档拼接后共同编码，但 Cross-Encoder 通常指 BERT 规模的判别式模型，输出一个相关性分数，而标题里说的 LLM Reranking 更多指生成式大模型通过指令或打分 token 判断相关性。工程上，如果预算紧张，可以先用小型 Cross-Encoder 精排，再用大模型只处理 Top-10，性价比最高。
2.4 三者的关系与分工
用一个简单类比来理解三者关系：假设你要从一个大型仓库里找“描述拖延症”的文件。稀疏检索相当于先看每份文件里有没有“拖延”“deadline”“进度”这些字眼，快的代价是会漏掉“我一直在刷手机却不想动”这种表达。语义检索像一个有经验的图书管理员，能根据大概意思找到相似内容，但偶尔也会把无关内容误拿进来。LLM 重排序则像最后请来一位专家，把前两步找出来的候选文件挨个精读，最终给出可信的判断。
所以整条管道是互补关系，不是替代关系。三者配合的意义在于：用最低成本淘汰绝大多数无关数据，再用最强模型保证最终结果质量。这个思想在 Facebook 的 ANN 检索、RAG 主流框架、各类评测任务里几乎成了标准动作。
| 方案 | 匹配粒度 | 优点 | 缺点 | 典型工具 |
|---|---|---|---|---|
| Sparse BM25 | 词项统计 | 无 GPU 要求、精确术语强、可解释 | 词汇鸿沟、无法处理同义表达 | rank_bm25、Elasticsearch |
| Semantic | 句子向量 | 语义近义识别强、可预先索引 | 对领域表达敏感、细节判别弱 | Sentence-BERT、BGE |
| LLM Rerank | 全文本理解 | 上下文理解强、可处理复杂语义 | 成本高、延迟高、依赖调用量控制 | OpenAI API、本地 LLM |
3. 系统架构设计：从 Query 到 Top-K
3.1 整体流程
一个完整的 ADHD 症状句检索系统，大致分为四个环节：查询处理、双路召回、候选融合、LLM 精排。查询处理阶段要做的不是简单把症状词扔进检索器，而是对查询做展开和改写。比如原始查询是“inattention”，可以扩展成“很难集中注意力”“容易走神”“上课听不进去”等表达。查询扩展可以在关键词层面做，也可以借助 LLM 生成同义表达，能明显提升召回率。
双路召回阶段，稀疏检索和语义检索同时运行。两条通道各自返回 Top-K 候选句子，然后做并集融合，去掉重复项。融合时如果某条候选只在一条通道出现，它依然有机会进入精排阶段，这保留了单路模型可能错杀、但另一路能捞回来的可能性。
精排阶段把融合候选集输入 LLM 重排序模块。LLM 逐个判断候选句子与症状查询的相关程度，输出分数。最后按分数排序，取 Top-N 作为最终输出。
3.2 召回阶段：为什么不能只靠一路
很多初学检索的人会把宝压在语义模型身上，觉得有嵌入向量就够了。但只靠语义向量召回往往会遗漏低频、但判别性极强的临床术语。反过来只靠 BM25，长尾表达又会被漏掉。两路召回相当于给系统上了双保险。
实际操作中还要注意两路召回的 Top-K 值设置。如果 Top-K 太小，融合后的候选集可能不够覆盖所有正例；如果太大，后续 LLM 精排的成本会明显上升。比较稳的做法是先分别取 20 到 50 条，跑完精排再看评估指标回退调整。从工程经验看，BM25 的 Top-K 可以比语义检索稍微小一点，因为语义检索贡献的多样性往往更多。
3.3 精排阶段：用 LLM 做“人”的判断
精排是整个系统中对结果质量贡献最大的一环。LLM 的优势在于它能读完整句子并理解上下文。ADHD 症状句子的判断难点往往不是关键词，而是句子所隐含的状态描述。比如“我今天又啥都没干”这句话，单独看很模糊，结合上下文可能是在描述拖延和执行困难，这种情况下 BERT 向量和 BM25 都很难给出高置信度，LLM 却可以结合表达方式做推理。
精排时 Prompt 设计非常关键。要把症状定义、判断标准、评分规则写清楚，最好给一两个正例和负例作为 few-shot 参考。这里最容易犯的错误是让 LLM 直接输出“是/否”，因为句子相关度本来就存在模糊地带，硬二分类会丢失大量信息。给一个连续分数更合理。
3.4 延迟与成本权衡
如果每秒要处理大量查询，把每一条候选都交给大模型打分显然不现实。一个被验证过的工程做法是分层级联：先让嵌入式模型做一个粗排，只把 Top-10 或 Top-20 交给 LLM 做最终重排。这样既控制了成本，又保证核心结果质量。
类似思路在搜索引擎里叫做级联排序，在 RAG 里也是标配。DS@GT-ARC 方案真正有价值的，不是某个单点模型的先进，而是把“高效召回 + 复杂精排”组合成了一个成本和质量都可控的系统。这提示我们：在论文复现时，永远要把工程约束放在第一优先级。
4. 环境准备与前置条件
下面是跑通本文代码所需的基础环境。以 Python 3.9 或 3.10 为主，其他版本也大概率兼容。建议使用虚拟环境，避免污染系统 Python。
python -m venv adhd-rerank-env source adhd-rerank-env/bin/activate pip install --upgrade pip核心依赖库如下：
- rank_bm25：BM25 稀疏检索实现
- sentence-transformers：语义嵌入模型加载与编码
- torch：深度学习框架，安装 CPU 或 GPU 版本按机器情况决定
- openai：调用 OpenAI 兼容接口的客户端库
- tiktoken：token 计数，用于控制提示词长度
安装命令：
pip install rank_bm25 sentence-transformers torch openai tiktoken语义嵌入模型建议选择支持文本匹配任务的通用模型，例如 BGE-small 或 BGE-base。具体的模型名称以实际项目可用版本为准，本文代码里的模型名只是一个占位演示，建议替换成你实际可选用的模型。
如果你希望完全本地化运行 LLM 重排序，也可以用 vLLM 或 llama.cpp 自托管一个开源模型，然后暴露 OpenAI 兼容接口。这样代码无需变化，只需要把 base_url 改成本地地址。这个思路好处是数据不出内网，对心理健康文本场景尤其重要。
数据集方面，eRisk 任务基于真实的社交媒体语料，由于隐私和合规限制，很多原始数据并不公开，但你可以用任何带“句子级标签”的文本构造自己的评测集。最简形式就是一个 JSON 文件，包含查询、候选句子、相关性标签，标签为 1 表示相关，0 表示不相关。后续代码演示都以这种格式为基础。
5. 核心代码实现
5.1 BM25 稀疏召回
先用 rank_bm25 构建一个最简单的稀疏检索器。这里的关键是分词方式。英文直接用空格切分即可，中文场景则建议使用 jieba 分词，否则 BM25 的效果会打折扣。
# 文件路径：sparse_retriever.py from rank_bm25 import BM25Okapi import jieba def tokenize(text: str, language: str = "en") -> list[str]: """按语言选择分词策略。""" text = text.lower().strip() if language == "zh": return list(jieba.cut(text)) return text.split() class SparseRetriever: def __init__(self, corpus: list[str], language: str = "en"): self.language = language tokenized_corpus = [tokenize(doc, language) for doc in corpus] self.bm25 = BM25Okapi(tokenized_corpus) self.corpus = corpus def retrieve(self, query: str, top_k: int = 30) -> list[tuple[str, float]]: tokenized_query = tokenize(query, self.language) scores = self.bm25.get_scores(tokenized_query) ranked = sorted( enumerate(scores), key=lambda x: x[1], reverse=True ) return [(self.corpus[idx], scores[idx]) for idx, _ in ranked[:top_k]]这段代码里，BM25Okapi 初始化时接收已经分好词的文档列表。之后每次查询只需要调用 get_scores 得到所有文档的得分，再取 Top-K。实际工程中如果候选文档很多，应该用 Elasticsearch 这一类倒排索引引擎来做，而不是全量扫内存，但原理一致。
5.2 语义召回
用 sentence-transformers 实现语义检索。先加载嵌入模型，再对查询和文档做向量化。得到向量后，可以用 sklearn 的 cosine_similarity，或者直接对归一化向量做点积。
# 文件路径：semantic_retriever.py from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity import numpy as np class SemanticRetriever: def __init__(self, model_name: str = "BAAI/bge-small-en-v1.5"): self.model = SentenceTransformer(model_name) self.corpus_embeddings = None self.corpus = None def index(self, corpus: list[str]): self.corpus = corpus self.corpus_embeddings = self.model.encode( corpus, normalize_embeddings=True, show_progress_bar=True ) def retrieve(self, query: str, top_k: int = 30) -> list[tuple[str, float]]: query_embedding = self.model.encode( [query], normalize_embeddings=True ) similarity = cosine_similarity(query_embedding, self.corpus_embeddings)[0] ranked = np.argsort(similarity)[::-1][:top_k] return [(self.corpus[idx], float(similarity[idx])) for idx in ranked]语义检索的关键参数是 normalize_embeddings。设为 True 后向量都做了 L2 归一化，此时点积等价于余弦相似度，计算更高效。如果数据量大，应该引入 FAISS 或 Milvus 做 ANN 索引，进一步压缩查询延迟。
5.3 LLM 重排序
LLM 重排序是整条管道里最灵活的一环。这里以 OpenAI 兼容接口为例，用一个 Pointwise 打分函数，让 LLM 输出 0 到 10 之间的相关度分数。
# 文件路径：llm_reranker.py from openai import OpenAI import json class LLMReranker: def __init__(self, api_key: str, base_url: str = None, model: str = "gpt-4o-mini"): self.client = OpenAI(api_key=api_key, base_url=base_url) self.model = model def _build_prompt(self, query: str, candidate: str) -> str: return f""" 你正在辅助一个心理健康症状检测系统。 你的任务是判断【候选句子】是否表达或描述了查询中的 ADHD 相关症状。 查询症状：{query} 候选句子：{candidate} 请根据相关程度输出一个 0 到 10 之间的整数分数。 评分标准： - 10 分：句子直接、明确地描述了该症状。 - 5 分：句子与症状相关，但表达比较模糊或间接。 - 0 分：句子与症状完全无关。 只输出分数，不要输出任何解释。 """.strip() def rerank_sentence(self, query: str, candidate: str) -> float: prompt = self._build_prompt(query, candidate) response = self.client.chat.completions.create( model=self.model, messages=[{"role": "user", "content": prompt}], temperature=0, max_tokens=10, ) raw = response.choices[0].message.content.strip() try: return float(raw) except ValueError: return 0.0 def rerank(self, query: str, candidates: list[str]) -> list[tuple[str, float]]: scored = [] for candidate in candidates: score = self.rerank_sentence(query, candidate) scored.append((candidate, score)) return sorted(scored, key=lambda x: x[1], reverse=True)这段代码有几个值得注意的地方。温度强制设为 0，保证输出稳定可复现。max_tokens 设为 10 而不是默认的很大值，一方面省钱，另一方面也能引导模型尽量只输出分数而不是长篇解释。实际调试时，如果模型经常输出非数字内容，可以在提示词里追加“只能输出整数”这种强约束，同时保留解析失败时返回 0 的兜底。
如果本地部署开源模型，可以把 base_url 指向 vLLM 或 llama.cpp 的服务地址，API 部分不需要改动。这样既能保护心理健康文本的数据隐私，也能显著降低单条打分成本。
5.4 把三段管道串起来
下面这个 Pipeline 类把稀疏召回、语义召回、LLM 精排整合成完整链路。
# 文件路径：pipeline.py from sparse_retriever import SparseRetriever from semantic_retriever import SemanticRetriever from llm_reranker import LLMReranker class RetrievalPipeline: def __init__(self, corpus: list[str], llm_reranker: LLMReranker, language: str = "en", sparse_top_k: int = 30, semantic_top_k: int = 30, final_top_k: int = 10): self.sparse = SparseRetriever(corpus, language=language) self.semantic = SemanticRetriever() self.semantic.index(corpus) self.reranker = llm_reranker self.sparse_top_k = sparse_top_k self.semantic_top_k = semantic_top_k self.final_top_k = final_top_k def retrieve(self, query: str) -> list[tuple[str, float]]: sparse_results = self.sparse.retrieve(query, top_k=self.sparse_top_k) semantic_results = self.semantic.retrieve(query, top_k=self.semantic_top_k) merged = {} for sentence, score in sparse_results + semantic_results: if sentence not in merged: merged[sentence] = score else: merged[sentence] = max(merged[sentence], score) candidates = sorted(merged, key=merged.get, reverse=True) # 为控制成本，先截断到 50 条再交给 LLM candidates = candidates[:50] return self.reranker.rerank(query, candidates)[: self.final_top_k]管道里唯一需要解释的是候选融合策略。这里对重复句子直接取两路得分的最大值，后续你完全可以根据实验把策略改成加权融合或者乘积融合。但第一版用 max 最简单，也便于定位问题。
6. 运行结果与效果验证
6.1 运行方式
准备好语料后，用下面的方式运行完整管道：
corpus = [ "I keep procrastinating on every assignment until the last minute.", "I hyperfocus on random hobbies for hours and forget to eat.", "My brain feels like it's full of fog and noise all the time.", "I bought a new notebook to organize my life but I never use it.", "The weather is nice today and I want to go for a walk.", ] query = "executive dysfunction and procrastination" pipeline = RetrievalPipeline( corpus=corpus, llm_reranker=LLMReranker(api_key="sk-xxx", model="gpt-4o-mini"), language="en", sparse_top_k=30, semantic_top_k=30, final_top_k=3, ) results = pipeline.retrieve(query) for sentence, score in results: print(f"{score:.1f}\t{sentence}")预期输出中，前两条应该明显与拖延和执行功能障碍相关，而“The weather is nice”这类无关句子应该被排到最后。如果运行后出现 API 报错，先检查网络连接、API Key 是否有效、模型名是否被当前服务商支持。
6.2 评估指标
对于检索排序任务，只看最终输出个大概效果是不够的，必须用定量指标衡量。推荐几个从竞赛到工业界都在用的指标：
| 指标 | 含义 | 用途 |
|---|---|---|
| Recall@K | 前 K 条结果中命中的正例数占全部正例比例 | 评估召回能力 |
| Precision@K | 前 K 条结果中真正相关的比例 | 评估精排准确性 |
| MRR | 第一个正例出现位置的倒数均值 | 适合单目标查询 |
| nDCG@K | 按相关等级加权的排名质量 | 最常用于通用排序 |
最稳妥的评测方式是先人工标注一小批测试集，运行管道后计算上述指标。你不需要在初始阶段追求完美标注，哪怕先标 50 个查询，也能暴露不少问题。
6.3 结果判读
如果 Recall@K 偏低，问题大概率出在召回阶段，需要扩大 Top-K、优化查询扩展，或者更换语义嵌入模型。如果 Recall@K 正常但 Precision@K 偏低，问题就在 LLM 重排序阶段，需要检查提示词的评分标准是否模糊、候选集中是否混入大量相似但无关句子。
这里最容易被忽视的是：查全率和查准率在健康文本场景下同等重要。漏掉一个症状句可能意味着错过干预机会，而误判太多又会降低系统可信度。所以指标分析不能只看单一指标。
7. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| BM25 召回结果完全无效 | 分词不合适，中文场景误用空格切分 | 打印 tokenized_corpus 观察分词结果 | 引入 jieba 等专用分词器，处理同义词 |
| 语义召回结果和关键词几乎无关 | 嵌入模型与领域不匹配 | 随机挑几条句子做向量相似度可视化 | 换领域特化模型，或用领域数据微调 |
| LLM 总是输出非数字内容 | 提示词约束不足、模型理解偏差 | 查看模型完整输出内容 | 增加输出格式约束，使用 few-shot 示例 |
| 候选集太大导致 API 成本过高 | 召回 Top-K 设置过大 | 统计每轮查询平均候选数 | 先截断到 20-50 条，再进 LLM |
| 同样查询多次结果不稳定 | 温度参数未设为 0 | 检查请求参数 | temperature=0，必要时固定随机种子 |
| 数据包含个人信息 | 原始社交语料未做脱敏 | 检查语料来源和字段 | 强制脱敏、匿名化，最小权限访问 |
如果你在本地跑通后发现某一类问题反复出现，建议按“召回质量 -> 融合策略 -> 重排序提示词”的顺序逐步排查，不要一上来就改模型，那样只会引入更多变量。
8. 最佳实践与工程建议
结合心理健康文本挖掘和信息检索的长线工程经验，这里给出几条值得写在项目文档里的实践原则。
第一，查询扩展要放在检索之前。原始症状名往往和用户表达存在巨大差异，直接用原始词查询很容易漏检。可以准备一个症状同义词表，也可以让 LLM 为每个症状生成 5 到 10 个用户视角的表达，再把这些表达混入查询。这个步骤对 Recall@K 的提升往往是最明显的。
第二，嵌入模型要领域特化。通用 Sentence-BERT 在新闻、百科语料上表现不错，但面对 ADHD 社群里的黑话、梗和情绪化表达容易失效。三个可行路径：收集一定数量的领域句子对做对比学习微调；选择已经在 Reddit 等社交媒体语料上训练的开源嵌入模型；至少做一次人工评估，确认嵌入模型对典型症状表达的敏感性。
第三，重排序的提示词要写“判断标准”，不要只写“判断”。告诉模型你关注的要素，比如“句子是否描述了注意力缺陷、冲动控制或多动表现”“是否是第一人称的具体经历描述”“是否具有时间持续性”，比笼统地要求“判断相关性”更有效。可以准备两个正例和两个负例放进提示词里做 few-shot。
第四，严格做好隐私合规。心理健康文本属于高敏感数据，无论做比赛还是做产品原型，都要遵循最小权限原则。数据脱敏、访问审计、模型服务内网部署是基本要求。不要为了效果把敏感文本发送到不受控的外部服务。如果必须使用外部 LLM API，优先选择签署了数据保护协议的服务，或者干脆用自托管模型。
第五，评估集要和真实分布对齐。用人工构造的干净句子做测试，往往会让系统看起来比实际好用很多。更靠谱的做法是从真实语料里采样并标注，多包含一些模糊句、否定句和隐喻句。这样模型上线后出现“实验室高分、真实场景崩盘”的概率会低很多。
第六，把管道设计成可插拔。不同任务的融合策略、Top-K 参数、提示词风格差异很大。建议从一开始就把 Sparse、Semantic、Reranker 封装成独立模块，通过配置文件控制超参数，方便后续做消融实验。
9. 总结与后续学习方向
从 DS@GT-ARC 这个方案里，最能直接复用的不是某一行代码，而是“分层治理”的思路。召回层用 Sparse 和 Semantic 互相兜底，精排层用 LLM 保证顶级质量，中间用候选融合和截断控制成本。这套设计在信息检索领域沉淀了很多年，在 RAG、搜索引擎、健康文本分析里反复出现。
顺着这篇文章，下一步你可以做三件事。先把自己手头的小规模语料跑通上面这套最小管道；然后加一个离线评估模块，用 Recall@K 和 nDCG@K 监控每次改动是变好还是变坏；最后尝试把 Pointwise 重排序换成 Pairwise，在 Top-10 范围内体验一下精度和成本的差异。
心理健康领域的文本挖掘还有很多值得深入的方向：针对 ADHD 症状的术语本体构建、多语言社交媒体语料的域适应、结合时间线做早期风险检测，以及把 RAG 能力引入到症状解释和报告生成中。每一项都能和今天的检索管道拼在一起，形成更大的系统。但无论怎么做，第一原则不变：一切效果优化都必须在可控成本、合规数据、可评估的闭环里进行，这样你的系统才不是比赛里的花瓶，而是能真正支撑业务的技术底座。
