👋 Welcome to LouFY’Log

首先，mapMulti或许用的不是特别多——和flatmap相比就只是多了一个优点：不会产生对于每个元素的中间stream对象，减少了开销。但是因为对它写法的一系列疑惑，结果促使探究到了stream的链路逻辑。 场景与mapMulti&faltMap //场景：将一个数字字符串列表转为Integer类型的列表，同时去除不合法字符 //实现：使用更省开销的mapMulti方法 List<String> strings = List.of("1", " ", "2", "3 ", "", "3"); List<Integer> ints = strings.stream() .<Integer>mapMulti( (string, consumer) -> { try { consumer.accept(Integer.parseInt(string)); } catch (NumberFormatException ignored) { } }) .toList(); IO.println("ints = " + ints); 一些基础 java16后引入 该方法传入一个BiConsumer 需要被映射的元素 调用一个Consumer，用来存放最终结果流，达到不产生中间过程流的目的（相比于flatMap） 因为这里逻辑稍复杂，防止编译器混乱，泛型参数类型推断出错，手动进行了参数类型指定。 对于方法：泛型写在方法名前「更准确是写在返回类型前」 对于类：泛型写在类名后 代码块逻辑： 若元素能被Integer.parseint准确转化，就将此结果传入一个结果流中，而不是形成一个个小的stream对象再进行展平（flatMap） 若失败，报出受检异常，并被catch捕获处理 传的consumer是什么东西？ 怎么会蹦一个consumer出来？内部定义的？定义这个干嘛？ 要弄明白这个问题就需要深入stream的底层了 直觉式解释： stream以“pipeline”式处理流式数据闻名。源数据经过一系列中间操作累积处理逻辑，最后在最终操作那一口气处理。那么是怎么将这些操作逻辑累积下去的呢？ 答：consumer。每次中间操作都会进行这样的逻辑：承载接收上流操作、将本次操作加入——“consumer.accept()”，传递到终端操作处，统一处理 mapMulti这里是显式地将内部进行的consumer操作作为参数传递，一旦有合法字符转化了，就将它传递。从而达成不产生中间流的作用 实际：AbstractPipeline + Sink。不过还是拿consumer来搭建心智模型： [源数据] → [map1] → [filter] → [map2] → [终止操作 toList] headSink → map1Sink → filterSink → map2Sink → terminalSink Stream 是惰性的：只有调用终止操作（如 toList()）时，才真正开始把元素从源头流过整个管道。 终止操作首先创建了最底层的“真实 consumer”：比如 x -> result.add(x)。 然后，从最后一个中间操作开始，每一层都拿到“下游 consumer”并返回一个“包了一层逻辑的上游 consumer”。 这一层层 wrap 下来，最外层的那个 consumer，就对应管道最前面的操作（第一个 map/filter）。 当源数据被遍历时，只调用这个最外层的 head.accept(x)，它内部会按顺序调用各个中间操作逻辑，最后传到终止操作的 consumer 上。 //伪实现 //终端操作： List<T> toList() { List<T> result = new ArrayList<>(); // 1. 在终止操作里，先创建最底层的 consumer Consumer<T> terminal = x -> result.add(x); // 2. 从“最后一个中间操作”开始，往前一层层 wrap Consumer<?> head = terminal; Stage<?> s = this; // this = 最后一个 stage（最近的 map/filter） while (s != null) { head = s.wrap(head); // 每一层都“包住”下游 consumer s = s.upstream; // 然后跳到上游那层 } // 3. 最终得到 head，是最前面的那个 map/filter 封装出来的“总入口” for (Object element : getSource()) { ((Consumer<Object>) head).accept(element); // 启动整条链 } return result; } //中间操作： class FilterStage<T> extends Stage<T> { private final Predicate<T> pred; FilterStage(Stage<T> upstream, Predicate<T> pred) { super(upstream); this.pred = pred; } @Override <X> MyConsumer<T> wrap(MyConsumer<X> downstream) { return (T value) -> { if (pred.test(value)) { ((MyConsumer<T>) downstream).accept(value); } // 否则就“拦截”掉，不往下传 }; } } 传的consumer就是该步操作产生的新consumer（将来会作为upStream向上传递，等待被包装）。 ...

