Finisky Garden

Today, I encountered a strange issue in Windows 11 where the D drive was visible in the Disk Management tool but not in File Explorer. I searched online for many solutions, such as updating drivers in Device Manager, disabling and re-enabling the device, using diskpart to delete and recreate the partition, changing the volume label, changing the drive letter, etc., but none worked.

Problem Description

• A new D drive, visible in diskmgmt.msc Disk Management, everything seemed normal. It could even be accessed in File Explorer (though the drive wasn’t displayed in the left sidebar).
• The D drive could be used normally, such as via the command line.
• Changing the drive letter to “E” or another letter made it visible in File Explorer, but switching it back to “D” caused it to disappear again.

今天遇到Win11中 D 盘在磁盘管理工具中显示可用，但在文件管理器中却不可见的诡异情况。网上搜了许多方案，如在设备管理器中更新驱动，禁用再启用设备，用diskpart重新删除新建分区，改卷标改盘符等等都不好使。

问题描述

• 新建D盘，在diskmgmt.msc磁盘管理器中可见，一切正常。甚至能打开文件浏览器（只是左栏不显示磁盘）
• D盘可正常使用，如在命令行中使用
• 修改盘符为“E”或其他盘符，文件浏览器中就可见了，但改回“D”又会消失

Use az cli to query multiple fields of VM information. Here we need to use JMESPath language to implement it.

Typically, we will use az vm show to get the detailed VM information:

$ az vm show -g Linux -n alpha -d -o table
Name    ResourceGroup    PowerState    PublicIps     Fqdns    Location    Zones
------  ---------------  ------------  ------------  -------  ----------  -------
alpha   Linux            VM running    11.1.111.111           eastasia    1

搜索系统的评估和调优很大程度上依赖于相关性标签——这些标签标注了某个文档对特定搜索和搜索者是否有用。理想情况下，这些标签来自真实的搜索用户，但要大规模收集这些数据非常困难，所以典型的实验依赖于第三方标注人员，但他们也可能产生不准确的标注。标注质量一般通过持续的审核、培训和监控来管理。

微软（Bing搜索组）在SIGIR'24提出了一种“反其道而行之”的方法：从真实的用户获取反馈，并利用这些反馈来选择一个与之相符的LLM及其提示词，然后令该LLM大规模地产生标签。实验表明，LLM的准确性与人工标注者相当，并且在找到最佳系统和最难的查询方面同样有用。

[SIGIR2024] # Large Language Models can Accurately Predict Searcher Preferences

大语言模型在各种与语言相关的任务中表现出了显著的零样本泛化能力，包括搜索引擎。然而，现有的工作主要利用LLM的生成能力进行信息检索，而不是直接进行段落排序。这篇EMNLP2023的论文(Outstanding Paper)研究了LLM是否擅长搜索排序的问题。

# Is ChatGPT Good at Search? Investigating Large Language Models as Re-Ranking Agents

之前写过深度检索模型的介绍：# 深度文本检索模型：DPR, PolyEncoders, DCBERT, ColBERT，今天来看看DeepMind在NeurIPS 2024上的文章，对多向量检索模型（Multi-Vector Retrieval）ColBERT进行了改进：

Rethinking the Role of Token Retrieval in Multi-Vector Retrieval

多向量检索模型由于使Query与Doc进行词元级别的交互，因此在许多信息检索基准测试中达到了SOTA。然而，其非线性评分函数无法扩展到数百万个文档，这就需要一个三阶段的推理过程：通过词元检索检索初始候选，访问所有词元向量，并对初始候选文档进行评分。非线性评分函数应用于每个候选文档的所有词元向量，使得推理过程复杂且缓慢。XTR 引入了新的目标函数，鼓励模型首先检索最重要的文档词元，对词元检索的改进使得 XTR 可以仅使用检索到的词元来对候选文档排序，而不是文档中的所有词元，因此其成本比 ColBERT 低两到三个数量级。在流行的 BEIR 基准测试中，XTR 在没有任何蒸馏的情况下，将 NDCG@10 提升了 2.8。

主要改进点：

• 仅使用检索到的doc token而非全部doc token进行相似度计算
• 解决了检索训练和推理之间的gap

最近读到一篇有趣的文章，讨论了当前许多新的AI搜索产品是否会取代Google：

Here’s why AI search engines really can’t kill Google

先简要地看下这篇文章在说什么：

如果要取代Google，那么这些新的产品必须可以完成Google能做的所有事情。于是，作者先收集了Top100的Google搜索查询，然后将它们输入到当前最好的一些AI搜索产品中。作者认为，虽然在某些情况下，基于LLM的搜索比一页Google搜索结果有用，但在大多数情况下，AI搜索取代Google还是相当困难的。

In WinSCP, I found that when uploading file to the server, the file doesn't have a temporary filename extension ".filepart".

Enable temporary filename for all files in "Preferences -> Transfer -> Endurance" still does not work.

After upgrading Ubuntu 20.04 LTS to Ubuntu 22.04LTS, the server always freezes after ~10 minutes. All services are down, cannot ssh, connect to serial console but cannot input. However, this issue never happen before release upgrade.

Cannot believe that Word has such a bug: when tracking changes, wildcard replacement cannot correctly work.

I want to batch replace English parentheses with Chinese parentheses, so I use wildcard replacement:

Find What: \((*)\)
Options: Use Wildcards
Replace With: （\1）

For example, for "(abc)", the expected result is "（abc）", however, the result is "abc（）".