前端兔233
前端全栈工程系
前端全栈，TDD思想布道者，公众号：前端兔
获得徽章 3
- 马上过年了，刚刚给老婆下单了17 PRO MAX，没有过多犹豫，这是她今年应得的(目前只有这么大的能力买这个了😮💨)。现在的手机还是2年前生孩子时买的15 PRO，性能稳定够用，但我觉得她值得用更好的。今年算是事情多发的一年吧，4月份我经历了裁员，5月份又做了一场小手术，恢复了2个月，八月才开始了新的工作。从裁员开始，她就一直在鼓励支持我，让我好好休息，难得放松的机会，让我出去旅游散散心。手术期间无微不至的照顾，白天上班，晚上陪护，连轴转了半个月。孩子这半年也发烧住院了3次，不管是在医院还是在家里，在孩子的照顾上她付出的更多，却休息的最少。孩子不舒服闹腾，每晚抱着入睡，两个胳膊酸胀的筷子都拿不稳，腰也疼的厉害。她很累，我都看在眼里，尽可能的帮她分担，但我知道，她依然很累。生活中她总是乐呵呵的照顾每个人的心情，默默承受着一切不好的情绪，说实话我挺依赖她。我们高中相识，一路走到现在，已经13年有余，我很庆幸，我能遇到她。我性格内向，她乐观开朗，我们形成完美的互补，就算过了这么久，第一次见到她时那种心动的感觉依然那么强烈。当你真正爱一个人时，你会怕她累着，怕她工作中受委屈，怕她在一些事上吃亏，会觉得为她买东西内心愉悦，我想我是真的很爱她。 年底了她还在忙，忙着过年回家时七大姑八大姨每家的节礼，到处凑单搞满减，买到便宜的礼品会开心的向我炫耀。给父母准备衣服，给孩子准备礼物。我们两个早就约好，今年两个人不添置新衣服了，今年发生了很多事确实花了挺多钱，这是她主动提的。但是我知道，她肯定会偷偷给我准备新年礼物，她就是这样。我不想让她忙了一年连一件像样的礼物都没有，她今年真的好累。手机到了后，准备半夜偷偷帮她转移数据，早上醒来时给她一点惊喜，写到这里我已经迫不及待想看她开心笑的样子了，快递情再快一点。 我深知这点礼物很轻，轻到跟她的付出比起来，微不足道，但这已是我目前能做到的全部了，其他的只能靠实际行动来弥补了。期待除夕夜，绚烂烟花下她开心的笑～展开322405
- 星期一的伤心事
背景：我每天早上是九点上班，由于住的离公司挺近，所以日常都是电动车上班，上个礼拜每天早上都是在8.50的样子从一个交叉路口出来碰见一个女生。起初一两天我并没有在意，直到第四天我发现好巧又遇上了，但我们没有打照面。于是周末的时候想到了这件事，想着周一要是再遇到了这个女生就去要个微信。
今天早上和往常一样收拾一下出门，同一个时间达到同一个路口，但今天我没有凑巧在她后面（或许这是伏笔1）。我心里还是不想放弃，也许我今天快了十几秒，因此我稍微放慢了车速，慢慢地到了红绿灯，我停下注视着后视镜里她的身影会不会出现，幸运的是她真的出现了！
绿灯亮了，由于我前面的电动车车挺多，没第一时间启动，但也因此我刚好在她的电动车后面。于是我就正常骑跟着，这个红绿灯离公司不到50米，不一会的时间就到了楼下停放的地方。我想着不问或许就从此错过，我也停在了离她两个车位的旁边。
我：“你好，你也是在××（园区名）上班吗”
她：“……”
或许是离上班时间近了，她还没反应过来我跟她说话
我接着说道：“好巧，我也是在这上班，可以加个微信吗”
她尴尬的笑了下说:“要到上班时间了…”
我心里确实想确实是哦
于是连忙说：“对了，你先打个卡”
我还没说完他已经点开app打起卡了，打完卡后她点开微信不知所措的在消息列表页滑动了几下，或许是在犹豫要不要给，大慨三四秒后她找到了添加好友的码（伏笔2），我当时还是有点喜悦的，赶紧点开扫一扫并点击添加，随后我说：“谢谢，实在抱歉打扰了”。
我们各自往上班的楼号走去
大概过了十分钟，微信界面依旧没有弹出通过好友申请的消息，我想或许人家刚上班正忙着呢，不着急。
又过了半小时，一小时，两小时……马上中午吃饭了，依旧没有通过，我心里已经有答案了，人家给你扫只是不想两个人站那里太尴尬，实际上是不想加的。
伏笔1，今天不同上礼拜都是凑巧在她后面，今天在她前面，或许本就代表没有缘分了，是我强行续上了一点
伏笔二，她打卡的期间我怎么就不知道把自己的码点开让她扫呢，这样主动权就在我自己手里了，还不用她找自己的码找几秒
总结：虽然最终结果还是失败了，但或许是我没有考虑到上班高峰很赶，以及周一上班本就烦，不恰当的时机去问让人很冒昧。对了这是我第二次问女生微信，没关系，心情也就一点点失落吧![[得意]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_52.cc6d6bc.png)
。
虽然有点美颜和磨皮，但也不丑吧，呜呜呜 展开1486 - 为什么知识库配置明明一样，但不同平台的效果却完全不同？
昨晚给一家企业做咨询，讨论到他们内部流程的知识库目前检索效果不佳。我看他们在用的是一个私有部署的工作流平台，顺口问了一句：“这块有没有试过专门的 FastGPT 或 RAGFlow？”
对方很疑惑：“没有。我们这个平台现在的知识库功能挺全的，切片、向量化、混合检索都有。底层的原理不都是 RAG 吗？换个平台效果能有多大差别？”
这其实是很多B端落地的误区：以为 RAG（检索增强生成）是一个标准化的功能模块，只要有了“上传 + 切片 + 搜索”这三板斧，效果就应该是一样的。
其实不然。这里的核心差异在于「知识库工程化」的深度。即使你上传同样的文件、配置同样的切片大小（Chunk Size）、使用同样的 Embedding 模型，不同平台跑出来的检索命中率可能天差地别。
1、很多人被平台配置的UI 骗了。
通用的 RAG 流程确实大同小异：文档解析、切片、向量化、存储、检索、生成。在 UI 界面上，你看到的配置项也无非是“切片长度 512，TopK 5”。
但这两个看似相同的数字背后，执行的代码逻辑可能完全不同。决定检索质量的，往往是那些配置界面上看不到的隐形工程。
2、差异的第一步发生在「文档解析」（Parsing）阶段：是读文字，还是理解排版？
很多通用平台使用开源的基础库（如 LangChain 的默认 Loader）来读取 PDF。如果你的文档是双栏排版，普通解析器只会傻傻地按行读取，结果就是把左栏的半句话和右栏的半句话拼在一起，造成语义错乱。这种数据一旦进入数据库，检索效果必然崩塌。
而在RAGFlow 这类平台中，它引入了 DeepDoc 视觉模型。它像人眼一样先看文档的布局，识别出哪里是标题、哪里是表格、哪里是跨页段落。比如处理一张复杂的财务报表，普通平台提取出来的是一堆乱码字符，而 RAGFlow 能保留表格结构。解析精度的差异，避免了Garbage in， Garbage out的问题。展开17
![[流泪]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_6.dde0d83.png)
![[得意]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_52.cc6d6bc.png)
。