RAG

到目前为止，个人感觉 90%以上的 AI 后端项目都是极其相似的一套：LangChain4j/Spring AI 搭个框架 + 调用大模型 API 做一下问答功能 + 搞点向量数据库做做 RAG 知识库 + 接点 MCP 调用一下外部系统的 API然后就没有然后了。最主要的问题是，这样的 AI 应用开发项目，基本不涉及什么高并发、高可用、分布式的场景，对于后端来说可以深挖的点很少，对于大模型来说又不涉及微调优化之类的。导致了一个很尴尬的局面：1.用这些“AI 后端项目”去面后端岗，候选人和面试官都不知道从哪挖项目的亮点。对于大部分中小厂来说，他们的业务都没有接入 AI 的必要，面试官一看你这什么，xxRAG知识库管理系统，不知道你这项目有什么价值，太简单了也没有什么场景题可挖。2.用这些“AI 后端项目”去面 agent 开发岗、大模型应用开发岗，后端出身的小伙伴不知道怎么扛住大模型相关问题拷打。这类岗位可能会拷打：怎么优化 RAG 召回、提示词工程怎么做的、向量检索原理……有些甚至问大模型微调怎么搞，大模型基础比如 Transformer 之类的。整体来说，这方面没有多少整理完善的八股，相关问题也偏实践，即场景题，但是此场景题与后端场景题既有共同的地方，也有不少出入，不是后端转过来做个玩具项目就能搞明白的。总结起来就是这些“AI 后端”的玩具项目难以包装，挖不深，拿来面两边都不讨好。可能最佳的解决办法（针对后端岗）是把它作为一个附加的服务模块加在已有的项目上，而不是独立拿出来。