如果你是一名機(jī)械工程師、產(chǎn)品設(shè)計(jì)師或3D打印愛好者是否經(jīng)歷過這樣的深夜崩潰從客戶或供應(yīng)商那里收到一個(gè)復(fù)雜的CAD模型文件比如STEP或OBJ格式導(dǎo)入自己的設(shè)計(jì)軟件后要么報(bào)錯(cuò)崩潰要么模型顯示異?！砻嫫贫?、法線翻轉(zhuǎn)、實(shí)體變曲面甚至直接導(dǎo)致后續(xù)的仿真或制造流程失敗。傳統(tǒng)的解決方案是什么手動(dòng)在CAD軟件里一點(diǎn)點(diǎn)檢查、修復(fù)或者依賴軟件自帶的、功能有限且規(guī)則僵硬的“幾何檢查”工具。這個(gè)過程不僅耗時(shí)而且高度依賴工程師的個(gè)人經(jīng)驗(yàn)。一個(gè)復(fù)雜的裝配體其潛在的錯(cuò)誤組合是海量的人工審查幾乎不可能全覆蓋。那么一個(gè)自然而然的“技術(shù)幻想”就產(chǎn)生了能否用現(xiàn)在最火的AI技術(shù)——RAG檢索增強(qiáng)生成——來自動(dòng)化審計(jì)CAD文件智能地找出并甚至修復(fù)其中的錯(cuò)誤這個(gè)想法聽起來非常誘人讓AI學(xué)習(xí)海量的CAD標(biāo)準(zhǔn)、最佳實(shí)踐和常見錯(cuò)誤案例然后像一位經(jīng)驗(yàn)豐富的專家一樣自動(dòng)審查你提交的模型。但這真的是解決CAD審計(jì)問題的“銀彈”嗎還是說它只是一個(gè)聽起來很酷但實(shí)際落地時(shí)處處是坑的技術(shù)噱頭本文將深入探討“使用RAG審計(jì)CAD文件”這一命題。我不會(huì)只告訴你RAG是什么而是會(huì)結(jié)合CAD數(shù)據(jù)處理的特殊性分析這套方案真正能解決什么問題其技術(shù)邊界在哪里以及現(xiàn)階段它更適合誰。更重要的是我將提供一個(gè)完整的、可運(yùn)行的實(shí)踐框架基于Spring Boot、Milvus向量數(shù)據(jù)庫和LangChain4J手把手帶你搭建一個(gè)針對(duì)CAD文本元數(shù)據(jù)注意是元數(shù)據(jù)進(jìn)行智能問答的RAG系統(tǒng)。你會(huì)發(fā)現(xiàn)真正的價(jià)值可能不在于讓AI“看懂”三維幾何而在于讓它“理解”圍繞三維模型產(chǎn)生的那座信息冰山。1. 這篇文章真正要解決的問題RAG審計(jì)CAD是噱頭還是革命首先我們必須直面一個(gè)核心矛盾RAG擅長(zhǎng)處理文本而CAD文件的核心是精確的幾何數(shù)據(jù)。STEP或OBJ文件雖然以文本形式存儲(chǔ)STEP是純文本協(xié)議OBJ是文本格式但其內(nèi)容本質(zhì)上是幾何指令的序列。例如一個(gè)圓柱體在STEP中可能被表述為一連串復(fù)雜的拓?fù)浜蛶缀螌?shí)體定義ADVANCED_FACE,CYLINDRICAL_SURFACE,AXIS2_PLACEMENT_3D等。讓一個(gè)基于自然語言訓(xùn)練的LLM去直接“理解”這些符號(hào)背后的三維語義并判斷其正確性相當(dāng)于讓一位語言學(xué)家去審核機(jī)械圖紙的公差標(biāo)注——專業(yè)完全不對(duì)口。所以當(dāng)我們談?wù)摗坝肦AG審計(jì)CAD”時(shí)通常不是在談?wù)撟孉I檢查一個(gè)倒角半徑是否準(zhǔn)確或者兩個(gè)零件是否干涉?，F(xiàn)階段更可行、更具價(jià)值的路徑是利用RAG處理與CAD文件伴生的、海量的非幾何文本信息。這些信息包括設(shè)計(jì)元數(shù)據(jù)零件號(hào)、材料規(guī)格、版本號(hào)、設(shè)計(jì)者、日期。PMI產(chǎn)品制造信息尺寸、公差、表面粗糙度、焊接符號(hào)等標(biāo)注信息這些在STEP AP242等標(biāo)準(zhǔn)中可能以文本屬性附著。BOM物料清單信息裝配關(guān)系、零件數(shù)量。設(shè)計(jì)規(guī)范和檢查清單企業(yè)內(nèi)部的建模規(guī)范文檔如“所有孔必須使用孔特征而非拉伸切除生成”、“裝配體中不得有冗余約束”。歷史錯(cuò)誤庫過去項(xiàng)目中總結(jié)的典型設(shè)計(jì)錯(cuò)誤案例報(bào)告。RAG的真正用武之地是構(gòu)建一個(gè)關(guān)于“如何正確設(shè)計(jì)”的知識(shí)庫并讓工程師能夠以自然語言快速查詢。例如工程師可以問“我們公司對(duì)于鋁合金件的最小壁厚有什么規(guī)定”或者“上次項(xiàng)目A中導(dǎo)致數(shù)控加工失敗的模型錯(cuò)誤主要有哪些”RAG系統(tǒng)能從企業(yè)內(nèi)部文檔和歷史數(shù)據(jù)中快速找到精準(zhǔn)答案。因此本文要解決的核心問題是如何為一個(gè)工程團(tuán)隊(duì)構(gòu)建一個(gè)實(shí)用的、基于RAG的“設(shè)計(jì)知識(shí)輔助與審計(jì)線索生成”系統(tǒng)而非一個(gè)全自動(dòng)的幾何錯(cuò)誤偵探。我們將聚焦于利用RAG處理文本知識(shí)來間接提升CAD設(shè)計(jì)的質(zhì)量和審查效率。2. 基礎(chǔ)概念與核心原理RAG與CAD審計(jì)的碰撞在深入實(shí)操前我們需要統(tǒng)一幾個(gè)關(guān)鍵概念并理解它們?cè)诖藞?chǎng)景下的結(jié)合點(diǎn)。2.1 RAG檢索增強(qiáng)生成是什么你可以把RAG理解為一個(gè)“超級(jí)外腦”。它主要由兩部分組成檢索器擁有一個(gè)龐大的、結(jié)構(gòu)化的知識(shí)庫通常是向量數(shù)據(jù)庫。當(dāng)用戶提出問題時(shí)它不會(huì)讓大模型憑空想象而是先從這個(gè)知識(shí)庫里快速找到與問題最相關(guān)的幾段資料。生成器將找到的相關(guān)資料和用戶問題一起提交給大語言模型讓模型基于這些確鑿的依據(jù)來組織語言生成答案。這樣做的好處是顯而易見的答案更準(zhǔn)確、事實(shí)性更強(qiáng)、可追溯知道答案來自哪份文檔并且能突破大模型本身的知識(shí)截止日期限制。2.2 CAD文件審計(jì)的維度CAD審計(jì)是一個(gè)多層次的工作不能一概而論審計(jì)維度內(nèi)容描述傳統(tǒng)方法RAG可能的作用幾何完整性檢查模型是否有破面、自相交、非流形邊、微小縫隙等。依賴CAD內(nèi)核如ACIS, Parasolid的幾何修復(fù)算法或軟件自帶的檢查工具。幾乎無效。這是數(shù)學(xué)和幾何學(xué)問題非文本語義問題。數(shù)據(jù)合規(guī)性檢查文件格式版本、實(shí)體類型是否符合特定標(biāo)準(zhǔn)如STEP AP203 vs AP214。使用標(biāo)準(zhǔn)驗(yàn)證工具或自定義腳本解析文件頭。輔助作用?？蓪?biāo)準(zhǔn)文檔存入知識(shí)庫回答關(guān)于合規(guī)要求的問題。設(shè)計(jì)規(guī)范性是否符合公司建模標(biāo)準(zhǔn)命名、圖層、特征使用等。人工檢查或編寫復(fù)雜的腳本進(jìn)行規(guī)則匹配。核心價(jià)值。將公司規(guī)范文檔知識(shí)化支持自然語言查詢和案例檢索。制造可行性檢查拔模角度、刀具可達(dá)性、板金展開等。使用專業(yè)的CAE/CAM軟件進(jìn)行仿真分析。線索提供。可檢索歷史制造問題報(bào)告提示設(shè)計(jì)師注意類似風(fēng)險(xiǎn)。元數(shù)據(jù)完整性檢查必填的屬性如材料、重量、成本中心是否填寫。通過API讀取屬性并判斷。高效實(shí)現(xiàn)?？赏ㄟ^RAG增強(qiáng)的智能流程引導(dǎo)或檢查元數(shù)據(jù)填寫。從表格可以看出RAG的優(yōu)勢(shì)領(lǐng)域集中在“設(shè)計(jì)規(guī)范性”和“知識(shí)問答”上。它無法替代幾何內(nèi)核算法但可以極大地增強(qiáng)對(duì)文本規(guī)則和經(jīng)驗(yàn)的利用效率。2.3 為什么是“檢索增強(qiáng)”而不是“直接生成”如果直接讓大模型背誦“好的CAD設(shè)計(jì)應(yīng)該怎么做”它可能會(huì)生成一套看似合理但泛泛而談的原則。而RAG模式強(qiáng)制它援引你提供的具體知識(shí)源比如你上傳的《XX公司三維建模規(guī)范V2.1.pdf》第5頁的內(nèi)容。這使得答案具有權(quán)威性和可操作性減少了模型“幻覺”的風(fēng)險(xiǎn)。對(duì)于嚴(yán)謹(jǐn)?shù)墓こ填I(lǐng)域這一點(diǎn)至關(guān)重要。3. 環(huán)境準(zhǔn)備與前置條件接下來我們將動(dòng)手搭建一個(gè)Spring Boot應(yīng)用集成Milvus向量數(shù)據(jù)庫和LangChain4J實(shí)現(xiàn)一個(gè)針對(duì)設(shè)計(jì)規(guī)范文檔的智能問答系統(tǒng)。這是實(shí)現(xiàn)“RAG輔助CAD審計(jì)”的第一步也是最關(guān)鍵的基礎(chǔ)設(shè)施。環(huán)境要求操作系統(tǒng)Windows 10/11, macOS 或 Linux (本文以Windows為例命令通用)Java開發(fā)環(huán)境JDK 17 或更高版本構(gòu)建工具M(jìn)aven 3.6容器運(yùn)行時(shí)Docker Desktop (用于運(yùn)行Milvus數(shù)據(jù)庫)IDEIntelliJ IDEA, VS Code 或 Eclipse關(guān)鍵組件版本Spring Boot: 3.1.xMilvus: 2.3.x (通過Docker運(yùn)行)LangChain4J: 0.25.0 (一個(gè)優(yōu)秀的Java版LangChain實(shí)現(xiàn))嵌入模型我們使用本地運(yùn)行的all-MiniLM-L6-v2模型無需OpenAI API密鑰。4. 核心流程拆解構(gòu)建RAG系統(tǒng)的四步我們的目標(biāo)系統(tǒng)工作流程如下知識(shí)入庫將設(shè)計(jì)規(guī)范PDF、歷史錯(cuò)誤報(bào)告TXT等文檔切分成片段轉(zhuǎn)換為向量存入Milvus。問答檢索用戶用自然語言提問系統(tǒng)將問題轉(zhuǎn)換為向量在Milvus中查找最相似的文本片段。增強(qiáng)生成將找到的文本片段作為上下文連同用戶問題發(fā)送給大語言模型生成答案。返回結(jié)果將模型生成的、有依據(jù)的答案返回給用戶。下面我們分步實(shí)現(xiàn)。5. 完整示例與代碼實(shí)現(xiàn)5.1 第一步啟動(dòng)Milvus向量數(shù)據(jù)庫Milvus是專為向量搜索設(shè)計(jì)的數(shù)據(jù)庫。我們使用Docker Compose快速啟動(dòng)一個(gè)單機(jī)版。創(chuàng)建一個(gè)docker-compose.yml文件version: 3.5 services: etcd: container_name: milvus-etcd image: quay.io/coreos/etcd:v3.5.5 environment: - ETCD_AUTO_COMPACTION_MODErevision - ETCD_QUOTA_BACKEND_BYTES4294967296 - ETCD_SNAPSHOT_COUNT10000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd command: etcd -advertise-client-urlshttp://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd minio: container_name: milvus-minio image: minio/minio:RELEASE.2023-03-20T20-16-18Z environment: MINIO_ACCESS_KEY: minioadmin MINIO_SECRET_KEY: minioadmin volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data command: minio server /minio_data healthcheck: test: [CMD, curl, -f, http://localhost:9000/minio/health/live] interval: 30s timeout: 20s retries: 3 standalone: container_name: milvus-standalone image: milvusdb/milvus:v2.3.3 command: [milvus, run, standalone] environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus ports: - 19530:19530 - 9091:9091 depends_on: - etcd - minio networks: default: name: milvus在文件所在目錄打開終端執(zhí)行docker-compose up -d等待所有容器狀態(tài)變?yōu)閔ealthy。你可以通過docker ps命令檢查。Milvus服務(wù)將在localhost:19530端口可用。5.2 第二步創(chuàng)建Spring Boot項(xiàng)目并配置依賴使用Spring Initializr創(chuàng)建一個(gè)新項(xiàng)目或直接在現(xiàn)有項(xiàng)目的pom.xml中添加以下關(guān)鍵依賴!-- pom.xml -- dependencies !-- Spring Boot Web -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- LangChain4j 核心 -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.25.0/version /dependency !-- LangChain4j Spring Boot 集成 -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-spring-boot-starter/artifactId version0.25.0/version /dependency !-- 本地嵌入模型All-MiniLM-L6-v2 -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-embeddings-all-minilm-l6-v2/artifactId version0.25.0/version /dependency !-- Milvus 向量存儲(chǔ) -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-store-embedding-milvus/artifactId version0.25.0/version /dependency !-- 用于文檔解析PDF, TXT等 -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-document-parser-apache-pdfbox/artifactId version0.25.0/version /dependency !-- 開發(fā)工具 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId scoperuntime/scope optionaltrue/optional /dependency /dependencies5.3 第三步配置應(yīng)用連接和組件在application.yml中配置Milvus連接和本地模型# src/main/resources/application.yml spring: application: name: cad-rag-demo langchain4j: embedding: model: provider: all-minilm-l6-v2 # 使用本地嵌入模型 chat-model: provider: openai openai: api-key: dummy-key # 因?yàn)槲覀冇帽镜厍度肓奶炷Ｐ涂蓵翰慌渲没蚴褂肙llama本地模型 model-name: gpt-3.5-turbo # 如果使用遠(yuǎn)程API才需要真實(shí)key vector-store: milvus: host: localhost port: 19530 collection-name: cad_design_knowledge # 在Milvus中創(chuàng)建的集合名 dimension: 384 # all-MiniLM-L6-v2 模型的向量維度創(chuàng)建一個(gè)配置類用于初始化關(guān)鍵的Bean// src/main/java/com/example/cadrag/config/RagConfig.java package com.example.cadrag.config; import dev.langchain4j.data.segment.TextSegment; import dev.langchain4j.model.embedding.EmbeddingModel; import dev.langchain4j.store.embedding.EmbeddingStore; import dev.langchain4j.store.embedding.milvus.MilvusEmbeddingStore; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class RagConfig { Bean public EmbeddingStoreTextSegment embeddingStore() { // 創(chuàng)建Milvus存儲(chǔ)對(duì)應(yīng)配置文件中的集合 return MilvusEmbeddingStore.builder() .host(localhost) .port(19530) .collectionName(cad_design_knowledge) .dimension(384) // 必須與嵌入模型維度一致 .build(); } }5.4 第四步實(shí)現(xiàn)文檔入庫與問答服務(wù)這是核心業(yè)務(wù)邏輯。我們創(chuàng)建兩個(gè)服務(wù)一個(gè)用于將文檔如PDF切片、向量化并存入Milvus另一個(gè)用于處理用戶問答。1. 文檔入庫服務(wù)// src/main/java/com/example/cadrag/service/KnowledgeBaseService.java package com.example.cadrag.service; import dev.langchain4j.data.document.Document; import dev.langchain4j.data.document.DocumentParser; import dev.langchain4j.data.document.DocumentSplitter; import dev.langchain4j.data.document.parser.apache.pdfbox.ApachePdfBoxDocumentParser; import dev.langchain4j.data.document.splitter.DocumentSplitters; import dev.langchain4j.data.segment.TextSegment; import dev.langchain4j.model.embedding.EmbeddingModel; import dev.langchain4j.store.embedding.EmbeddingStore; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.springframework.core.io.Resource; import org.springframework.core.io.ResourceLoader; import org.springframework.stereotype.Service; import org.springframework.util.StreamUtils; import java.io.InputStream; import java.nio.charset.StandardCharsets; import java.util.List; Service Slf4j RequiredArgsConstructor public class KnowledgeBaseService { private final EmbeddingModel embeddingModel; private final EmbeddingStoreTextSegment embeddingStore; private final ResourceLoader resourceLoader; /** * 從類路徑加載PDF文件解析并存入向量庫 * param filePath 類路徑下的文件路徑如 classpath:docs/design_spec.pdf */ public void loadPdfToKnowledgeBase(String filePath) { try { Resource resource resourceLoader.getResource(filePath); if (!resource.exists()) { log.error(文件不存在: {}, filePath); return; } // 1. 解析PDF文檔 DocumentParser parser new ApachePdfBoxDocumentParser(); Document document; try (InputStream is resource.getInputStream()) { // 對(duì)于PDF解析 document parser.parse(is); } // 2. 分割文檔避免超出模型上下文長(zhǎng)度 DocumentSplitter splitter DocumentSplitters.recursive(300, 50); // 最大300字符重疊50字符 ListTextSegment segments splitter.split(document); log.info(文檔 {} 被分割成 {} 個(gè)片段, filePath, segments.size()); // 3. 為每個(gè)片段生成向量并存儲(chǔ) for (TextSegment segment : segments) { var embedding embeddingModel.embed(segment.text()).content(); embeddingStore.add(embedding, segment); } log.info(成功將文檔 {} 導(dǎo)入知識(shí)庫, filePath); } catch (Exception e) { log.error(導(dǎo)入文檔失敗: {}, filePath, e); throw new RuntimeException(文檔導(dǎo)入失敗, e); } } /** * 加載純文本文件如歷史錯(cuò)誤報(bào)告TXT */ public void loadTextFileToKnowledgeBase(String filePath) { try { Resource resource resourceLoader.getResource(filePath); String content StreamUtils.copyToString(resource.getInputStream(), StandardCharsets.UTF_8); Document document Document.from(content); DocumentSplitter splitter DocumentSplitters.recursive(300, 50); ListTextSegment segments splitter.split(document); for (TextSegment segment : segments) { var embedding embeddingModel.embed(segment.text()).content(); embeddingStore.add(embedding, segment); } log.info(成功將文本文件 {} 導(dǎo)入知識(shí)庫, filePath); } catch (Exception e) { log.error(導(dǎo)入文本文件失敗: {}, filePath, e); } } }2. 智能問答服務(wù)這里我們使用一個(gè)簡(jiǎn)單的、基于檢索內(nèi)容拼接的“生成”方式。在實(shí)際生產(chǎn)中你可以集成Ollama本地運(yùn)行LLaMA等模型或調(diào)用OpenAI/文心一言等API。// src/main/java/com/example/cadrag/service/RagQueryService.java package com.example.cadrag.service; import dev.langchain4j.model.embedding.EmbeddingModel; import dev.langchain4j.store.embedding.EmbeddingMatch; import dev.langchain4j.store.embedding.EmbeddingStore; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.springframework.stereotype.Service; import java.util.List; import java.util.stream.Collectors; Service Slf4j RequiredArgsConstructor public class RagQueryService { private final EmbeddingModel embeddingModel; private final EmbeddingStoredev.langchain4j.data.segment.TextSegment embeddingStore; /** * 核心RAG查詢方法 * param question 用戶自然語言問題 * return 基于知識(shí)庫生成的答案 */ public String query(String question) { // 1. 將用戶問題轉(zhuǎn)換為向量 var questionEmbedding embeddingModel.embed(question).content(); // 2. 在向量庫中檢索最相關(guān)的3個(gè)片段 int maxResults 3; ListEmbeddingMatchdev.langchain4j.data.segment.TextSegment relevantMatches embeddingStore.findRelevant(questionEmbedding, maxResults); if (relevantMatches.isEmpty()) { return 抱歉在現(xiàn)有知識(shí)庫中未找到相關(guān)信息。; } // 3. 構(gòu)建增強(qiáng)的上下文 String context relevantMatches.stream() .map(match - match.embedded().text()) .collect(Collectors.joining(\n\n---\n\n)); // 4. 構(gòu)建Prompt這里簡(jiǎn)化處理實(shí)際可使用更復(fù)雜的模板或調(diào)用LLM String answer generateAnswerBasedOnContext(question, context, relevantMatches); return answer; } private String generateAnswerBasedOnContext(String question, String context, ListEmbeddingMatchdev.langchain4j.data.segment.TextSegment matches) { // 這是一個(gè)簡(jiǎn)化的生成邏輯。在實(shí)際應(yīng)用中這里應(yīng)該調(diào)用一個(gè)LLM。 // 例如String prompt String.format(基于以下上下文回答問題。如果上下文不包含答案請(qǐng)說不知道。\n\n上下文%s\n\n問題%s, context, question); // 然后調(diào)用 chatModel.generate(prompt); StringBuilder sb new StringBuilder(); sb.append(**問題**).append(question).append(\n\n); sb.append(**根據(jù)知識(shí)庫相關(guān)信息如下**\n\n); sb.append(context).append(\n\n); sb.append(**參考來源摘要**\n); for (int i 0; i matches.size(); i) { // 這里可以展示相似度分?jǐn)?shù) sb.append(i 1).append(. ).append(matches.get(i).embedded().text().substring(0, Math.min(100, matches.get(i).embedded().text().length()))).append(...\n); } sb.append(\n**注此為檢索結(jié)果展示。完整答案生成需集成大語言模型。**); return sb.toString(); } }3. 創(chuàng)建REST控制器提供API// src/main/java/com/example/cadrag/controller/RagController.java package com.example.cadrag.controller; import com.example.cadrag.service.KnowledgeBaseService; import com.example.cadrag.service.RagQueryService; import lombok.RequiredArgsConstructor; import org.springframework.web.bind.annotation.*; RestController RequestMapping(/api/rag) RequiredArgsConstructor public class RagController { private final KnowledgeBaseService knowledgeBaseService; private final RagQueryService ragQueryService; PostMapping(/load-pdf) public String loadPdf(RequestParam String filePath) { knowledgeBaseService.loadPdfToKnowledgeBase(filePath); return PDF文檔導(dǎo)入指令已接收請(qǐng)查看后臺(tái)日志。; } PostMapping(/load-txt) public String loadTxt(RequestParam String filePath) { knowledgeBaseService.loadTextFileToKnowledgeBase(filePath); return 文本文件導(dǎo)入指令已接收請(qǐng)查看后臺(tái)日志。; } GetMapping(/ask) public String askQuestion(RequestParam String question) { return ragQueryService.query(question); } }5.5 第五步準(zhǔn)備知識(shí)庫文檔并運(yùn)行測(cè)試準(zhǔn)備文檔在src/main/resources下創(chuàng)建docs文件夾放入你的知識(shí)文檔。例如design_standard.pdf(公司CAD設(shè)計(jì)規(guī)范)common_errors.txt(歷史常見錯(cuò)誤列表每行一個(gè)錯(cuò)誤描述)common_errors.txt示例內(nèi)容錯(cuò)誤案例ID-2023-001: 鈑金件折彎半徑小于材料最小彎曲半徑導(dǎo)致開裂。規(guī)范要求SPCC鋼板厚度t2mm時(shí)內(nèi)半徑R應(yīng)≥1.5t。 錯(cuò)誤案例ID-2023-002: 裝配體中存在冗余的“重合”配合導(dǎo)致過定義和軟件解算緩慢。 錯(cuò)誤案例ID-2023-003: 螺紋孔標(biāo)注不完整缺少螺紋深度和鉆孔深度信息。 規(guī)范條目-5.2: 所有零件文件必須以“P-”開頭裝配體文件以“A-”開頭。 規(guī)范條目-7.1: 三維模型中必須填寫“Material”、“Weight”、“CostCenter”屬性。編寫一個(gè)初始化類在應(yīng)用啟動(dòng)后自動(dòng)加載知識(shí)庫// src/main/java/com/example/cadrag/runner/DataInitRunner.java package com.example.cadrag.runner; import com.example.cadrag.service.KnowledgeBaseService; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.springframework.boot.CommandLineRunner; import org.springframework.stereotype.Component; Component Slf4j RequiredArgsConstructor public class DataInitRunner implements CommandLineRunner { private final KnowledgeBaseService knowledgeBaseService; Override public void run(String... args) { log.info(開始初始化RAG知識(shí)庫...); try { // 加載設(shè)計(jì)規(guī)范PDF knowledgeBaseService.loadPdfToKnowledgeBase(classpath:docs/design_standard.pdf); // 加載常見錯(cuò)誤TXT knowledgeBaseService.loadTextFileToKnowledgeBase(classpath:docs/common_errors.txt); log.info(RAG知識(shí)庫初始化完成。); } catch (Exception e) { log.error(初始化知識(shí)庫失敗請(qǐng)檢查文檔路徑和Milvus連接。, e); } } }啟動(dòng)應(yīng)用并測(cè)試 確保Milvus Docker容器正在運(yùn)行。 啟動(dòng)你的Spring Boot應(yīng)用。 使用瀏覽器或Postman調(diào)用API初始化知識(shí)庫應(yīng)用啟動(dòng)時(shí)會(huì)自動(dòng)運(yùn)行DataInitRunner。進(jìn)行問答GET http://localhost:8080/api/rag/ask?question鈑金件折彎半徑有什么規(guī)定 GET http://localhost:8080/api/rag/ask?question文件命名規(guī)范是什么 GET http://localhost:8080/api/rag/ask?question裝配體過定義是什么原因6. 運(yùn)行結(jié)果與效果驗(yàn)證調(diào)用GET http://localhost:8080/api/rag/ask?question鈑金件折彎半徑有什么規(guī)定后預(yù)期會(huì)得到如下格式的響應(yīng)**問題**鈑金件折彎半徑有什么規(guī)定 **根據(jù)知識(shí)庫相關(guān)信息如下** 錯(cuò)誤案例ID-2023-001: 鈑金件折彎半徑小于材料最小彎曲半徑導(dǎo)致開裂。規(guī)范要求SPCC鋼板厚度t2mm時(shí)內(nèi)半徑R應(yīng)≥1.5t。 --- **參考來源摘要** 1. 錯(cuò)誤案例ID-2023-001: 鈑金件折彎半徑小于材料最小彎曲半徑導(dǎo)致開裂。規(guī)范要求SPCC鋼板厚度t2mm時(shí)內(nèi)半徑R應(yīng)≥1.5t。... **注此為檢索結(jié)果展示。完整答案生成需集成大語言模型。**如何驗(yàn)證成功檢查日志應(yīng)用啟動(dòng)日志應(yīng)顯示“開始初始化RAG知識(shí)庫...”和“成功將文本文件...導(dǎo)入知識(shí)庫”。檢查Milvus集合可以使用Milvus的Python SDK或Attu圖形化客戶端連接localhost:19530查看cad_design_knowledge集合中是否有數(shù)據(jù)。問答相關(guān)性提出的問題返回的片段應(yīng)直接包含問題關(guān)鍵詞如“折彎半徑”、“命名規(guī)范”。這證明檢索功能工作正常。當(dāng)前系統(tǒng)的局限性我們目前只實(shí)現(xiàn)了“檢索”部分并用簡(jiǎn)單拼接展示了結(jié)果。要獲得流暢、歸納性的答案需要將檢索到的上下文發(fā)送給真正的LLM大語言模型進(jìn)行“生成”。7. 常見問題與排查思路問題現(xiàn)象可能原因排查方式解決方案應(yīng)用啟動(dòng)失敗連接Milvus超時(shí)1. Milvus Docker容器未啟動(dòng)。2. 防火墻阻止了19530端口。3.application.yml配置錯(cuò)誤。1. 運(yùn)行docker ps檢查容器狀態(tài)。2. 使用telnet localhost 19530測(cè)試端口。3. 檢查配置文件中的host和port。1. 執(zhí)行docker-compose up -d。2. 關(guān)閉防火墻或放行端口。3. 修正配置并重啟應(yīng)用。文檔導(dǎo)入成功但問答返回“未找到相關(guān)信息”1. 問題向量與文檔向量相似度低。2. 文檔分割太碎語義不完整。3. 嵌入模型不匹配維度不對(duì)。1. 檢查問題是否包含文檔中的關(guān)鍵詞。2. 調(diào)整DocumentSplitters的參數(shù)增大片段大小。3. 確認(rèn)Milvus集合的維度與模型維度384一致。1. 嘗試用更接近文檔表述的方式提問。2. 將recursive(300,50)改為recursive(500, 100)。3. 刪除Milvus集合重新創(chuàng)建并導(dǎo)入。導(dǎo)入PDF時(shí)解析亂碼或失敗1. PDF是掃描件圖片非文本。2. PDF加密或有特殊權(quán)限。3. 字體缺失。1. 用文本編輯器打開PDF看能否復(fù)制文字。2. 檢查PDF屬性。3. 查看應(yīng)用日志中的具體異常信息。1. 對(duì)掃描件PDF使用OCR工具如Tesseract先轉(zhuǎn)換為文本。2. 解除PDF保護(hù)或使用可解析的版本。3. 考慮使用其他文檔解析庫。問答響應(yīng)慢1. 首次運(yùn)行嵌入模型需下載或加載。2. Milvus集合未建立索引。3. 檢索的片段數(shù)量maxResults設(shè)置過大。1. 觀察日志看是否在下載模型文件。2. 在Milvus中為集合創(chuàng)建索引如IVF_FLAT。3. 檢查代碼中findRelevant的參數(shù)。1. 首次加載耐心等待模型文件會(huì)緩存。2. 在生產(chǎn)環(huán)境中務(wù)必為向量字段創(chuàng)建合適的索引。3. 根據(jù)需求合理設(shè)置maxResults通常3-5個(gè)足夠。如何集成真正的LLM生成答案當(dāng)前示例僅做了檢索和拼接。查看LangChain4J文檔中關(guān)于ChatLanguageModel的集成。1.本地部署集成Ollama使用OllamaChatModel。2.云端API集成OpenAI、Azure OpenAI或國(guó)內(nèi)大模型API配置相應(yīng)的ChatModelBean。8. 最佳實(shí)踐與工程建議將RAG用于CAD知識(shí)管理要避免淪為玩具項(xiàng)目需遵循以下工程實(shí)踐知識(shí)庫質(zhì)量?jī)?yōu)先RAG的輸出質(zhì)量極度依賴輸入知識(shí)。確保你的設(shè)計(jì)規(guī)范、錯(cuò)誤案例等文檔是結(jié)構(gòu)清晰、表述準(zhǔn)確、無二義性的。雜亂無章的知識(shí)輸入只會(huì)得到混亂的輸出。文檔預(yù)處理是關(guān)鍵分塊策略對(duì)于CAD規(guī)范按章節(jié)、條款分塊比固定字符長(zhǎng)度分塊更有效?？梢岳梦臋n的標(biāo)題結(jié)構(gòu)Markdown的#PDF的書簽。元數(shù)據(jù)附著為每個(gè)文本塊附加元數(shù)據(jù)如“文檔名稱”、“章節(jié)號(hào)”、“適用軟件SolidWorks/AutoCAD”。在檢索時(shí)可以按元數(shù)據(jù)過濾提高精度。選擇合適的嵌入模型all-MiniLM-L6-v2是一個(gè)不錯(cuò)的通用起點(diǎn)。但對(duì)于高度專業(yè)的中文工程術(shù)語可以探索在專業(yè)語料上微調(diào)過的模型或使用針對(duì)中文優(yōu)化的模型如BGE系列、M3E。實(shí)現(xiàn)真正的“生成”環(huán)節(jié)集成LLM后設(shè)計(jì)好的Prompt模板至關(guān)重要。例如你是一名嚴(yán)謹(jǐn)?shù)臋C(jī)械設(shè)計(jì)審核專家。請(qǐng)嚴(yán)格根據(jù)以下上下文回答問題。如果上下文沒有提供足夠信息請(qǐng)明確回答“根據(jù)現(xiàn)有知識(shí)無法確定”。 上下文來自公司內(nèi)部設(shè)計(jì)規(guī)范和歷史審核記錄請(qǐng)確保答案的準(zhǔn)確性和可追溯性。 上下文 {context} 問題{question} 請(qǐng)?zhí)峁┖?jiǎn)潔、專業(yè)的答案并指出依據(jù)來源于上下文的哪一部分。建立更新與評(píng)估機(jī)制知識(shí)庫版本化當(dāng)設(shè)計(jì)規(guī)范更新時(shí)應(yīng)有流程觸發(fā)知識(shí)庫的更新全量或增量。效果評(píng)估構(gòu)建一個(gè)測(cè)試集QA對(duì)定期運(yùn)行評(píng)估RAG系統(tǒng)的準(zhǔn)確率、召回率。關(guān)注“幻覺”情況。明確系統(tǒng)邊界在用戶界面中清晰說明本系統(tǒng)基于文本知識(shí)庫提供設(shè)計(jì)規(guī)范和歷史案例查詢不能替代幾何檢查軟件和工程師的專業(yè)判斷。它是一個(gè)“輔助”和“線索提供”工具。安全與權(quán)限設(shè)計(jì)規(guī)范可能包含敏感信息。確保RAG系統(tǒng)的API有適當(dāng)?shù)恼J(rèn)證和授權(quán)避免知識(shí)庫被未經(jīng)授權(quán)訪問。9. 總結(jié)與后續(xù)學(xué)習(xí)方向回到我們最初的問題使用RAG來審計(jì)CAD文件這是正確的方向嗎通過本文的構(gòu)建與實(shí)踐我們可以給出一個(gè)更清晰的判斷將RAG直接用于審計(jì)CAD文件的幾何數(shù)據(jù)目前是一條艱難且不成熟的技術(shù)路徑。但是將RAG用于審計(jì)和管理與CAD設(shè)計(jì)相關(guān)的文本知識(shí)、規(guī)范和流程則是一個(gè)立即可行且價(jià)值顯著的方向。你構(gòu)建的這個(gè)系統(tǒng)不是一個(gè)自動(dòng)的“幾何錯(cuò)誤偵探”而是一個(gè)“設(shè)計(jì)知識(shí)中樞”。它能夠秒級(jí)響應(yīng)讓新員工快速查詢公司設(shè)計(jì)規(guī)范而不必翻閱數(shù)百頁的PDF。經(jīng)驗(yàn)傳承將散落在郵件、報(bào)告中的歷史錯(cuò)誤案例結(jié)構(gòu)化供團(tuán)隊(duì)檢索借鑒。審查提效在人工審查模型前先通過問答系統(tǒng)核對(duì)關(guān)鍵的設(shè)計(jì)規(guī)則和元數(shù)據(jù)要求。后續(xù)你可以深入的方向集成本地LLM使用Ollama在本地部署Llama 3、Qwen等開源模型替換掉示例中的簡(jiǎn)單拼接實(shí)現(xiàn)真正的智能生成保證數(shù)據(jù)隱私。多模態(tài)RAG探索這是前沿方向。研究如何解析CAD圖紙中的PMI標(biāo)注文本、BOM表甚至結(jié)合視覺模型對(duì)圖紙截圖進(jìn)行理解構(gòu)建更豐富的多模態(tài)知識(shí)庫。與PLM/PDM系統(tǒng)集成將RAG系統(tǒng)作為插件集成到Teamcenter、Windchill等產(chǎn)品生命周期管理系統(tǒng)中在設(shè)計(jì)流程的關(guān)鍵節(jié)點(diǎn)自動(dòng)觸發(fā)知識(shí)查詢和建議。實(shí)現(xiàn)簡(jiǎn)單規(guī)則檢查結(jié)合RAG檢索出的規(guī)范編寫腳本程序去自動(dòng)檢查CAD文件的屬性如通過SolidWorks API檢查零件屬性是否完整。將“知識(shí)查詢”升級(jí)為“自動(dòng)規(guī)則檢查知識(shí)解釋”。技術(shù)的價(jià)值不在于追逐最熱的概念而在于解決最痛的問題。對(duì)于CAD審計(jì)這個(gè)領(lǐng)域RAG或許不是那把“萬能鑰匙”但它確實(shí)為我們打開了一扇新的門讓我們能夠以更智能的方式管理和運(yùn)用那些曾經(jīng)被鎖在文檔里的寶貴知識(shí)。從構(gòu)建一個(gè)本文這樣的文本知識(shí)問答系統(tǒng)開始你已經(jīng)在通往更智能設(shè)計(jì)輔助的道路上邁出了扎實(shí)的一步。