河岳日星的博客

RAGFlow 实战（二）：文档解析实战——按文档类型选切块策略 系列导航：（一）部署、鉴权与排障；（二）本篇；（三）检索调参实录；（四）API 自动化。 一、一个反直觉的结论：解析质量的上限在「切块」，不在「识别」刚开始用 RAGFlow，我默认「扫描件才需要担心解析，文本文件还不是随便切」。直到拿一份 CSV 产品参数表做问答，检索结果一塌糊涂，才反应过来： CSV 是纯文本，根本不需要 OCR——OCR 是给像素的。CSV 的病在切块方式，不在识别。 同一份 CSV，两种切块方法的实测对比： 切块方法 结果 General（naive） 切出 ~2000 个「合并块」，一行数据被切得七零八落 Table 切出 ~10000 个「行级块」，每行一个块，字段齐全 行级块长这样，检索和阅读都友好： 1234- Product ID: M20978- Torque: 45 N·m- Voltage: 24V- 负责人: 唐博涛 RAGFlow 的 Table 切块会按列类型生成可过滤字段，等于给每行数据建了结构化索引。表格类文档（CSV/Excel/数据库导出）无 ...

把工作流沉淀成技能：我的 Skill 设计方法论一、为什么需要「技能」同一个任务第三次做的时候，就该停下来想一件事：前两次的经验去哪了？ 如果答案是「在聊天记录里」，那这些经验约等于不存在——下次还要重新踩一遍坑。 技能就是把「工作流 + 坑位 + 路由」打包成可复用的资产。我现在有二十多个技能：短剧创作体系、ComfyUI 流水线、RAGFlow API、长视频笔记、录屏拆解、模型部署……这篇讲设计它们时沉淀下来的方法论。 二、SKILL.md 的结构：每一行都有职责一个技能就是一个带 front matter 的 Markdown，结构高度模板化： 123456789101112---name: skill-namedescription: 什么时候用我——包含触发语，写用户的原话---# 标题## 0. 铁律（开工前必读，放最前）## 一、主流程（SOP）## 二、参数正解表 / 决策表## 三、脚本速查## 四、本机硬事实（照抄，别重新踩）## 五、参考资料（按需读，SKILL.md 保持瘦身） 几个字段的真实职责： description 是路由的唯一入口。用户说一句话， ...

RAGFlow 实战（一）：部署、鉴权与那些「不报错但不对」的问题 系列导航（全部为实战排障向，不讲源码 anatomy）：（一）本篇：部署、鉴权、API 调通的排障实录；（二）文档解析实战：按文档类型选切块策略；（三）检索调参实录：从「检索不到」到「检索得准」；（四）API 自动化：CLI 工具与批量流水线。 一、先说结论：RAGFlow 的坑分两种用 RAGFlow 小半年，踩的坑归两类： 会报错的坑——好办，看日志就行； 不报错但不对的坑——上传成功但解析没动静、HTTP 200 但「知识库中未找到」、日志一片绿但检索质量差。这类才是真正吃时间的。 这篇先把「调通」阶段的问题一次扫清：部署、鉴权、API 权限、建库传文档。解析和检索的深水区留给后面三篇。 二、部署：一把梭之后先改三样12cd dockerdocker compose up -d 默认 CPU profile，ES、MinIO、MySQL、Redis 全容器化，开发机够用。拉起后先改三样： 端口：80 是必争之地，宿主机有 Nginx 就改映射；API 示例里我用 http://localhost:938 ...

经验驱动。自动字幕工作流 = whisper 做语音识别出字幕文件 + 剪映做对齐/排版/校错。为什么选 whisper.cpp 而不是 openai-whisper、每一步怎么跑、哪些坑必须躲，全在这里。诚实声明：本机用 whisper.cpp 跑过中文转写；完整流水线（含剪映部分）是分步验证的，剪映本身是 GUI，无法脚本化。 为什么要做自动字幕手动打字幕又慢又累，尤其口播长视频。whisper 是 OpenAI 的开源语音识别，中文效果已经能用了。整套思路：机器出初稿 → 人工校一遍 → 排版，把最累的”听写”交给模型。 为什么用 whisper.cpp 而不是 openai-whisper whisper.cpp：C++ 实现，量化 GGUF 模型，CPU/GPU 都能跑，显存占用极低，本机 12G 显存跑大模型也不抢资源。 openai-whisper：Python + PyTorch，方便但要装 torch，显存和依赖都重。 我选 whisper.cpp 纯粹是为了不和本地 27B 推理抢显存。 工作流步骤1234567# 1) 用 ffmpeg 从视频抽音频（16k ...

做大模型应用最怕一句话：「效果好像变好了？」——「好像」不是证据。这篇讲我怎么把 LLM 应用的评测做成可复现、可对比的方法论，而不是靠感觉。 一、先拆层：别混着测LLM 应用通常分两层，必须分开测，否则你永远不知道问题在哪： 检索层（RAG 类）：检索准不准？召回全不全？切块对不对？ 生成层：答案对不对？有没有幻觉？有没有引用？ 我曾修过 RAGFlow 的检索调参（见 检索调参实录），核心动作就是先把检索层单独测准（召回@k、空结果率），再动生成。 二、检索层指标 召回率 @k：正确答案是否在前 k 条里——衡量「漏没漏」； 空结果率 / 软失败率：返回 200 但啥都没有，这是头号人为坑，必须单独埋点； 切块正确率：答案是否被切坏、是否跨段。 经验：检索层的指标大多能自动化批量跑，用黄金问答集（问题→应有段落）一键出分。 三、生成层指标 忠实度（Faithfulness）：答案是否都来自检索内容，有没有编； 答案相关性：是否真的回答了问题； 无害性 / 合规：要不要看业务而定。 这些主观指标，用 LLM-as-judge 做初筛：让一个强模型按 rubric 打分。但必须 ...