厉害之处在于融入了物理学规律（爬 wiki 数据）
不足也很明显，该功能仍在初级阶段，期待后续。
有想体验的佬，点下方链接。
]]>
这个方案利用 emby 支持 strm 文件可以快速入库，切通过 openlist 等支持网盘的 302 重定向，实现快速起播，以下内容中提到的所有工具均为开源项目，当然也有其他可选的工具替代，例如 cd2 可以用 rclone 替代，auto_symlink 可以用其他 strm 工具替代，emby2alist 可以用 go-emby2openlist 替代等。(同时也推荐使用 auto_symlink 作者的 symedia 和 fastemby 项目)
目前已知 115 网盘在多个地区或超过一定连接数使用 302 重定向可能会触发风控，想请问下各位是否有更好的解决方案，如是否可以做多网盘资源的负载均衡(也可以推荐相应的 vps 走代理的方式)
mkdir -p /media/docker/alist docker run -d \ --restart=always \ -p 5244:5244 \ -p 6801:6800 \ -e PUID=0 \ -e PGID=0 \ -e UMASK=022 \ --name=openlist \ -e TZ=Asia/Shanghai \ openlistteam/openlist:beta 注意点： 这里映射了两个媒体目录，一个是cloud_media，一个是webdav_media。
cloud_media用于挂载支持 302 重定向的网盘，如 115 ，天翼等；webdav_media用于挂载如夸克网盘等；部署前请确认 docker 已开启 MountFlags 
version: '3' services: clouddrive: image: cloudnas/clouddrive2 container_name: clouddrive restart: unless-stopped environment: - CLOUDDRIVE_HOME=/Config volumes: - /volume2/Media/mp_downloads:/CloudNAS:shared - /volume2/Media/cloud_media:/media:shared - /volume2/Media/webdav_media:/webdav_media:shared - /volume1/docker_dir/clouddrive2:/Config ports: - "8097:19798" pid: "host" privileged: true devices: - /dev/fuse:/dev/fuse 
需注意：
version: '3' services: auto_symlink: image: shenxianmq/auto_symlink:latest container_name: auto_symlink environment: - TZ=Asia/Shanghai volumes: - /volume2/Media/cloud_media/clouddrive:/volume2/Media/cloud_media/clouddrive:rslave # cd2 挂载目录 - /volume2/Media/webdav_media/clouddrive:/volume2/Media/webdav_media/clouddrive:rslave - /volume2/Media/strm:/volume2/Media/strm # emby 扫描媒体目录 - /volume2/Media/webdav_strm:/volume2/Media/webdav_strm - /volume1/docker_dir/auto_symlink/config:/app/config ports: - "8095:8095" user: "0:0" restart: unless-stopped 
需注意：
version: '3' services: emby-server: image: amilys/embyserver container_name: emby-local network_mode: bridge # DLNA and Wake-on-Lan 需要 bridge environment: - UID=0 # 设置容器用户 ID 为 0 (通常是 root) - GID=0 # 设置容器组 ID 为 0 (通常是 root) - GIDLIST=0 # 设置容器组 ID 列表为 0 - TZ=Asia/Shanghai # 设置容器的时区为亚洲/上海 devices: - /dev/dri:/dev/dri # 将主机的 /dev/dri 设备挂载到容器 开启硬解 ports: - 8096:8096 # 对外访问端口 restart: unless-stopped privileged: true volumes: - /volume1/docker_dir/emby_local/config:/config - /volume2/Media/cloud_media/clouddrive:/volume2/Media/cloud_media/clouddrive:rslave - /volume2/Media/local_media:/volume2/Media/local_media - /volume2/Media/webdav_media/clouddrive:/volume2/Media/webdav_media/clouddrive:rslave - /volume2/Media/webdav_strm:/webdav_strm # 其他网盘的 strm(夸克等) - /volume2/Media/strm:/strm # 支持 302 重定向的网盘 strm(115 ，天翼等) /volume2/Media/cloud_media/115 直接指向 alist 路径下的/115，从而实现 302 重定向网盘资源/volume2/Media/webdav_media路径进行访问wget https://github.com/bpking1/embyExternalUrl/archive/refs/tags/v0.4.5.tar.gz tar -zxvf v0.4.5.tar.gz cd embyExternalUrl-v0.4.5/ cd emby2Alist # modify nginx/conf.d/constant.js # 参考下图 1 配置 # embyHost 如果是本地 docker 部署的，就是图中的 http://172.17.0.1:8096(端口自行确认) # modify nginx/conf.d/config/constant-mount.js # 参考下图 2 配置 # alistAddr 如果是本地 docker 部署的，就是图中的 http://172.17.0.1:5244(端口自行确认) # modify nginx/conf.d/config/constant-pro.js # 参考下图 3 配置 # 待替换路径需确认 emby 媒体库内资源路径和 alist 内的路径，填写多出来的部分(仅限支持 302 重定向的网盘资源) nginx/conf.d/constant.js 
nginx/conf.d/config/constant-mount.js 
nginx/conf.d/config/constant-pro.js 
nginx-emby 容器内日志如下：
[warn] 21#21: *155 js: redirect to: /d/115/xxx 匹配到 emby2alist 里的 115 规则，并使用 alist 公网地址进行转发 
屏蔽位于constant-mount.js内clientSelfAlistRule中与 115 有关的规则 
问题描述：在上面的环境正常运转的情况下(emby 启动后)，新增了一个夸克盘通过alist -> cd2挂载到本地目录/volume2/Media/webdav_media，可以正常生成新的 strm 文件，emby 也可以正常入库，但是无法播放，并提示无兼容的流。此时在 emby 中查看挂载在 emby 容器上的/volume2/Media/webdav_media路径，里面的夸克盘路径下是没有东西的
复现方式：
/volume2/Media/webdav_media下是否已经没有文件夹/volume2/Media/webdav_media下是否虽然有夸克盘的目录，但里面没东西这是因为在之前的步骤中，emby 容器配置中与网盘相关的路径映射如cloud_media, webdav_media没有开启 rslave 模式，现已修正
emby 容器与网盘相关的路径挂载时开启 rslave 模式，详见 4.1
以下操作可保留原先所有配置和刮削记录
# add :rslave to docker-compose.yml 按照 4.1emby 部署的 compose 文件更改 docker stop emby_container # emby_container 替换成自己的容器名 docker rm emby_container # emby_container 替换成自己的容器名 docker-compose up -d # 重新部署 该问题一般由指定路径下的文件不存在引起，可以检查下网盘是否正确挂载
参考教程：
url: https://www.nerocats.com/archives/58/ title: "alist-clouddrive2-auto_symlink-emby-nginx 实现 emby 播放 115 直链 - 偏爱一丛花" description: "完成效果：1. moviepilot 下载目录(可以不用) 如：/media/docker/moviepilot/downloads2. moviepilot 整理后的媒体库目录，同时也是 cd2..." host: www.nerocats.com favicon: https://www.nerocats.com/usr/uploads/logo/favicon.ico 免责声明：仅为学术研究，请勿扩大化联想。
]]>有些人问为啥叫"garlic", 这个名字来自郭德纲的相声：喝咖啡高雅，吃大蒜低俗，java class 文件以 CAFEBABE 开始，所以起了一个恶搞的名字garlic， 咖啡就着大蒜，高雅又低俗。
经过一个月的开发，garlic反编译器支持了 apk 和 dex 。apk 的 Manifest 和资源文件没有解析，只反编译了里面的代码。
顺带写了些其它的东西：
我测试过的 apk （豌豆荚下载的最新版）：
速度方面，抖音的体量最大，差不多有 44w 个 class ，处理完需要 30 秒，我的机器是 macmini m4
~/workspace/clang/decompiler-garlic/build $ time -v ./garlic ~/workspace/java/bytecode/apks/douyin.apk [Garlic] APK file analysis File : /Users/xxx/workspace/java/bytecode/apks/douyin.apk Save to : /Users/xxx/workspace/java/bytecode/apks/douyin_apk Thread : 4 Progress : 446075 (446075) [Done] Command being timed: "./garlic /Users/xxx/workspace/java/bytecode/apks/douyin.apk" User time (seconds): 84.91 System time (seconds): 27.90 Percent of CPU this job got: 372% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:30.28 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 1725728 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 3 Minor (reclaiming a frame) page faults: 156943 Voluntary context switches: 25062 Involuntary context switches: 708980 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 16384 Exit status: 0 有朋友问我到底想搞一个什么样的东西出来，我总吹牛逼说我要搞一个 c 语言写的jeb出来。
后来看了好多 apk ，又想支持 lua ，又想支持 C#，我现在想吹牛逼我想搞个大而全的东西出来，能反编译所有 apk 。
回过头看写出来的东西，一堆一堆待解决的问题和完全未知的领域，真他娘的不知天高地厚了。
还是欢迎大家试用，欢迎大家提意见，欢迎 PR ，欢迎提 bug
]]>
将提供的 Android 录屏视频中出现的题目 选项 解析摘录, 一共 755 个题目输出到一个完整的 Docx 文档中. 如有公式, 则应当以公式格式呈现. 其他干扰信息, 如 DeepSeek 广告等不应出现在解析中. 示例界面: 
视频中存在部分干扰, 如通知消息和界面动画滑动: 
本质上是一个 OCR+结构化提取并输出的过程, 本质上并无太大难度. 难点在于如何提取视频题目帧和结构化的输出. 至于部分干扰(如遮挡等)则可不处理, 由后续对方人工按帧校对.
我的思路如下:
instruct的模型. 对不稳定的模型输出, 自己实现结构化提取是一件很恼火的事情...在下面给出的实现中, 为了保障观感去掉了一些错误处理和判断.
import cv2 import os from skimage.metrics import structural_similarity as ssim def extract_static_frames(video_path, output_dir, threshold=0.99): top_crop = 200 bottom_crop = 250 skip_frames = 6 # 每处理一次跳过的帧数 cap = cv2.VideoCapture(video_path) success, prev_frame = cap.read() prev_frame = prev_frame[top_crop:-bottom_crop, :] frame_id = 0 saved_count = 0 while True: success, frame = cap.read() frame = frame[top_crop:-bottom_crop, :] # 转为灰度图做 SSIM gray_prev = cv2.cvtColor(prev_frame, cv2.COLOR_BGR2GRAY) gray_curr = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) score, _ = ssim(gray_prev, gray_curr, full=True) if score > threshold: saved_path = os.path.join(output_dir, f"frame_{frame_id}.jpg") cv2.imwrite(saved_path, prev_frame) saved_count += 1 # 跳过接下来的几帧 for _ in range(skip_frames): cap.read() frame_id += 1 prev_frame = frame frame_id += 1 cap.release() print(f"Saved {saved_count} static frames to: {output_dir}") 对于输入格式为1080x2340@13.88fps 23min共 19154 帧的视频,使用 5800H 需要约 7 分钟处理完成, 最终共保存 855 帧, 基本可以做到一个题目一帧. 有精力的话可以人工从中去掉一些明显不正确的帧, 没有的话后续进行 OCR 时可进行判断.
这里我选用paddleocr来做文字识别, 不得不说即开源准确又高的东西还是非常有优势的. 它也能对中英文和公式有较好的识别率. 要识别的界面较为规整, 提取到的文字按行读取即可.
我们首先要采取一个样品, 交由大语言模型生成判断是否是题目的标志question_mark和无用的信息标志useless_mark. 之后就是简单的判断和保存了. 这一步同样不需要做的十分完美. 如下为 OCR 得到的文字样品:
< 0 答题 背题 语音 单选 6 、轻型无人机是指 质量大于 7 千克，但小于等于 116 千克 的无人机，且全马力平飞中，校正空 A 速大于 100 千米/小时(55 海里/小 时），升限大于 3000 米 质量大于等于 7 千克，但小于 116 千克 的无人机，且全马力平飞中，校正空 B 速小于 100 千米/小时（ 55 海里/小 时），升限小于 3000 米 空机质量大于 7 千克，但小于等于 116 千克的无人机，且全马力平飞中，校 正空速小于 100 千米/小时 (55 海里/ 小时），升限小于 3000 米 答案 c 试题详解 试题纠错 解析 该题关键点在于空机质量。参考 R1 的重量分 类，微型 0<m≤7kg ，轻型 7<m≤116kg ，小 型 116<m≤5700kg ，m>大型 5700kg 。 755 收藏 答题卡 实现:
def ocr_images_to_markdown(image_dir, output_dir): os.makedirs(output_dir, exist_ok=True) for fname in os.listdir(image_dir): isquestion = False question_mark = ["单选", "判断", "多选"] useless_mark = ["背题", "背题", "语音", "统计", "概述", "来", "难", "度", "使用 DeepSeek ，获取深度思考过程。", "试题详解", "试题纠错", "答题", "背题", "语音", "755"] image_path = os.path.join(image_dir, fname) md_path = os.path.join(output_dir, fname.replace(".jpg", ".md")) result_text = ocr.predict(image_path)[0]['rec_texts'] lines = [] for line in result_text: l = str(line).strip() if l in useless_mark: continue if l in question_mark: # 只有有该行的才视为一个正确的问题帧 isquestion = True lines.append(l) with open(md_path, "w", encoding="utf-8") as f: f.write("\n".join(lines)) print(f"已提取并保存到 {md_path}") 经过处理后, 总共剩余 780 个帧. 这个结果已经足够好了, 钱不够的情况下怎么可能再人工处理呢?
对于给钱不够的情况下是不可能使用参数量过大的模型的. 这里我们采用qwen2.5:7b, 由搭载ollama的笔记本就可以运行.
作为小模型的参数量摆在那, 并且计算性能有限, 因而我们输入给他的提示词和用户输入需要尽量精简, 这也是为什么前面要粗略过滤一遍.
为了保障结构化, 我们需要使用第三方库instructor, 使用上十分简单, 我们只需要使用pydantic定义一个回答类即可. instructor的使用能够保障模型的输出格式正确, 但是代价为一定的模型性能下降.
class Answer(BaseModel): options: dict = Field(..., description="题目选项") ## 顺序很重要!! question: str = Field(..., description="题目内容") explanation: str = Field(..., description="题目解析") @field_validator('options') def options_should_have_at_least_two_keys(cls, v): if not all(k in v for k in ["A", "B"]): raise ValueError("选项内容必须包含 A, B 两个选项") return v @field_validator('options') def options_should_not_be_empty(cls, v): if any(not v.get(k) for k in ["A", "B"]): raise ValueError("选项内容不能有空值") return v class Config: json_schema_extra = { "example": { "question": "微型无人机是指？", "options": { "A": "质量小于 7 千克的无人机。", "B": "质量小于等于 7 千克的无人机。", "C": "空机质量小于等于 7 千克的无人机。" }, "explanation": "该题关键点在于空机质量。参考 R1 的质量分类，微型 0<m≤7kg ，轻型 7<m≤116kg ，小型 116<m≤5700kg ，m>大型 5700kg 。。" } } 在使用instructor时, 有一点需要注意: 定义的 Class 类的顺序很重要, 以 3.2 的示例样本为例, 如果按 question -> options -> explanation 的顺序定义类, 模型的输出顺序自然也会按照其进行.
那么, 模型的输出大概率就会变为:
题目: 大型无人机是指空机质量大于 5700kg 的无人机. 选项: A: 空机质量大于 5700kg 的无人机 B: 质量大于 5700kg 的无人机 C: 空机质量大于等于 5700kg 的无人机 解析: 该题关键点在于空机质量。参考 R1 的重量分 类，微型 0<m≤7kg ，轻型 7<m≤116kg ，小 型 116<m≤5700kg ，m>大型 5700kg 。 即便调整提示词也没有作用(如下第一和第二点). 但是按照先 options 再 question 的顺序进行模型就几乎不会出现此问题.
提示词:
system_prompt = """你是一名熟悉考试题目的内容结构化助手。 你需要将用户提供的原始 OCR 文本内容，进行结构化提取，并输出为需要的结构： - 一共三个部分: 题目, 选项, 解析. 正确分辨题目, 选项, 解析内容. - 题目内容中不应包含选项, 题目应当是个问句或需要填空回答的陈述句。 - 两个或三个选项, 分别是 A, B, C. - 保留数学公式，尽量用 LaTeX 格式（如 $x^2 + y^2 = r^2$） - 解析中, 去除无用内容, 如 DeepSeek 成绩 作答等. """ 在使用大语言模型进行工程实践时, 顺序和提示词非常重要, 需要反复修改才可达到理想的效果. 在这个调试过程中建议使用如W&B等平台进行记录.
实现:
def process_all_ocr_markdown(input_dir, output_dir, model="qwen2.5:7b"): os.makedirs(output_dir, exist_ok=True) client = instructor.from_openai( OpenAI(base_url="http://localhost:11434/v1",api_key="ollama",),mode=instructor.Mode.JSON,) for fname in os.listdir(input_dir): parsed_text = parse_markdown_file(os.path.join(input_dir, fname)) refined = ollama_structured(client, parsed_text, model=model) question_str = f"题目: {refined.question}" options_str = "\n".join([f"{k}. {v}" for k, v in refined.options.items()]) explanation_str = f"解析: {refined.explanation}".replace("\n", "") refined_md = f"{question_str}\n 选项:\n{options_str}\n{explanation_str}" with open(os.path.join(output_dir, fname), "w", encoding="utf-8") as f: f.write(refined_md) print(f"Done: {fname}") 反复调整提示词后, 我们就可以得到较为完美的解析输出:
题目: 轻型无人机是指？ 选项: A. 质量大于 7 千克，但小于等于 116 千克的无人机，且全马力平飞中，校正空速大于 100 千米/小时(55 海里/小时)，升限大于 3000 米 B. 质量大于等于 7 千克，但小于 116 千克的无人机，且全马力平飞中，校正空速小于 100 千米/小时（ 55 海里/小时），升限小于 3000 米 C. 空机质量大于 7 千克，但小于等于 116 千克的无人机，且全马力平飞中，校正空速小于 100 千米/小时 (55 海里/ 小时），升限小于 3000 米 解析: 该题关键点在于空机质量。参考 R1 的质量分类，微型$0<m≤7$ ext{kg}$，轻型$7<m≤116 ext{kg}$，小型$116<m≤5700 ext{kg}$，$m>大型 5700 ext{kg}。 其实还可以提供一些样例, 供模型进行少样本学习(Few-Shot Learning), 效果会更好一些. 但是钱不够, 那这方面的测试可以等后面有兴趣了再进行.
至于公式和 Docx 输出, 使用pypandoc和python-docx就可以很简单地解决, 这里就不贴代码了.
大模型通常是解决问题时懒人的大杀器, 但是如何正确使用依然是费力且玄学的事情. 在某些情况下, 提供的样本越多模型的性能反而会下降, 至于其故事就等后续另开新篇章再讲.
如果各位有更好的解决方法也可以提出来相互交流.
]]>刚开始涉及到的模型是 java 的，计算时间也短，十来秒就结束了，我们采用的方案就是直接接口调用，等待响应就好了。
过了一段时间，涉及到的模型计算时间在半个小时晚上，就涉及到了数据的返回，已经这次计算的时候还要判断上次计算是否结束。（因为模型都是只能一次跑一个，没办法多线程运行。）计算时间长了过后，等待响应肯定是不行了，我们又采用了 grpc 的连接。又因为这个的参数组装加实际使用肯不方便，用着用着又搁置了。
现在我们采用的方案就是：设置全局变量，标志模型是否运行状态，还是调用 http 接口，本次计算后，不会等待响应，模型那边封装个通知接口，模型计算完成之后调用业务的通知接口返回参数或者文件，完成一次计算。
各位经验丰富的彦祖有什么更好，更合适一些的建议吗？感激不尽。
]]>但是手机目前还没找到一个好工具，如果 chatgpt 官方 app 的话每次都需要先开梯子。用 safari 开 lobechat 的话又感觉不太方便。
想问问大家有没有在用什么方便的 app 在 ios 端能实现类似 lobechat 的功能。
]]>脑机接口已经走入实际应用了吗？一直以为是未来世界的设想。。。
]]>本文首发于 [沉浸式趣谈] ，我的个人博客 https://yaolifeng.com 也同步更新。
转载请在文章开头注明出处和版权信息。
如果本文对您有所帮助，请 点赞、评论、转发，支持一下，谢谢！
AI — 它可能是个「语言魔术师」，但绝对不是「人类大脑」
你心血来潮问 AI：
你：「为什么古埃及人建造金字塔？」
AI （认真回答）：「古埃及人建造金字塔主要是作为法老的陵墓，同时也有宗教意义，代表通往来世的阶梯。金字塔的建造反映了古埃及人对死后生活的信仰和对法老神圣地位的崇敬。」
你：「他们用了什么技术能搬运那么重的石块？」
AI （开始推理）：「考古学家认为古埃及人可能使用了斜坡系统、滚木和杠杆原理来搬运巨石。一些理论提出他们使用了湿沙降低摩擦力，有效减轻搬运重量。工人们组成团队，通过绳索和集体力量协作完成。根据计算，大约需要 4,000 名工人协同工作才能移动最大的石块...」
你：原来如此...（ AI 将有限的历史证据、各种假说和未经证实的理论混合在一起，呈现为确定的知识）
为什么 AI 总在「靠谱」和「离谱」之间反复横跳？
答案很简单：它（ LLM：大语言模型）根本不知道什么是「合理」。
AI 聊天机器人（比如 ChatGPT ）就像一个「超级语言拼图大师」。
它的所有「知识」，只是从海量文字中统计出的「词语搭配套路」。
当你提问时，它就像在玩一场巨型文字接龙——永远在猜「下一句话怎样接最像人话」，而不是判断「这件事是否可能发生」。
举个栗子 🌰：
它不关心现实逻辑，只追求「语言流畅」的概率。
这种「无脑缝合」的特质，让它既能妙笔生花，也能胡编乱造。
接下来，我们就扒开 AI 的「语言魔术」，看看它到底是怎么「一本正经说胡话」的。
LLM （大语言模型）就是个「超级语言模仿怪」，它通过疯狂看人类的文字（书、网页、聊天记录），学会了「人类说话的概率」，然后就能跟你聊天、写文章、编故事，甚至装成莎士比亚。
角色 + 任务 + 格式 + 限制条件
例如： "你是一位经验丰富的数据科学家(角色)。请分析这组销售数据并提供三个关键洞察(任务)。以简洁的要点形式呈现(格式)，避免使用技术术语，因为这是给非技术团队的报告(限制条件)。"
AI 的"胡话"提醒我们：
下次有人问你 AI 是否真的懂问题，
你就说：「不，它只是个超级语言预测器，能猜出问题后面该接什么话，但根本不知道自己在谈论什么」
回到开头的问题：AI 真的懂你问的问题吗？
答案显而易见：不，它不懂。
它只是在玩一场极其精妙的语言游戏。
当 AI 回答你关于古埃及金字塔的问题时，它并不是真正理解了考古学和历史，而是巧妙地重组了互联网上关于这个话题的无数文字。
它给你的是语言的拼图，而非知识的本质。
这让我们想起文章开头的比喻：AI 是个「语言魔术师」，但绝对不是「人类大脑」。
它能让文字华丽地舞蹈，但不理解舞蹈的意义。
在 AI 时代，真正的智慧不在于拥有 AI 这个工具，而在于明智地使用它，同时保持批判性思考的能力。
]]>类似我这样用工具 https://github.com/zhangjunjie6b/shellok
我是这样做的，比如我想测试服务器上下载速度我就去写一个
然后服务器上
这样就拥有了一个自定义的融合怪
]]>AI 底层用的最多的应该是 容器化(K8s/..), 对象存储(Ceph/..), Python
佬们是如何看待这两者关系, 是否现有大数据技术可有可无, 从头新立即可.
]]>大家有在学习 DL 的么？
]]>我认为这次尝试效果不好的一个原因是底模不够强大，一个 4B 的模型本身说出有条理的话就已经很难，还要让其理解并学习用户说话的语气和方式，并拥有用户的记忆，本身就已经很难。
所以我在想，以当前大模型的能力，是否可以通过设计一套系统实现用户的赛博飞升？让 AI“成为”一个人具体需要调整和设计哪些方面？
早上看新闻的时候，看见有跑马灯，瞬间心动了，感觉很炫酷(老婆觉得很 low) ]]>倒闭的几家不算，比如 Sun ，还是让人敬仰。
]]>日志查询系统里的数据一般存放多久的日志？我们的日志有原始备份在 s3 上，查询系统上的数据是不是就可以定期删除掉了？
Loki 动态标签问题。Loki 不推荐动态标签，其理由是影响性能、增加索引体积。但是我怎么感觉少了动态标签，查询就很鸡肋。下面是我的想法，不知道符不符合实践经验，望指正！想法：
a. 分布式系统，少不了要用 reqeustId 去链接起一个请求经过不同服务产生的日志。
b. 不同的子业务，会有不同重要的数据 ID 。比如，一个订单系统的请求，打印出来的每一条日志，至少都要带上订单 ID 吧？这类数据 ID 也是动态标签。
c. 如果这些动态数据都不用 labels ，而是用正则匹配 log 内容查询。个人直觉告诉我，这个有点鸡肋。
如果用 Loki 索引动态标签。数据量大的时候，性能会不会比 ES 拉跨？
两个种服务都在本地实验性的搭建起来过。
Kibana 确实感觉有点吃性能，web 页面还偶尔会有点卡卡的，功能很多眼花缭乱（不过这个可以选择使用，逐步深入），但是查询的功能确实更强大。
Loki 真的很轻量就是不知道这动态标签用起来之后，会不会卡。不过查询真的差点意思。
相关文章：
V2: 最近我安装了 Loki + Promtail + Grafana ，感觉这一组合可以取代 Elasticsearch + Logstash
]]>如果每次创建新 skiplist 时，都使用完全相同的随机函数以及 seed ，从而每个 skiplist 被填满后，其层高的布局皆相同，这样相比于每次都完全随机层高的布局，会否降低查询效率？写入又会否有所改善，因为仅需查表而非摇色子。
想法是，写入数据的顺序本身就是随机的，被复用的层高布局本身也是随机的，只是从宏观看，所创建的所有 skiplist 实例的层高布局不够随机。
]]>