簡(jiǎn)介這份資源是一套基于PHP與ThinkPHP框架的運(yùn)營級(jí)在線客服系統(tǒng)源碼重點(diǎn)解決客服系統(tǒng)接入AI知識(shí)庫的問題適合有一定PHP基礎(chǔ)、希望搭建企業(yè)級(jí)智能客服的開發(fā)者與運(yùn)維人員。壓縮包共2010個(gè)文件約68.72MB以613個(gè)js、368個(gè)html、258個(gè)css等前端資源為主配合131個(gè)php業(yè)務(wù)代碼、3個(gè)sql數(shù)據(jù)庫腳本及大量xml、json、md配置與說明文檔整體結(jié)構(gòu)完整便于二次開發(fā)與部署。資源附帶安裝教程涵蓋fileinfo、redis插件安裝以及pcntl_signal、pcntl_fork等禁用函數(shù)的配置說明幫助讀者快速完成環(huán)境搭建。目前已有137人學(xué)習(xí)下載。通過該源碼讀者可掌握AI知識(shí)庫與在線客服的對(duì)接思路理解NLP問答匹配、緩存加速與ThinkPHP模塊化開發(fā)并獲得一套可直接運(yùn)行、便于擴(kuò)展的客服系統(tǒng)實(shí)踐參考。1. 從工單到知識(shí)庫PHP 在線客服接入 AI 的落地路徑很多團(tuán)隊(duì)做在線客服系統(tǒng)第一版都是「人工坐席 常見問題靜態(tài)頁」用戶問一句、客服查半天響應(yīng)慢、口徑還不統(tǒng)一。這套基于 PHP 的在線客服接入 AI 知識(shí)庫方案解決的就是這個(gè)斷層把歷史工單、產(chǎn)品文檔、FAQ 沉淀成可檢索的知識(shí)庫用戶提問時(shí)先由 AI 召回并生成回答答不上來再轉(zhuǎn)人工。它適合用 ThinkPHP 做后臺(tái)、已經(jīng)有一套客服工單表結(jié)構(gòu)、想低成本加一層智能問答的團(tuán)隊(duì)。整套邏輯不依賴重型框架核心是「知識(shí)入庫 → 向量或關(guān)鍵詞召回 → 拼 Prompt → 調(diào)模型 → 回寫會(huì)話」這條鏈路PHP 側(cè)負(fù)責(zé)調(diào)度和兜底模型側(cè)只做生成。下面按落地順序拆開講從環(huán)境到代碼到踩坑能直接照著改。2. 知識(shí)庫接入前的環(huán)境與數(shù)據(jù)準(zhǔn)備ThinkPHP 側(cè)要先把地基打平2.1 為什么選 ThinkPHP 做調(diào)度層而不是純腳本在線客服系統(tǒng)本身有會(huì)話、坐席、工單、消息幾張核心表ThinkPHP 的模型和查詢構(gòu)造器能直接復(fù)用現(xiàn)有連接不用為了接 AI 再搭一套服務(wù)。常見做法是把 AI 問答封裝成一個(gè) Service 類在消息入庫的鉤子里調(diào)用而不是單獨(dú)起一個(gè)進(jìn)程。這樣會(huì)話上下文、用戶身份、歷史消息都能順手拿到省掉一次跨服務(wù)查詢。選型上不建議一上來就上向量數(shù)據(jù)庫中小體量用 MySQL 全文索引或關(guān)鍵詞匹配先跑通等知識(shí)條目過萬再考慮 embedding 方案否則運(yùn)維成本會(huì)吃掉收益。環(huán)境上PHP 建議 8.0 以上ThinkPHP 6.x擴(kuò)展需要curl、mbstring、json、pdo_mysql。如果本地用 phpstudy 或小皮面板注意 PHP 版本和 CLI 版本要一致否則命令行跑遷移腳本時(shí)會(huì)報(bào)擴(kuò)展缺失。下面先建知識(shí)庫表。-- 知識(shí)條目表存 FAQ、文檔片段、歷史優(yōu)質(zhì)回答 CREATE TABLE kb_article ( id int unsigned NOT NULL AUTO_INCREMENT, title varchar(255) NOT NULL DEFAULT COMMENT 條目標(biāo)題, content text NOT NULL COMMENT 正文用于召回和拼 Prompt, keywords varchar(500) NOT NULL DEFAULT COMMENT 逗號(hào)分隔關(guān)鍵詞提升召回, category_id int unsigned NOT NULL DEFAULT 0 COMMENT 分類對(duì)應(yīng)產(chǎn)品線, status tinyint NOT NULL DEFAULT 1 COMMENT 1啟用 0停用, updated_at int unsigned NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_category (category_id), FULLTEXT KEY ft_content (title,content) WITH PARSER ngram ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTAI知識(shí)庫條目;邏輯說明content是召回主體keywords用來補(bǔ)全文索引對(duì)短詞不敏感的問題category_id讓不同產(chǎn)品線互不串味。WITH PARSER ngram是 MySQL 5.7 對(duì)中文全文檢索的支持沒加這個(gè)中文分詞基本失效。參數(shù)上ngram_token_size默認(rèn) 2意味著至少兩個(gè)漢字才能命中單字查詢會(huì)漏這是后面避坑章要展開的點(diǎn)。2.2 把歷史工單清洗成知識(shí)條目直接拿原始工單喂給模型效果很差因?yàn)楣卫镉写罅俊改愫谩埂冈趩帷埂皋D(zhuǎn)人工」這類噪聲。清洗思路是只保留客服最終回復(fù)且用戶未再追問的會(huì)話把用戶首問作為title客服回復(fù)作為content再從首問里抽關(guān)鍵詞。下面是一個(gè)批量導(dǎo)入腳本。?php // 命令行執(zhí)行php think kb:import namespace app\command; use think\console\Command; use think\console\Input; use think\console\Output; use think\facade\Db; class KbImport extends Command { protected function configure() { $this-setName(kb:import)-setDescription(清洗工單并導(dǎo)入知識(shí)庫); } protected function execute(Input $input, Output $output) { // 只取已關(guān)閉且客服有最終回復(fù)的會(huì)話 $rows Db::name(chat_session) -alias(s) -join(chat_message m, m.session_id s.id) -where(s.status, 2) -where(m.role, agent) -field(s.id, s.first_question, m.content, m.create_time) -order(m.create_time desc) -limit(2000) -select(); $batch []; foreach ($rows as $r) { $q trim($r[first_question]); $a trim(strip_tags($r[content])); // 過濾過短和純寒暄內(nèi)容 if (mb_strlen($q) 4 || mb_strlen($a) 10) { continue; } if (preg_match(/^(你好|在嗎|轉(zhuǎn)人工|有人嗎)/u, $q)) { continue; } $batch[] [ title mb_substr($q, 0, 100), content $a, keywords $this-extractKeywords($q), category_id 1, status 1, updated_at time(), ]; } if ($batch) { Db::name(kb_article)-insertAll($batch); } $output-writeln(導(dǎo)入條數(shù) . count($batch)); } // 簡(jiǎn)易關(guān)鍵詞抽取按標(biāo)點(diǎn)和停用詞切分 private function extractKeywords(string $q): string { $stop [的,了,嗎,呢,怎么,如何,請(qǐng)問]; $q str_replace($stop, , $q); $parts preg_split(/[\s,。?!]/u, $q, -1, PREG_SPLIT_NO_EMPTY); return implode(,, array_slice(array_unique($parts), 0, 5)); } }邏輯說明status2表示會(huì)話已結(jié)束roleagent取客服消息避免把用戶追問也當(dāng)成答案。mb_strlen過濾掉過短內(nèi)容正則過濾寒暄。extractKeywords是兜底方案停用詞表按自己業(yè)務(wù)補(bǔ)比如電商要加「發(fā)貨」「退款」。參數(shù)上limit(2000)是防止一次性拉爆內(nèi)存實(shí)際可以分批跑。跑完用SELECT COUNT(*) FROM kb_article確認(rèn)條數(shù)再抽查幾條看content有沒有混入 HTML 標(biāo)簽。提示導(dǎo)入前先備份kb_article清洗規(guī)則調(diào)一次可能要重跑有備份就不用后悔藥。3. 召回與拼 Prompt讓 AI 答得像你們自己的客服3.1 關(guān)鍵詞召回與全文索引的取舍召回質(zhì)量直接決定回答質(zhì)量。中小體量下MySQL 全文索引夠用但中文場(chǎng)景有兩個(gè)坑一是ngram_token_size最小 2單字詞查不到二是全文索引對(duì)keywords字段不生效因?yàn)樯厦嬷唤otitle和content建了索引。常見做法是先用keywords做一次 LIKE 匹配再用全文索引兜底兩路結(jié)果合并去重。下面是對(duì)外暴露的召回方法。?php namespace app\service; use think\facade\Db; class KbRecall { /** * param string $question 用戶問題 * param int $categoryId 產(chǎn)品線 * param int $topN 返回條數(shù) */ public function recall(string $question, int $categoryId 0, int $topN 3): array { $question trim($question); if ($question ) { return []; } // 第一路關(guān)鍵詞 LIKE命中快適合短查詢 $like Db::name(kb_article) -where(status, 1) -where(function ($q) use ($question) { $q-whereLike(keywords, % . $question . %) -whereOr(title, like, % . $question . %); }) -when($categoryId 0, function ($q) use ($categoryId) { $q-where(category_id, $categoryId); }) -limit($topN) -select()-toArray(); // 第二路全文索引適合長(zhǎng)句 $fulltext []; if (mb_strlen($question) 2) { $fulltext Db::name(kb_article) -where(status, 1) -whereRaw( MATCH(title, content) AGAINST(:q IN NATURAL LANGUAGE MODE), [q $question] ) -when($categoryId 0, function ($q) use ($categoryId) { $q-where(category_id, $categoryId); }) -limit($topN) -select()-toArray(); } // 合并去重保留順序 $merged []; foreach (array_merge($like, $fulltext) as $item) { $merged[$item[id]] $item; } return array_slice(array_values($merged), 0, $topN); } }邏輯說明whereLike那一路對(duì)keywords和title同時(shí)匹配解決全文索引對(duì)短詞不敏感的問題MATCH ... AGAINST那一路處理長(zhǎng)句。when是 ThinkPHP 的條件構(gòu)造categoryId為 0 時(shí)不加分類過濾。參數(shù)topN建議 3 到 5太多會(huì)撐大 Prompt 導(dǎo)致模型跑偏太少召回不全。注意whereRaw里用了綁定參數(shù)別直接拼字符串否則有注入風(fēng)險(xiǎn)。3.2 拼 Prompt 的模板與上下文控制召回結(jié)果不能直接丟給模型要拼成結(jié)構(gòu)化 Prompt明確告訴模型「只根據(jù)以下資料回答資料沒有就說不知道」。這樣能大幅降低胡編。下面是一個(gè)可復(fù)用的 Prompt 構(gòu)造方法。?php namespace app\service; class PromptBuilder { public function build(string $question, array $articles): array { $context ; foreach ($articles as $i $a) { $no $i 1; $context . 【資料{$no}】{$a[title]}\n{$a[content]}\n\n; } $system 你是一名在線客服助手。只能依據(jù)下面提供的資料回答用戶問題。 . 資料中沒有的內(nèi)容直接回復(fù)「這個(gè)問題我需要轉(zhuǎn)人工幫您確認(rèn)」。 . 回答要簡(jiǎn)潔不超過 150 字不要編造資料外的信息。; $user 資料如下\n{$context}用戶問題{$question}; return [ [role system, content $system], [role user, content $user], ]; } }邏輯說明system里三條約束是關(guān)鍵——限定來源、限定兜底話術(shù)、限定長(zhǎng)度。context拼接時(shí)給每條資料編號(hào)方便模型引用。參數(shù)上如果content很長(zhǎng)要做截?cái)鄦螚l建議不超過 800 字總上下文控制在模型窗口的三分之一以內(nèi)留出余量給用戶問題和模型輸出。常見做法是在build前先按updated_at排序優(yōu)先用新資料。注意Prompt 里的兜底話術(shù)要和你們轉(zhuǎn)人工的關(guān)鍵詞對(duì)齊否則用戶看到「轉(zhuǎn)人工」但系統(tǒng)沒觸發(fā)轉(zhuǎn)接體驗(yàn)會(huì)斷。4. 調(diào)用模型與回寫會(huì)話把 AI 回答接進(jìn)現(xiàn)有消息流4.1 封裝模型調(diào)用與超時(shí)重試模型調(diào)用是整條鏈路最容易翻車的地方網(wǎng)絡(luò)抖動(dòng)、限流、返回格式異常都會(huì)遇到。封裝時(shí)要設(shè)超時(shí)、重試和降級(jí)。下面用 curl 封裝一個(gè)通用調(diào)用方法兼容常見的對(duì)話補(bǔ)全接口。?php namespace app\service; class AiClient { private string $endpoint; private string $apiKey; private int $timeout 8; public function __construct(string $endpoint, string $apiKey) { $this-endpoint $endpoint; $this-apiKey $apiKey; } /** * param array $messages PromptBuilder 產(chǎn)出的消息數(shù)組 * return string 模型回答失敗返回空串 */ public function chat(array $messages): string { $payload json_encode([ model your-model-name, messages $messages, temperature 0.3, max_tokens 300, ], JSON_UNESCAPED_UNICODE); for ($i 0; $i 2; $i) { // 最多重試一次 $ch curl_init($this-endpoint); curl_setopt_array($ch, [ CURLOPT_RETURNTRANSFER true, CURLOPT_POST true, CURLOPT_POSTFIELDS $payload, CURLOPT_TIMEOUT $this-timeout, CURLOPT_HTTPHEADER [ Content-Type: application/json, Authorization: Bearer . $this-apiKey, ], ]); $resp curl_exec($ch); $code curl_getinfo($ch, CURLINFO_HTTP_CODE); $err curl_error($ch); curl_close($ch); if ($code 200 $resp) { $data json_decode($resp, true); $text $data[choices][0][message][content] ?? ; if ($text ! ) { return trim($text); } } // 記錄日志便于排查別把 key 寫進(jìn)去 trace(ai_call_fail code{$code} err{$err}, error); usleep(300000); // 等 300ms 再試 } return ; } }邏輯說明temperature設(shè) 0.3 是為了讓客服回答穩(wěn)定不要發(fā)揮max_tokens300 對(duì)應(yīng) 150 字左右。重試只做一次避免雪崩。trace是 ThinkPHP 的日志助手記錄時(shí)不要帶apiKey。參數(shù)上timeout8 秒是經(jīng)驗(yàn)值超過這個(gè)時(shí)間用戶已經(jīng)等不及了不如直接走兜底。4.2 在消息入庫鉤子里接入并回寫AI 回答生成后要寫回chat_message表并標(biāo)記來源方便后續(xù)統(tǒng)計(jì)命中率。下面是在消息服務(wù)里的接入片段。?php namespace app\service; use think\facade\Db; class ChatService { public function handleUserMessage(int $sessionId, string $question): array { // 1. 先入庫用戶消息 Db::name(chat_message)-insert([ session_id $sessionId, role user, content $question, create_time time(), ]); // 2. 召回 拼 Prompt $recall new KbRecall(); $articles $recall-recall($question, 1, 3); // 3. 沒召回到直接轉(zhuǎn)人工不浪費(fèi)一次模型調(diào)用 if (empty($articles)) { return [type transfer, msg 這個(gè)問題我需要轉(zhuǎn)人工幫您確認(rèn)]; } $builder new PromptBuilder(); $messages $builder-build($question, $articles); // 4. 調(diào)模型 $client new AiClient(config(ai.endpoint), config(ai.key)); $answer $client-chat($messages); // 5. 模型失敗也轉(zhuǎn)人工 if ($answer ) { return [type transfer, msg 這個(gè)問題我需要轉(zhuǎn)人工幫您確認(rèn)]; } // 6. 回寫 AI 消息source 標(biāo)記來源 Db::name(chat_message)-insert([ session_id $sessionId, role ai, content $answer, source kb, create_time time(), ]); return [type ai, msg $answer]; } }邏輯說明先入庫用戶消息保證會(huì)話完整召回為空直接轉(zhuǎn)人工省調(diào)用成本模型失敗也轉(zhuǎn)人工保證不冷場(chǎng)。sourcekb方便后面統(tǒng)計(jì) AI 命中率。參數(shù)上recall的categoryId傳 1 是示例實(shí)際按用戶當(dāng)前咨詢的產(chǎn)品線傳。注意config(ai.key)要放在.env或獨(dú)立配置文件里別硬編碼進(jìn)代碼。提示上線前先用幾條真實(shí)問題跑一遍看召回條數(shù)和回答是否對(duì)得上別直接放全量流量。5. 避坑與排查接入 AI 知識(shí)庫最常見的五個(gè)翻車點(diǎn)5.1 中文全文索引查不到短詞現(xiàn)象用戶問「退款」召回結(jié)果為空但知識(shí)庫明明有退款條目。原因是ngram_token_size默認(rèn) 2單字和部分雙字詞在全文索引里匹配不到。解決短查詢走keywords的 LIKE 那一路或者把ngram_token_size調(diào)到 1 并重建索引。調(diào)小會(huì)增加索引體積權(quán)衡后我一般保留 2靠 LIKE 兜底。5.2 模型回答里出現(xiàn)資料外的內(nèi)容現(xiàn)象知識(shí)庫沒有的內(nèi)容AI 也編了一段。原因是 Prompt 約束不夠強(qiáng)或者temperature太高。解決system里明確「只能依據(jù)資料」temperature壓到 0.3 以下并在代碼里做一次校驗(yàn)——如果回答里出現(xiàn)資料中沒有的關(guān)鍵實(shí)體直接替換成兜底話術(shù)。5.3 curl 調(diào)用偶發(fā)超時(shí)導(dǎo)致用戶干等現(xiàn)象高峰期部分用戶消息發(fā)出后十幾秒沒反應(yīng)。原因是模型接口超時(shí)沒設(shè)或設(shè)太長(zhǎng)。解決CURLOPT_TIMEOUT設(shè) 8 秒超時(shí)后走轉(zhuǎn)人工別讓用戶等。同時(shí)加日志統(tǒng)計(jì)超時(shí)率超過 5% 要考慮換接口或加緩存。5.4 知識(shí)庫條目重復(fù)導(dǎo)致召回冗余現(xiàn)象同一個(gè)問題召回三條內(nèi)容幾乎一樣的資料Prompt 被撐大。原因是導(dǎo)入時(shí)沒去重。解決導(dǎo)入前按title做一次GROUP BY去重或者用keywords做相似度過濾。我一般會(huì)在導(dǎo)入腳本里加一步SELECT title, COUNT(*) FROM kb_article GROUP BY title HAVING COUNT(*) 1檢查。5.5 會(huì)話上下文丟失導(dǎo)致多輪對(duì)話答非所問現(xiàn)象用戶追問「那這個(gè)要多久」AI 答的是上一個(gè)不相關(guān)的問題。原因是每次只拿當(dāng)前問題去召回沒帶歷史。解決召回時(shí)把最近兩輪用戶消息拼進(jìn)去一起查或者在 Prompt 里帶上最近一輪問答。注意別把整個(gè)會(huì)話歷史都塞進(jìn)去會(huì)超上下文。6. 進(jìn)階用緩存和命中率統(tǒng)計(jì)把成本壓下來跑通之后最該做的是兩件事緩存高頻問題和統(tǒng)計(jì)命中率。高頻問題比如「怎么退款」「發(fā)貨時(shí)間」每天被問幾百次每次都調(diào)模型是浪費(fèi)。常見做法是用 Redis 緩存「問題 → 回答」key 用問題歸一化后的哈希過期時(shí)間設(shè) 1 小時(shí)。歸一化就是去掉標(biāo)點(diǎn)、轉(zhuǎn)小寫、去空格這樣「怎么退款」和「怎么退款」能命中同一條。?php // 在 ChatService 調(diào)模型前加一層緩存 $cacheKey kb_ans: . md5(mb_strtolower(preg_replace(/[\s,。?!]/u, , $question))); $cached cache($cacheKey); if ($cached) { return [type ai, msg $cached, from cache]; } // ... 調(diào)模型拿到 $answer 后 cache($cacheKey, $answer, 3600);邏輯說明preg_replace做歸一化md5生成定長(zhǎng) keycache是 ThinkPHP 的緩存助手底層配 Redis。過期時(shí)間 3600 秒是平衡新鮮度和命中率的值知識(shí)庫更新頻繁就調(diào)短。注意緩存要區(qū)分產(chǎn)品線否則 A 產(chǎn)品的答案會(huì)串到 B 產(chǎn)品可以在 key 里拼categoryId。命中率統(tǒng)計(jì)則是給chat_message加一個(gè)source字段前面已經(jīng)加了定期跑 SQL 看 AI 回答占比和轉(zhuǎn)人工占比。如果轉(zhuǎn)人工率超過 40%說明知識(shí)庫覆蓋不夠該補(bǔ)條目了如果 AI 回答里用戶緊接著又追問同一問題說明回答質(zhì)量不行該優(yōu)化 Prompt 或換模型。我一般每周跑一次這個(gè)統(tǒng)計(jì)把轉(zhuǎn)人工率高的問題撈出來人工補(bǔ)進(jìn)知識(shí)庫形成閉環(huán)。從那以后我每次接新的知識(shí)庫都強(qiáng)制先跑一周的召回日志再調(diào) Prompt不然根本不知道模型在哪些問題上翻車。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取