Prompt engineering 入门:少即是多
看过太多新手写 prompt 像写论文,恨不得把所有约束堆进去,结果模型反而犯晕。我的经验是:少即是多。 核心三件套就够:角色(你是谁)、任务(做什么)、约束(怎么做)。其余的能省则省,模型比你想象的聪明。约束堆太多反而互相打架,模型不知道听哪条。 调不通的时候,先试着删几条 p
Posts
像论坛一样发起讨论,适合问题、观点、工具推荐和经验交流。
看过太多新手写 prompt 像写论文,恨不得把所有约束堆进去,结果模型反而犯晕。我的经验是:少即是多。 核心三件套就够:角色(你是谁)、任务(做什么)、约束(怎么做)。其余的能省则省,模型比你想象的聪明。约束堆太多反而互相打架,模型不知道听哪条。 调不通的时候,先试着删几条 p
给公司内部搭了个问答机器人,把规章制度、技术文档、历史工单全喂进去,本以为效果会很一般,结果同事反馈意外地好。 复盘下来几个关键:文档预处理做得细(去噪、分章节、加标题);chunk 切得合理(按语义而非固定长度);加了个"重排"步骤把最相关的顶上去;最后用强模型做答案生成。 没
应用流量涨上来之后,API 费用成了大头,老板让我压一压。目前已经做了:缓存高频查询、短任务切小模型、prompt 精简。 还想再降,但找不到方向了。听说有人用蒸馏、有人自部署开源模型、有人做多供应商竞价路由。 想问问大家都用啥招压成本,哪个效果最明显?有没有什么坑要注意的?谢了
每次以为开源快追上了,闭源一个新版本又把差距拉开。推理能力、长任务稳定性、agent 能力,开源暂时还是跟不上头部闭源。 不是说开源没用,自部署、隐私、成本这些场景开源还是香。但在"最强能力"这条线上,闭源目前确实领先。 希望开源继续发力追上。大家日常用开源多还是闭源多?觉得差距
RAG 里 chunking 看着不起眼,实际决定召回质量。分享我用得最顺的策略。 核心思路是"按结构切,不按字数切"。对 Markdown 按标题层级切,每块带上父标题作为上下文;对代码按函数/类切;对长文按段落+滑动窗口。 加父标题前缀之后,召回时模型能知道这块在讲啥。细节决
现在多模态模型能看图了,有人试过给它截图让它写代码。我体验下来,简单 UI 还原确实能写个七八分,复杂布局就各种走样。 最实用的是"看设计稿写前端",能把大致结构搭出来,省不少起步时间。但精细的交互、响应式还得人来。 不过这方向想象空间大,截图→代码、Figma→代码以后可能真成
我的 RAG 召回率一直上不去,调了几招之后有所改善,分享下。 一是 query 改写:用户原话往往召回不准,先用模型把问题改写成更"检索友好"的表述;二是混合检索:向量 + 关键词(BM25)一起上,取长补短;三是重排:召回 top 50 后用专门的 reranker 模型重排
给站内搜索加了语义检索,记录下流程备忘,也给大家参考。 老搜索是纯关键词,搜"怎么部署"匹配不到标题写"上线流程"的文章。加 embedding 之后,把每篇文章向量化存进 pgvector,搜索时把 query 也向量化,按余弦相似度排序。 pgvector + 一行 SQL
做应用最纠结的就是选型,我把三种路线的取舍理一下。 闭源 API:能力最强、上手最快、最贵、数据要出域。开源 API(第三方托管):能力次之、便宜、灵活。完全自部署:最便宜(量大时)、数据完全自控、运维和硬件成本高、能力打折。 我的经验是:早期用闭源快速验证,规模上来后核心链路切
想让一个小模型在特定任务上胜任,准备微调,但数据量心里没底。查了一圈说法不一,从几百条到几万条的都有。 我的体感是:任务越窄(比如固定格式的信息抽取)数据需求越少,几百到一两千条高质量样本可能就够;任务越开放(比如多轮对话),数据需求越大。 质量比数量重要,一千条干净数据胜过一万
RAG 加重排(rerank)效果立竿见影,但用专门的重排模型成本不低。分享个轻量做法。 先用向量检索粗召回 top 50,再用一个便宜的小模型(或者直接用交叉编码器)对这 50 条和原 query 打分,按分数重排取 top 5。重排只算 50 次,成本可控。 大家 RAG 都
推理模型流行起来后,输出前面经常跟一大段"思考过程",啰啰嗦嗦列一堆中间步骤,正经答案就那么几句。简单问题也这么搞,看着累还费 token。 理解思考过程对复杂推理有用,但能不能让模型自己判断该不该思考?简单问题直接答不香吗。 现在我的做法是简单任务用非推理模型,复杂任务才上推理