目前是一个最基础的框架，不管是嵌入还是向量检索都粒度非常的粗。
我想先加一个Ragas对目前的效果进行评估，方便和未来优化后的做对比。
Ragas 的评估需要四个要素：

  1. question: 用户的问题。
  2. ground_truth: 人工写的标准答案（你需要自己准备几条）。
  3. answer: 你的 RAG 系统生成的回答（你现在的代码只有检索，没有生成，我们需要补上这一环）。
  4. contexts: 检索到的文档原文（注意：你之前的 search_similar 只返回了 ID 和分数，Ragas 必须要看原文内容才能判断检索准不准）。
    但是我没有标准答案，因为我不可能看过所有论文。我想到的办法是先用比较牛的AI读论文，然后让 AI 出题考 RAG 系统。
    这叫 “自动化评估集构建（Automated Evaluation Pipeline）”。在简历上写这一条，比写“人工标注数据”要高级得多，因为这代表你具备 MLOps（机器学习运维） 的思维。

读取你的文档，然后利用大模型自动生成三种数据：

  1. Question: 根据文档内容生成的复杂问题。
  2. Ground Truth: 该问题的标准答案。
  3. Context: 答案在原文中的出处。

感觉是有点道理的，但是我没法收集所有和某个需求有关的论文。一个需求又怀疑是不是没有普适性，不知道够不够。

前者，小样本能说明的是：假设数据库里有这篇论文，你的代码能把它精准地捞出来吗？可以验证链路的健壮性，业务数据覆盖度不是我能做好的事情。只要我的系统在“已有的 50 篇论文”上表现完美（Recall 很高），我就有理由相信，当我把数据库扩容到 500 万篇时，你的检索逻辑依然是成立的（虽然那时候会面临性能问题，但那是架构师的事，不是实习生的事）。

所以我要先做一个pdf阅读的功能，把一篇论文的内容做成相关度不一的需求。然后根据需求测试是不是能在700篇论文里每次都把这篇捞出来。

后者，我应该根据论文去选取不同维度的样本空间，生成不同种相关度的需求，而不是仅仅测试更多需求和论文。

还有幻觉问题，我应该问一些跟这些论文领域相关，但论文里通过只字未提的问题。RAG 应该返回 **”相关度低”**，而不是强行编造一个答案。

但是我需要一种工作温度超过800度的涂料，漏了怎么办。设计了 Metadata Extraction（元数据提取） 环节：

  1. 在论文入库时，我会先用一个轻量级的 LLM（或正则表达式）快速扫一遍全文。
  2. 提取关键指标（如：温度、精度、算法复杂度、核心材料）作为结构化标签（Metadata），存入向量库的元数据字段中。
  3. 虽然向量是用摘要生成的，但过滤（Filter）是可以基于全文提取的元数据的。

这样既保留了向量检索的高信噪比，又避免了因为摘要信息不全导致的‘关键参数漏召回’问题。”

具体实现

uv run --with ragas --with "numpy<2.0" python test_ragas.py
uv 是最近由 Rust 编写的 Python 包管理器，速度比 pip 快 10-100 倍，而且它的依赖解析算法更智能，能瞬间告诉你具体是哪个包冲突了，而不是傻傻地回溯。

用这种方式解决了包依赖的问题，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# /// script
# requires-python = ">=3.10"
# dependencies = [
#     "ragas",
#     "numpy<2.0",
#     "sentence-transformers>=2.3.0",  # 关键：强制升级它
#     "chromadb",
#     "langchain",
#     "openai",
#     "python-dotenv",
#     "torch",  # 向量计算通常需要它
#     "PyPDF2==3.0.1",
# ]

# ///

但是最终测试结果是
NFO:main:总测试用例数: 2
INFO:main:成功找到期望论文: 0
INFO:main:成功率: 0.00%
第一反应是库里有100篇论文，粗排召回50篇，我只对前10篇精排，是不是太少了
第二反应是我在对需求进行llm提取的时候，只提出了学术词语而把某些场景的给漏掉了，更贴合场景的论文被排在了后面

前一个先不管他，因为应该要想办法提高匹配度，而不是靠召回率去实现召回。
第二个在解决了泛化问题以后
[[prompt]]
（卧槽了，好像其实是因为我没有建立索引。）