笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
自建向量库/知识库检索不准：先分清真 chunk 检索问题还是 embedding 模型选错
自建 RAG（知识库问答），文档切了、embedding 存了向量库、也能检索，但问答效果很差：答非所问、漏关键信息。排查 RAG 不准，先分清是检索层拿回来的东西不对，还是生成层（LLM）没用好——而检索层里最常见的是 chunk 切分和 embedding 模型的坑。
第一步：先测检索本身，别让 LLM 背锅。 把问题直接拿去向量检索，看召回的前几条是不是真的相关：
# 用你调的接口/脚本，打印命中 top-k 的原文片段和相似度
如果召回的东西和问题八竿子打不着 → 问题在检索层（chunk/embedding/相似度阈值）。如果召回的相关但答案还是错 → 问题在 prompt 或生成层（上下文塞太多太乱、模型没读懂）。RAG 调试第一原则：先把检索结果人肉看一遍，再谈生成。
检索不准常见原因：
- chunk 切太碎：一段话被切到两个 chunk，语义断掉，检索只命中一半。常见于按固定字符数硬切。对策：按语义边界切（标题/段落/句子），chunk 间保留重叠（overlap），比如 500 字切、重叠 100 字。
- chunk 切太大：一个 chunk 塞好几页，检索时向量是整个 chunk 的平均语义，问题只涉及其中一小段，相似度被稀释。chunk 大小要和"问题的粒度"匹配——FAQ 类小 chunk 好使，长文档要配合结构。
- embedding 模型和语言/领域不匹配：中文文档用英文优化的 embedding，效果差很多。中文优先用中文/中英双语 embedding 模型（如 bge-m3、bge-large-zh 等），别默认套英文模型。
- 没做混合检索：纯向量检索对"专有名词、精确数字、型号"这类 query 弱（语义相近但字面不同）。好用的 RAG 大多是向量 + 关键词（BM25）混合检索再融合，专有名词靠 BM25 捞，语义靠向量，别只上向量。
- 相似度阈值/返回条数不当：top-k 太少漏关键、太多把噪声塞进 prompt 稀释注意力。调 top-k 并设个相似度下限，过滤明显不相关的。
生成层常见坑（检索没问题时）：
- prompt 没让模型"只用检索内容回答，不知道就说不知道"，模型会自己脑补。
- 上下文太长，关键片段被埋没；做 rerank 或用小 chunk + 精排。
一个高效的调试手段：做个小的测试集，十几个真问题，每题记下"检索命中的原文对不对 + 最终答案对不对"，分别调 chunk 和模型，别凭感觉调。检索命中率低先改 chunk/换 embedding/加 BM25；命中率高答案还差再调 prompt。
总结：RAG 不准先人肉看检索结果分清是哪层。检索层：按语义边界切 chunk + 适当 overlap、用和语言匹配的 embedding、加 BM25 混合检索。生成层：prompt 约束 + 控制上下文。用测试集量化调，别瞎试参数。