有好多版本，好有意思 git 你怎么能直接 commit 到我的 main 分支啊？！GitHub 上不是这样！你应该先 fork 我的仓库，然后从 develop 分支 checkout 一个新的 feature 分支，比如叫 feature/confession。然后你把你的心意写成代码，并为它写好单元测试和集成测试，确保代码覆盖率达到95%以上。接着你要跑一下 Linter，通过所有的代码风格检查。然后你再 commit，commit message 要遵循 Conventional Commits 规范。之后你把这个分支 push 到你自己的远程仓库，然后给我提一个 Pull Request。在 PR 描述里，你要详细说明你的功能改动和实现思路，并且 @ 我和至少两个其他的评审。我们会 review 你的代码，可能会留下一些评论，你需要解决所有的 thread。等 CI/CD 流水线全部通过，并且拿到至少两个 LGTM 之后，我才会考虑把你的分支 squash and merge 到 develop 里，等待下一个版本发布。你怎么直接上来就想 force push 到 main？！GitHub 上根本不是这样！我拒绝合并！ RAG系统 你怎么能直接 client.chat.completions.create 去调大模型啊？！企业级 RAG 系统里不是这样！你应该先通过 ETL 流水线把 PDF 和 PPT 清洗一遍，跑一遍 OCR 和 Layout Analysis 提取图片里的图表信息。接着你要用 Recursive Character Text Splitter 按照语义完整性做 Chunking，并调用 CLIP 或者 BGE-M3 模型生成多模态 Embeddings。然后你要把这些高维向量存进 Milvus 或者 Weaviate，构建好 HNSW 索引。接着用户提问的时候，你要先做 Query Rewriting，生成多路查询，去走一遍 Hybrid Search，同时结合 BM25 关键词和 Dense Vector 召回 Top-K 文档。然后你要过一遍 Cross-Encoder 的 Reranker 模型，把 Relevancy Score 低的脏数据过滤掉。之后你把这些图文切片按照 Token Limit 精心塞进 Prompt Template 的 Context Window 里，并严格要求模型基于引用回答。在生成 Response 之前，你要跑一遍 Guardrails 甚至用 RAGAS 框架做一轮评估，检查有没有幻觉，确保 Faithfulness 和 Answer Relevance 分数达标。等 Grounding Check 全部通过，并且没有触发 Sensitive Word Filter 之后，我才会考虑把 token 一个个 stream 推回给前端，等待用户反馈。你怎么直接上来就想裸调 API 靠模型瞎编？！知识库增强根本不是这样！我拒绝生成！ ...

#最佳实践 一般来说不会有这个问题，老老实实进行“定义接口->写实现类/匿名类->new对象->调用方法”自然会进行变量层面的抽象。 但lambda这种语法糖太简洁了，导致写的时候会忍不住追求更方便写法，导致jvm运行时的不方便 List<String> strings = List.of("one", "two", "three", "four", "five", "six", "seven"); Map<Integer, String> map = new HashMap<>(); for (String word: strings) { int length = word.length(); map.merge(length, word, (existingValue, newWord) -> existingValue + ", " + newWord);//如果length不在map中，会绑定到word；如果存在，会用现有值和word调用双函数，双函数的结果替换当前值 } map.forEach((key, value) -> IO.println(key + " :: " + value)); 为什么这些lambda明明可以直接用外面的变量，如上面的newword，但还要把它作为一个参数传进来？ 可以让lambda变成“non-capturing”（不捕获外部变量），性能更好 对于non-capturing，JVM 可以把它当成纯函数对象、无状态对象来优化 可以实现成一个没有字段的单例对象，甚至整个程序里就用这一份；一次创建，到处复用。 不需要每次创建新对象； 更容易被 JIT 内联、优化。 如果进行捕获了，lambda 用到了外部的变量，编译器必须生成一个带字段的对象，里面存着 bonus 的值。在某些场景下，甚至每次使用都要 new 一份（或者至少要为每个不同捕获环境生成不同实例），分配成本更高，优化空间更小。

大伙自然地将entry和键值对联系在一起**“一个键值对就是一个 entry”**，于是java官方就把其作为造键值对的静态方法名 为什么会“自然地将entry和键值对联系在一起”？ entry 有“目录/词典里的一个条目”语义 map也很像词典/目录：词头、释义

