文 / 勇哥 原創文章，轉載請聯繫授權 關注公眾號「六邊形架構」，及時瞭解更多的技術分享和項目經驗 在前兩篇文章中，我們探討了《大模型應用開發技術路線（上）：從概念到RAG實戰指南》和《大模型應用開發技術路線（中）：大模型微調與定製實戰指南》。今天，讓我們繼續探索大模型應用開發的前沿技術路線——智能代理(Agent)開發和多模態應用開發。 作為一名在AI領域"衝浪"多年的技術老兵
昵稱 六邊形架構
MySQL索引最左原則：從原理到實戰的深度解析 一、什麼是索引最左原則？ 索引最左原則是MySQL複合索引使用的核心規則，簡單來説： "當使用複合索引（多列索引）時，查詢條件必須從索引的最左列開始，且不能跳過中間的列，否則索引將無法完全生效" 為什麼會有這個原則？ 這與B+樹索引的存儲結構密切相關： 複合索引按照定義時的列順序構建 數據先按第一列排序 第一列相同的情況下按第二列排序 依此
昵稱 DBLens
用 LangChain 構建 AI Agent 的人應該都遇到過這種情況：測試階段一切正常，部署到生產環境就開始出各種問題。上下文管理混亂，Agent 的行為變得難以預測，最後不得不寫一堆自定義代碼來控制信息流向。 這是因為在v1.0 之前的 LangChain 對上下文工程的支持不夠系統化。上下文工程的本質其實就是信息管理——給 AI 多少信息、什麼時候給、以什麼方式給。信息過載會導致模型困惑，
昵稱 deephub
在開發知識問答助手的過程中，常見的挑戰之一就是如何讓智能體記住之前的對話和交互內容。 很多應用在實現多輪問答時，會遇到信息丟失或上下文混亂的問題：用户提過的問題、提供的數據、甚至助手之前的回答都無法被系統持續記憶，導致體驗斷層。對於企業級知識庫或面向用户的個人助手來説，這種缺失不僅影響回答的準確性，也使得智能體難以形成長期價值。 構建一個能夠記憶的問答系統，並非簡單地將對話記錄寫入數據庫。 智能
昵稱 商湯萬象開發者
很多團隊把它vLLM 當 demo 跑，但是其實這沒把它系統能力發揮出來。這篇文章將介紹怎麼讓 vLLM 真正幹活——持續輸出高令牌/秒，哪些參數真正有用，以及怎麼在延遲和成本之間做取捨。 先説 vLLM 到底好在哪 vLLM 提供 OpenAI 兼容的 API，核心是 continuous batching 加上 PagedAttention。PagedAttention 用分頁管理 K
昵稱 deephub
