項目深挖AI知識庫引擎的存儲與記憶架構面試官上來先讓他自我介紹然后直接切項目。他簡歷上的項目是一個AI知識庫引擎包含文檔上傳、解析、向量化、對話檢索等完整鏈路。面試官對這個項目挖得很細。Q1. 短期記憶怎么做的長期記憶怎么做的這道題考察的是對AI對話系統(tǒng)中記憶管理機制的理解面試官想確認你不是只會調API。短期記憶本質是當前會話的上下文窗口。他把最近N輪對話消息user assistant按時間順序拼接塞進LLM的messages數組里。這里有兩個關鍵設計滑動窗口截斷不是無腦堆所有歷史消息而是按token數截斷。比如模型上下文窗口128K他預留32K給system prompt和檢索到的知識庫內容剩下的96K按消息倒序填充最新的消息優(yōu)先保留。摘要壓縮當對話超過一定輪次比如20輪把前10輪的對話內容用一次輕量LLM調用生成摘要壓縮成一段200字內的文本替換掉原始消息釋放token空間。長期記憶本質是跨會話持久化的用戶畫像和關鍵信息。他的做法是結構化存儲MySQL存用戶偏好標簽偏好的編程語言、常用框架、項目背景等每次對話結束后異步提取關鍵信息寫入。向量化記憶將用戶歷史對話中的重要片段做embedding存入向量數據庫。新會話開始時用當前問題做語義檢索把相關的歷史對話片段注入上下文。觸發(fā)時機不是每次對話都寫而是識別出用戶說了新信息比如換了項目、換了技術棧才觸發(fā)記憶更新避免無效寫入。記住這一句短期記憶上下文窗口管理滑動窗口摘要壓縮長期記憶跨會話持久化結構化存儲向量檢索。Q2. 知識庫上傳怎么做的整個上傳鏈路分四步文件接收前端上傳到OSS后端拿到文件URL和元信息文件名、大小、類型寫入MySQL的文檔表狀態(tài)設為待解析。異步解析通過消息隊列觸發(fā)解析任務。解析器根據文件類型PDF/Word/Markdown/TXT選擇合適的解析引擎提取純文本內容。這里用了Apache Tika做通用解析PDF用PDFBox做深度提取。文本分片解析后的文本按語義邊界切分——不是粗暴的固定長度而是優(yōu)先在段落、句號、換行符處切分保證每個chunk語義完整。chunk大小控制在512 tokens左右重疊128 tokens。向量化入庫每個chunk調用embedding模型生成向量存入向量數據庫Milvus同時原始文本存入MySQL備查。文檔狀態(tài)更新為已完成。面試官追問了失敗重試和冪等性他答了解析失敗自動重試3次每次間隔遞增文檔級別的冪等靠唯一hash值去重chunk級別的冪等靠先刪后插的覆蓋策略。Redis連環(huán)追問從作用到消息隊列再到大KeyQ3. Redis在你的項目里做了什么他的項目里Redis承擔了三個角色緩存層熱點對話session、用戶信息、知識庫元數據避免頻繁查MySQL。分布式鎖文檔解析任務用SETNX防重復消費保證同一文檔只會被一個worker處理。消息隊列用Redis List實現文檔解析的異步任務隊列生產者push任務消費者BRPOP阻塞拉取。Q4. 選型時為什么用Redis穩(wěn)定性如何任務有持久化嗎選型原因項目本身已經用了Redis做緩存復用同一套基礎設施不需要額外引入RabbitMQ/Kafka運維成本最低。文檔解析任務是輕量級的QPS不高Redis List的性能完全夠用。小團隊不想為消息隊列單獨維護一套集群。穩(wěn)定性Redis本身是單線程處理命令執(zhí)行層面不存在并發(fā)問題。主從哨兵模式下主節(jié)點掛了10秒內自動切換對于他們的業(yè)務場景可以接受。但Redis List做消息隊列的可靠性不如專業(yè)MQ——沒有ACK機制消費者掛了消息就丟了。持久化開了AOFappendfsync everysec每秒刷盤一次。最壞情況丟1秒的數據。對于文檔解析任務來說丟了就丟了——任務狀態(tài)在MySQL里解析失敗會自動重試消息丟了不過是多等一輪。Q5. Redis持久化期間宕機導致數據丟了怎么辦這道題面試官明顯在挖你對Redis持久化機制的理解深度。先說背景Redis持久化有兩種——RDB快照和AOF追加日志。RDB是定期把內存數據dump到磁盤AOF是每次寫命令追加到日志文件。宕機丟數據的情況分幾種RDB場景兩次快照之間的數據全丟。如果配置save 900 1最壞丟15分鐘的數據。AOF場景取決于fsync策略。always不丟但性能差everysec最壞丟1秒no交給操作系統(tǒng)可能丟幾十秒。AOF文件損壞宕機時AOF文件可能寫了一半用redis-check-aof工具修復。真正要保證數據不丟需要從架構層面解決主從復制哨兵主節(jié)點宕機從節(jié)點頂上。但異步復制可能丟最新寫入——如果主節(jié)點剛寫完還沒同步到從節(jié)點就掛了這部分數據就沒了。業(yè)務層兜底關鍵數據寫Redis的同時寫MySQLRedis掛了從MySQL恢復。Redis定位就是緩存不是主存儲。Redis Cluster WAIT命令WAIT可以讓客戶端等待指定數量的從節(jié)點確認同步完成再返回犧牲一點延遲換可靠性。核心結論Redis持久化是盡力而為不是萬無一失。真正不容丟的數據要雙寫MySQL做兜底Redis當緩存用。Q6. 用Redis當消息隊列不會導致額外維護一個中間件嗎這個問題問得很有水平。面試官其實在問“你嘴上說Redis復用省運維但Redis本身要不要維護你省了什么”他的回答是Redis已經在項目里了不需要額外維護。這里的關鍵判斷是基礎設施復用。如果你的項目本身就有Redis那用它的List/Stream做輕量級消息隊列增加的是功能維度的復用不是運維維度的負擔。但如果你的項目本身沒有Redis為了做消息隊列專門引入Redis那就本末倒置了——不如直接上RabbitMQ。另外Redis 5.0引入的Stream數據結構在消息隊列場景下比List強很多支持消費者組、ACK確認、消息回溯、阻塞讀取。本質上Redis Stream已經是一個輕量級MQ了對于低吞吐的場景完全夠用。Q7. 消費者不斷輪詢消息隊列空閑時浪費資源除了消息隊列還有什么異步方案這個追問很棒。面試官順著消息隊列往深處挖——你在用MQ但你理解MQ之外的選擇嗎注意他用的是BRPOP阻塞拉取不是輪詢——BRPOP在隊列為空時直接阻塞線程不會空轉消耗CPU。但面試官問的是如果不用消息隊列還有哪些異步處理方式那就展開了方案原理適用場景線程池異步任務主線程提交任務到線程池立即返回后臺線程執(zhí)行單機、任務量小、不需要持久化事件驅動Netty/Reactor事件到達時回調線程不阻塞等待高并發(fā)IO密集型場景定時任務輪詢DB定時掃MySQL待處理表取出狀態(tài)為待處理的記錄執(zhí)行容忍延遲、不想引入額外組件CompletableFuture鏈式編排異步任務編排thenApply/thenCompose組合多個異步步驟多步驟有依賴關系的異步任務如果從避免輪詢浪費資源這個角度核心解法是用阻塞等待替代輪詢用事件通知替代定時掃描。BRPOP是阻塞等待Kafka的Consumer.poll()本質也是阻塞等待有超時Netty的EventLoop是事件驅動——它們都不會讓CPU空轉。JUC線程池全鏈路Q8. 講一下線程池參數、工作原理、拒絕策略、用過什么線程池這是一道標準八股但面試官要的是你真正理解不是背參數。七個核心參數參數含義corePoolSize核心線程數即使空閑也不會被回收除非allowCoreThreadTimeOut設為truemaximumPoolSize最大線程數核心線程臨時線程的總上限keepAliveTime臨時線程空閑多久后被回收unitkeepAliveTime的時間單位workQueue任務隊列阻塞隊列核心線程忙時新任務先進隊列threadFactory線程工廠給線程起名字、設置daemon等handler拒絕策略隊列滿了且線程數達到max時觸發(fā)工作原理任務提交三步走第一步當前線程數 corePoolSize直接創(chuàng)建新線程執(zhí)行任務即使有空閑核心線程也優(yōu)先創(chuàng)建。第二步當前線程數 ≥ corePoolSize任務進入workQueue排隊。第三步隊列滿了且線程數 maximumPoolSize創(chuàng)建臨時線程執(zhí)行任務。第四步隊列滿了且線程數 maximumPoolSize觸發(fā)拒絕策略。這里有一個90%的人會畫錯的地方不是先擴線程再入隊而是先入隊再擴線程。只有隊列滿了才會創(chuàng)建超過corePoolSize的線程。這意味著如果你用無界隊列如LinkedBlockingQueue不設容量線程數永遠不會超過corePoolSize——maximumPoolSize參數形同虛設。四種拒絕策略策略行為適用AbortPolicy默認拋RejectedExecutionException關鍵任務必須感知到丟棄CallerRunsPolicy由提交任務的線程自己執(zhí)行不想丟任務用提交線程做緩沖DiscardPolicy直接丟棄不拋異常非關鍵任務丟了無所謂DiscardOldestPolicy丟棄隊列中最老的任務然后重試提交優(yōu)先保證最新任務實際用過什么線程池自定義線程池文檔解析用的IO密集型任務核心線程數CPU核數*2隊列用有界隊列1000拒絕策略用CallerRunsPolicy。Executors提供的幾個他基本不用newFixedThreadPool用無界隊列可能OOMnewCachedThreadPool最大線程數是Integer.MAX_VALUE也可能OOM。阿里巴巴規(guī)約明確禁止用Executors創(chuàng)建線程池。Redis大Key兩道題連起來打Q9. Redis某個Key很大有什么問題如何解決大Key的大沒有一個絕對標準但業(yè)界的經驗值是String類型超過10KB算大List/Hash/Set/ZSet元素超過5000個算大。大Key引發(fā)的問題阻塞Redis單線程Redis是單線程處理命令的。一個大Key的DEL操作如果數據量幾百萬條Redis會卡住幾百毫秒甚至幾秒期間所有請求都被阻塞。網絡帶寬打滿一個大Key的GET操作一次性返回幾MB數據如果并發(fā)拉取瞬間打滿網卡。主從同步抖動主節(jié)點執(zhí)行大Key操作后同步到從節(jié)點也慢集群擴縮容時數據遷移也更慢。內存不均Redis Cluster分片下大Key會導致某個分片內存嚴重傾斜熱點分片先OOM。解決方案拆分大KeyString類型壓縮gzip或拆成多個小Key。Hash類型按field拆分比如一個用戶的大Hash按field前綴拆成user:1:base、user:1:ext等。刪除用UNLINKRedis 4.0引入UNLINK命令異步刪除不阻塞主線程。分批刪除對于List/Set/ZSet用HSCAN/SSCAN/ZSCAN分批掃描LREM分批刪除每次刪少量。從源頭治理識別大Key的監(jiān)控手段——redis-cli --bigkeys掃一遍或者用Redis內存分析工具redis-rdb-tools分析RDB文件。Q10. 為什么大Key影響Redis性能——從單線程模型說起這道題是Q9的追問面試官要你講出底層原理不是只列現象。Redis的核心瓶頸是單線程事件循環(huán)。所有命令在一個線程里串行處理一個慢操作會卡住后面所有請求。大Key的每次操作——無論是GET整個值、DEL整個Key、還是遍歷所有元素——都會讓這個線程長時間占用CPU。舉個例子一個Hash有100萬元素執(zhí)行DEL keyRedis需要遍歷所有元素逐個釋放內存。這個操作在單線程中執(zhí)行期間Redis無法處理任何其他請求。如果這個DEL耗時500ms那這500ms內所有客戶端都在排隊等待。Redis 4.0引入的lazy free機制就是為了解決這個問題——UNLINK命令把釋放內存的操作交給后臺線程主線程只做解除引用這一步然后立刻返回。但根本解決方案還是從源頭避免大Key產生。大Key的本質不是存不下而是操作慢。單線程模型下任何O(N)操作都是定時炸彈。場景題五連從限流到可觀測性再到ThreadLocal跨線程這是整場面試含金量最高的部分。面試官沒有考八股而是基于真實業(yè)務場景追問每道題都踩在實際工程的要害上。Q11. 文件解析時用戶突然上傳很多文件服務器打滿如何決策這道題本質是流控和過載保護的組合題。面試官想看你有沒有系統(tǒng)性的防御思維。他的回答分三層第一層入口限流對上傳接口做速率限制比如單用戶每分鐘最多上傳10個文件超過直接返回429?？梢杂肦edis計數器滑動窗口實現。第二層隊列削峰上傳請求不直接觸發(fā)解析而是寫入消息隊列由消費者按固定速率消費。這樣即使前端瞬間涌入1000個文件后端解析線程只按自己的節(jié)奏處理不會被打滿。第三層過載保護監(jiān)控線程池隊列深度和CPU使用率。當隊列積壓超過閾值比如500觸發(fā)降級策略——新上傳的文件延遲解析返回文件已接收正在排隊或者暫停非核心功能釋放資源。面試官追問如果用戶上傳的是惡意文件呢他答了文件類型白名單校驗只允許PDF/Word/Markdown/TXT文件大小上限比如50MB以及解析超時熔斷單文件解析超過30秒直接kill并標記失敗。Q12. 如何明確線程數量如何找到哪個線程被阻塞線程數設定沒有萬能公式但有一個經驗口訣CPU密集型線程數 CPU核數 1。因為CPU密集型任務幾乎不阻塞多一個線程可以在某個線程因缺頁中斷等暫停時頂上。IO密集型線程數 CPU核數 * 2或者用公式CPU核數 / (1 - 阻塞系數)。阻塞系數在0.8-0.9之間意味著線程80%-90%時間在等待IO。實際做法先按公式算一個初始值然后壓測調優(yōu)。關鍵是動態(tài)調整——美團動態(tài)線程池的思路核心參數暴露到配置中心根據監(jiān)控指標自動擴縮。定位阻塞線程jstack最直接的工具。jstack [pid] 打出所有線程的堆?？煺照褺LOCKED或WAITING狀態(tài)的線程。BLOCKED是等鎖WAITING是等notify/條件。Arthas阿里的Java診斷工具。thread命令列出所有線程和CPU使用率thread -b 直接找出當前阻塞其他線程的罪魁禍首死鎖持有者。thread [id] 看某個線程的完整堆棧。線程池監(jiān)控給線程池加監(jiān)控暴露活躍線程數、隊列大小、完成任務數、拒絕次數。當活躍線程數持續(xù)等于最大線程數且隊列持續(xù)增長說明有線程被阻塞或者任務執(zhí)行過慢。Q13. 對外提供一個接口如何保障整個接口執(zhí)行過程中的可觀測性這道題面試官在考你對可觀測性三支柱的理解是否落地到了接口層面。他的回答分三個維度日志Logs每個請求分配一個全局唯一的traceId貫穿整個調用鏈。關鍵節(jié)點打日志——入口參數、出口返回值、調用了哪些下游、每個步驟的耗時。異常日志必須帶完整堆棧traceId。指標Metrics接口維度暴露四個黃金指標——QPS請求量、Latency延遲P50/P99、Error Rate錯誤率、Saturation線程池隊列深度、CPU使用率等飽和度指標。用Prometheus Grafana做采集和可視化。鏈路追蹤Traces用SkyWalking或Jaeger在接口入口生成traceId往下游傳遞HTTP header透傳或MQ message header攜帶全鏈路串聯。出問題時靠traceId在日志平臺一鍵搜出所有相關日志。落地層面Spring Boot項目最簡單的方式是引入Micrometer SkyWalking Agent幾乎零侵入。Micrometer負責指標暴露SkyWalking Agent負責鏈路追蹤和自動埋點。Q14. 多個方法連續(xù)調用如何在無侵入的情況下通過日志查看調用鏈AOP原理這道題是Q13的延續(xù)面試官在問可觀測性的具體落地手段。無侵入方案用Spring AOP寫一個切面對所有Service層方法做環(huán)繞通知。在Around中方法執(zhí)行前打印方法名入參執(zhí)行后打印方法名出參耗時異常時打印方法名異常信息。關鍵是把traceId打在每一行日志里用MDCMapped Diagnostic Context自動注入。AOP的原理Spring AOP基于動態(tài)代理有兩種實現方式JDK動態(tài)代理目標類實現了接口Spring用java.lang.reflect.Proxy生成代理對象代理對象實現了和目標類相同的接口。調用代理對象的方法時實際調用InvocationHandler.invoke()在這里織入增強邏輯。CGLIB代理目標類沒有實現接口Spring用CGLIB生成目標類的子類作為代理對象。調用代理對象的方法時通過MethodInterceptor.intercept()織入增強邏輯。Spring AOP默認使用JDK動態(tài)代理如果目標類沒有實現接口則自動切換CGLIB。也可以通過proxy-target-classtrue強制使用CGLIB。一個常見坑同一個類內部方法調用不走代理。比如A方法調用B方法如果調用方和被調用方在同一個類里B方法的AOP增強不會生效——因為this.B()是直接調用不經過代理對象。Q15. 線程池ThreadLocal如何解決跨線程傳遞參數這是整場他唯一卡住的題。背景ThreadLocal是線程綁定的每個線程有自己獨立的ThreadLocalMap。當你把任務提交到線程池任務從主線程換到工作線程執(zhí)行ThreadLocal里的值就丟了。面試官提示他“線程池在執(zhí)行任務時實際上都是使用Runnable接口來執(zhí)行的可以在run方法上做文章?！笔潞笪?guī)退砹巳N解法方案一手動傳遞最原始在主線程把ThreadLocal的值取出來作為參數傳給Runnable的構造方法在工作線程的run方法開頭手動set進去finally塊里remove。缺點是每個任務都要寫一遍侵入性強。方案二裝飾器模式面試官提示的方向寫一個TaskDecorator或者包裝Runnable在run方法執(zhí)行前從主線程獲取ThreadLocal的值set到工作線程的ThreadLocal中執(zhí)行完再清理。Spring的ThreadPoolTaskExecutor原生支持TaskDecorator接口。方案三InheritableThreadLocal適用于簡單場景用InheritableThreadLocal代替ThreadLocal子線程創(chuàng)建時會自動繼承父線程的值。但注意——線程池的線程是復用的只在創(chuàng)建時繼承一次之后不再更新。所以這個方案在線程池場景下基本不可靠。方案四TransmittableThreadLocal阿里開源生產推薦阿里開源的transmittable-thread-local庫通過TtlRunnable包裝原始Runnable在提交任務時捕獲當前線程的ThreadLocal快照在執(zhí)行時回放快照值執(zhí)行完恢復。這個方案完美解決了線程池復用場景下的ThreadLocal傳遞問題。面試官提示的在run方法上做文章本質上就是裝飾器模式——對Runnable做一層包裝在run的前后插入ThreadLocal值的捕獲和回放邏輯。阿里的TransmittableThreadLocal就是這個思路的工業(yè)級實現。手撕代碼LC215. 數組中的第K大元素Q16. 手寫快速選擇算法題目給定整數數組nums和整數k返回數組中第k個最大的元素不是第k個不同的元素。他選了快速選擇QuickSelect——基于快速排序的分區(qū)思想平均時間復雜度O(n)最壞O(n2)。核心邏輯每次選一個pivot把數組分成大于pivot和小于pivot兩部分。如果pivot的位置正好是第k大返回如果pivot位置比k大說明答案在左邊遞歸左邊否則遞歸右邊。注意這里的第k大是從大到小排所以分區(qū)時大的放左邊小的放右邊。public int findKthLargest(int[] nums, int k) {int target nums.length - k;return quickSelect(nums, 0, nums.length - 1, target);}private int quickSelect(int[] nums, int left, int right, int target) {int pivotIndex partition(nums, left, right);if (pivotIndex target) {return nums[pivotIndex];} else if (pivotIndex target) {return quickSelect(nums, left, pivotIndex - 1, target);} else {return quickSelect(nums, pivotIndex 1, right, target);}}private int partition(int[] nums, int left, int right) {int pivot nums[right];int i left;for (int j left; j right; j) {if (nums[j] pivot) {swap(nums, i, j);i;}}swap(nums, i, right);return i;}private void swap(int[] nums, int i, int j) {int tmp nums[i];nums[i] nums[j];nums[j] tmp;}時間復雜度O(n)平均最壞O(n2)在數組已排序時出現。優(yōu)化方式隨機選擇pivotRandomized QuickSelect把最壞情況概率降到極低。面試標準答案速查如果你正在準備類似的引擎架構/后端開發(fā)面試下面這些一句結論可以直接背#面試時可以說出口的一句話1短期記憶滑動窗口摘要壓縮長期記憶結構化存儲向量檢索2知識庫上傳OSS接收→異步解析→語義分片→向量化入庫每個環(huán)節(jié)都帶冪等和重試3Redis在項目里做緩存分布式鎖消息隊列三個角色共用一套基礎設施4Redis選型基礎設施復用優(yōu)先單獨為MQ引入Redis不如直接上RabbitMQ5Redis持久化宕機丟數據→主從哨兵減少損失關鍵數據雙寫MySQL兜底6Redis當MQ復用已有組件Redis Stream支持ACK和消費者組輕量場景夠用7異步方案線程池、事件驅動、定時輪詢DB、CompletableFuture核心是用阻塞等待替代輪詢8線程池核心線程→隊列→最大線程→拒絕先入隊再擴線程無界隊列讓max參數失效9大Key問題阻塞單線程打滿帶寬主從同步抖動內存不均10大Key影響性能Redis單線程O(N)操作阻塞所有請求UNLINK異步刪除緩解11文件上傳打滿入口限流隊列削峰過載保護三層防御12線程數CPU密集型N1IO密集型N*2。定位阻塞jstackArthas thread -b13可觀測性traceId貫穿全鏈路日志指標鏈路追蹤三支柱14無侵入調用鏈Spring AOP環(huán)繞通知MDC自動注入traceIdAOP原理JDK動態(tài)代理/CGLIB15ThreadLocal跨線程裝飾器包裝Runnable捕獲快照回放生產用TransmittableThreadLocal16第K大快速選擇O(n)隨機pivot防退化比堆排序O(nlogk)更優(yōu)復盤總結看完這份復盤我最想聊的不是具體某道題而是這個面試官的提問方式。他的每一道題都不是孤立的知識點考察而是沿著一個方向層層深入從Redis做什么→為什么選Redis→宕機了怎么辦→當MQ不會額外維護嗎→除了MQ還有什么異步方案這是技術選型的縱深追問。從大Key有什么問題→為什么大Key影響性能這是從現象到原理的追問。從可觀測性→無侵入調用鏈→AOP原理→ThreadLocal跨線程這是從架構到實現的追問。這種面試方式不會的人覺得被步步緊逼會的人覺得酣暢淋漓——這位學員顯然是后者。不是因為每道題都答對了ThreadLocal那道確實卡了而是因為面試官在你卡住的時候他不是沉默等你自己掙扎而是給你一個方向讓你自己推出來。這種半引導半考察的節(jié)奏比壓力面更能測出真實水平。如果你也在準備同類面試我拆解完這份面經后覺得有三點值得記住不要只背八股要能講出為什么選它。面試官問Redis穩(wěn)定性如何不是在考你Redis的HA方案而是在看你做技術選型的時候有沒有考慮過trade-off。場景題沒有標準答案但有標準思路。限流→削峰→降級→監(jiān)控這是處理高負載問題的標準公式。ThreadLocal跨線程→裝飾器模式→TransmittableThreadLocal這是處理線程上下文傳遞的標準路線?？ㄗ〔豢膳碌阋芙幼∶嬖嚬俚囊龑?。ThreadLocal那道題面試官說線程池執(zhí)行任務用的是Runnable這個提示其實已經把答案放到嘴邊了——包裝Runnable、在run方法前后做文章。如果這都接不住才是真的減分。好的面試不是你會不會而是你能不能學會。學AI大模型的正確順序千萬不要搞錯了2026年AI風口已來各行各業(yè)的AI滲透肉眼可見超多公司要么轉型做AI相關產品要么高薪挖AI技術人才機遇直接擺在眼前有往AI方向發(fā)展或者本身有后端編程基礎的朋友直接沖AI大模型應用開發(fā)轉崗超合適就算暫時不打算轉崗了解大模型、RAG、Prompt、Agent這些熱門概念能上手做簡單項目也絕對是求職加分王給大家整理了超全最新的AI大模型應用開發(fā)學習清單和資料手把手幫你快速入門學習路線:?大模型基礎認知—大模型核心原理、發(fā)展歷程、主流模型GPT、文心一言等特點解析?核心技術模塊—RAG檢索增強生成、Prompt工程實戰(zhàn)、Agent智能體開發(fā)邏輯?開發(fā)基礎能力—Python進階、API接口調用、大模型開發(fā)框架LangChain等實操?應用場景開發(fā)—智能問答系統(tǒng)、企業(yè)知識庫、AIGC內容生成工具、行業(yè)定制化大模型應用?項目落地流程—需求拆解、技術選型、模型調優(yōu)、測試上線、運維迭代?面試求職沖刺—崗位JD解析、簡歷AI項目包裝、高頻面試題匯總、模擬面經以上6大模塊看似清晰好上手實則每個部分都有扎實的核心內容需要吃透我把大模型的學習全流程已經整理好了抓住AI時代風口輕松解鎖職業(yè)新可能希望大家都能把握機遇實現薪資/職業(yè)躍遷這份完整版的大模型 AI 學習資料已經上傳CSDN朋友們如果需要可以微信掃描下方CSDN官方認證二維碼免費領取【保證100%免費】