想象一下你是一名试图解决棘手问题的软件工程师。你知道官方教科书（学术论文）中存有答案，但现实世界中的“街头智慧”——那些快速修复方法、变通方案，以及关于行业内实际发生了什么故障的最新传闻——却隐藏在互联网那些杂乱、无序的角落里。这被称为灰色文献（Grey Literature）。这就像是在寻找最好的食谱时，不是去翻阅食谱大全，而是在成千上万篇博客文章、论坛帖子和 GitHub 评论中寻找。
问题在于？寻找这些瑰宝就像是在一个不断变形的草堆中寻找特定的针头。来源随处可见，格式各异，而且手动操作极其耗时。
于是有了 GLiSE（发音同 "glissade"，意为平滑的滑动）。这是一个全新的数字工具，旨在成为你的个人“灰色文献猎手”。以下是它的工作原理，分为简单的几个步骤：
1. 魔法提示词（“下单”）
你不需要分别在 GitHub、Stack Overflow 和 Google 上输入复杂的搜索字符串，你只需要输入一个简单的句子来描述你的需求。
- 类比： 把这想象成在餐厅点一份定制餐点。你不需要知道食材是如何烹饪的；你只需要告诉厨师（GLiSE）你想吃什么。
- 它做什么： GLiSE 会将你的简单句子立即转化为 GitHub、Stack Overflow 和 Google 能理解的特定“语言”或搜索代码。
2. 寻宝游戏（“收集”）
一旦 GLiSE 拥有了你的定制搜索代码，它就会派出由数字侦察兵组成的团队去访问这些网站。
- 类比： 想象一群图书管理员同时奔向不同的图书馆（GitHub、Stack Overflow、Google），抓取所有符合你描述的书籍。
- 它做什么： 它会从这些来源中提取标题、片段和描述。它足够聪明，能够识别出是否抓取了重复的“书”，并忽略重复项。
3. 智能过滤器（“分类”）
这是最重要的一部分。侦察兵带回了数百个结果，但其中许多可能是垃圾信息或无关内容。GLiSE 使用一个“大脑”（机器学习）来筛选优劣。
- 类比： 想象一位非常严格的管家，阅读侦察兵带回的每一本书。管家会将每本书的内容与你的原始订单进行对比。如果一本书讲的是“烤面包”，而你要求的是“修车”，管家就会把它扔进垃圾桶。如果它完美匹配，则将其排到队伍的最前面。
- 它是如何工作的： 该工具将文字转化为数学“指纹”（称为嵌入/embeddings）。它将你的请求指纹与每个结果的指纹进行比较。如果它们看起来相似，它就会保留；否则，它就会丢弃。
结果：它有效吗？
开发者用一小组软件工程师和研究人员对这个工具进行了测试。他们让这些人完成两次相同的研究任务：一次是用传统方式（手动搜索），另一次是使用 GLiSE。
- 速度： 使用 GLiSE 就像从步行切换到了驾驶。参与者找到第一个有用结果所需的时间减少了约 39%。
- 效率： 如果手动寻找 10 个好的结果，人们需要查看大约 25 个项目。而使用 GLiSE，由于该工具过滤掉了噪音，他们平均只需查看 1 个 项目。
- 满意度： 用户对该工具给出了很高的评价（81 分，满分 100 分），表示它非常有用，并且他们愿意再次使用。
核心结论
GLiSE 是一个自动化处理寻找现实世界软件建议这类枯燥、杂乱工作的工具。它将一个模糊的想法转化为精确的搜索，收集结果，并使用智能过滤器只为你展示最相关的信息，从而为研究人员和工程师节省了大量在互联网中挖掘的时间。
本文档并不声称：
- 它并不声称完全取代人类判断；它只是加速了搜索过程。
- 它并不声称适用于医学或临床研究（它是专为软件工程构建的）。
- 它并不承诺永远完美；开发者承认，未来需要更多数据来让这个“管家”变得更加聪明。
技术摘要：GLiSE
问题陈述
灰色文献（例如博客、GitHub Issues、Stack Overflow 讨论和技术文档）对于软件工程（SE）研究至关重要，因为它们捕捉了学术会议中往往缺失的不断演进的行业实践、失败案例和社区规范。然而，由于来源异构、格式不统一、元数据稀疏以及缺乏标准化的、可重复的搜索流水线，大规模系统性地收集和评估此类文献仍然十分困难。现有的方法主要依赖于手动操作或即兴编写的脚本，这限制了研究的可重复性和覆盖范围。此外，通用的 AI 驱动搜索工具（如聊天机器人）缺乏严谨的基于证据的综合研究所必需的透明度、可追溯性、源目标定位能力和可配置性。
方法论
本文介绍了 GLiSE，这是一个由提示词驱动、基于机器学习的工具，旨在实现软件工程领域灰色文献的自动化提取、过滤和排序。该工具通过以下三个步骤的工作流运行：
查询提取 (Query Extraction)：
- 输入： 描述研究意图的自由文本提示词。
- 过程： 通过 OpenAI API 调用大语言模型（LLM），根据提示词和用户定义的约束条件（时间范围、语言、来源选择）生成特定平台的搜索查询语句。
- 输出： 为特定来源定制的结构化查询：
- GitHub： 利用原生限定符（如
in:description, is:issue）针对仓库描述、README 和 Issues 进行检索。
- Stack Overflow： 生成带有标签约束和信号（如已接受回答）的标题/正文查询。
- Google 搜索： 使用
site 和 filetype 操作符构建表达式。
- 可重复性： 所有生成的查询均可导出和导入。
API 调用与数据获取 (API Calls & Data Acquisition)：
- 该工具针对所选来源的公开 API 执行生成的查询。
- 处理分页、重试和溯源追踪。
- 提取核心元数据（URL、标题、摘要）和特定来源的数据（如 README、元描述）。
- 基于 URL、标题和摘要进行近重复检测。
相关性分类 (Relevance Classification)：
- 嵌入 (Embedding)： 将文本字段（标题、摘要、README）和原始搜索意图转换为向量嵌入，使用 OpenAI 的
text-embedding-3-small 或 text-embedding-3-large 模型。
- 特征工程： 系统计算项目嵌入与意图嵌入之间的语义相似性特征。测试的特征包括余弦距离 (Cosine distance)、欧氏距离 (Euclidean distance)、L1 距离、元素级绝对差值以及元素级乘积。
- 分类： 机器学习分类器（针对每个来源和嵌入模型进行训练）预测每个项目的相关性。
- 排序： 根据分类器预测的相关性概率或置信度得分对项目进行排序。
核心贡献
- GLiSE 工具： 一个端到端的自动化系统，用于从 GitHub、Stack Overflow 和 Google 搜索中搜索、过滤和提取灰色文献，并采用基于配置的设置以实现完全的可重复性。
- 精选数据集： 一个包含 1,137 条搜索结果及其对应搜索意图的手动标注数据集，并将结果分类为相关或不相关。该数据集涵盖四种来源类型：GitHub 仓库、GitHub Issues、Stack Overflow 和网页搜索。
- 经验可用性研究： 一项涉及五位软件工程专业人士和研究人员的评估，对比了手动搜索与 GLiSE 辅助搜索的效果。
结果
模型性能
作者进行了探索性研究，以选择最优的嵌入维度（512, 1024, 1536）、特征组合和分类器（高斯朴素贝叶斯、逻辑回归、XGBoost、线性支持向量机、岭回归）。
- 最佳表现者： 最优配置因来源而异。例如，对于 GitHub Issues，使用
text-embedding-3-small 和“所有距离”特征的 GaussianNB 表现最佳（平衡准确率：0.72）；而对于 Stack Overflow，使用 text-embedding-3-large 和“元素级绝对差值”特征的 Ridge 表现最佳（平衡准确率：0.76）。
- LLM 基准： 研究评估了一个基于 LLM 的基准（gpt-4o），但由于其成本更高、速度更慢且整体性能低于专门的机器学习分类器，因此未被采用。
可用性研究
五位参与者完成了两项研究任务（一项手动，一项使用 GLiSE）。结果显示了显著的效率提升：
- 首次发现相关项所需时间 (TTFR)： 从 158 秒（手动）减少到 96 秒（GLiSE），降低了 39%。
- 找到 10 个相关项所需的项目数 (IT@10)： 手动寻找 10 个相关结果平均需要检查 24.8 个项目，而使用 GLiSE 仅需 1 个项目。
- 总筛选时间： 从 20.0 分钟 缩短至 2.5 分钟。
- 用户体验： GLiSE 的系统可用性量表 (SUS) 得分为 81.0，超过了“良好”可用性的阈值 (68)，接近“优秀”。感知有用性和重用意愿平均均为 6.0/7。
重要性与主张
本文声称 GLiSE 通过提供一个可重复、透明且针对特定来源的框架，解决了自动化灰色文献提取中的关键空白。与通用的 AI 搜索工具不同，GLiSE 提供：
- 控制力： 用户可以直接控制搜索配置和来源选择。
- 可追溯性： 对检索过程具有完全的可见性，包括生成的查询语句和溯源信息。
- 可扩展性： 能够处理大规模结果集，并利用轻量级机器学习模型而非昂贵的 LLM 推理来高效过滤项目。
作者将 GLiSE 定位为迈向系统化、基于证据的软件工程研究的一步，使其能够有效地利用工业灰色文献中所蕴含的“实时”证据。他们也承认了局限性，例如相关性的主观性质以及数据集规模较小，并指出未来的工作将侧重于扩大数据集、整合更多来源，以及开发用于评估检索项目可信度的机制。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。