“长尾”指的是：主流需求之外，那条又长又细、数量巨大的“小需求带” 除开很多人需求外，还有一部分“细长”区域，特点是 每个需求对应的人数不是那么多 需求种类很多 以前没人管这条尾巴，原因：软件开发成本高：人工成本、维护成本、需要“比较规范”才上线 现在：LLM、app生成工具、低成本部署使得面向特定小群体的app也值得一做。应用=内容，如15年前YouTube兴起一样

注：观点来自锦恢 注：内容来自该帖子评论区的回答 Q：训练岗应该能无缝转agent算法开发吧 A：只是把大模型接入应用，很简单，但是如果需要在特定任务上不微调模型的情况下把准确率提升到95%以上，就很难了。目前agent开发难点不在接入一个agent框架上，这件事没有任何技术难度，难在不断调整策略，在业务数据的迭代中设计出可以满足客户要求的准确率和可靠性的系统。后训练模型只是一种解决思路，但是考虑到成本和实际的性能，频繁使用这个方法和只使用这个方法都是不可靠的。事实上，大模型到最终落地之间有一道很大的鸿沟，这道鸿沟就是agent开发的发力空间。很多纯算法出身的人都认为只要大模型一训好，就能自动落地让客户满意，事实上，并非如此。

背景 看dev.java，学集合框架时，原文写了iteration，翻译总翻成遍历，觉得奇怪 结论 都可以。“iterate” 既可以表示 “迭代”，也可以表示 “遍历” iterate演化出两层含义 机械地重复执行（即迭代算法中“反复求近似解”那种含义）； 依次访问集合中的每个元素（即遍历集合）。 编程中 “迭代器（iterator）” 是一种机制 “遍历（iteration）” 是这种机制实现的动作 参考 https://www.zhihu.com/question/39854900

很棒的资料 https://jamesakl.com/posts/cuda-ontology/ 详细系统讲解了CUDA整体 从顶往下：GPU 软件栈的层次结构 可以把 CUDA 系统理解成从硬件到应用的四层结构： ┌──────────────────────────┐ │ 你的深度学习程序 (PyTorch / TensorFlow) │ ← 应用层 ├──────────────────────────┤ │ CUDA Toolkit / cuDNN / cuBLAS / 驱动API │ ← 开发与加速库层 ├──────────────────────────┤ │ NVIDIA 驱动 (Driver) │ ← 驱动层 ├──────────────────────────┤ │ GPU 硬件 (2080 Ti 等) │ ← 硬件层 └──────────────────────────┘ “我的 Python 程序通过 PyTorch 调用 CUDA Runtime API， CUDA Runtime 依赖 NVIDIA 驱动与硬件通信， 驱动再控制显卡完成底层计算。” “CUDA 生态是一整套 GPU 加速栈： 从最底层的硬件到驱动，再到 Toolkit 和加速库，最后被深度学习框架调用。 驱动连接硬件，Toolkit 提供编译和库接口， 框架调用这些接口完成并行计算。” ...

泪水之城描述 如 一座由繁华转为死寂的城市，总是下着雨 阴暗的小巷，总是潮湿多雨，高耸入云/不切实际的尖塔，幽深的地下城 风格? 搜索失败了，并没有准确的答案。 reddit上确实有相关讨论，但是都是模糊模棱两可的 感觉最像的是哥特式 城市：Prague 如果天气是雨天就更好了。这种感觉绝了 一位似乎是艺术领域或者爱好者？的回答 《空洞骑士》中的几种设计可能受到了历史悠久的维多利亚式建筑（更多例子）和第二帝国风格的启发，带有巴洛克和哥特式的影响和风格，并带有一丝新艺术风格。 是的，维多利亚式，高耸的尖塔，笔直的墙壁

mac里的一款软件、包管理工具，提供快捷的依赖关系整理 安装命令「使用官网脚本安装」：/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 检查：brew --version 使用：brew install mysql 首次配置参考教程：https://mirrors.tuna.tsinghua.edu.cn/help/homebrew/ 注意 配置brew本身的镜像源「否则其自身的update将会很慢」 配置仓库的镜像源「否则其下载会很慢」