처음 접하는 인데이터베이스 AI: 벡터 검색, RAG부터 AI 에이전트까지

본 기사의 내용은 2026/10/21의 Oracle AI Jam Session #41 처음 접하는 인데이터베이스 AI: 벡터 검색, RAG부터 AI 에이전트까지에서 소개된 내용을 정리한 것입니다.

생성형 AI를 업무에 활용하려면 사내 지식이나 업무 데이터를 안전하고 적절하게 검색하여 답변이나 액션으로 연결하는 메커니즘이 필요합니다. 본 기사에서는 데이터베이스 내에서 벡터 검색을 통한 의미론적 검색(Semantic Search), 임베딩 모델을 이용한 벡터 생성, 검색 증강 생성(RAG), 자연어를 이용한 데이터 질의, AI 에이전트를 구현하는 '인데이터베이스 AI (In-Database AI)'의 개념을 초심자도 이해할 수 있도록 전체적인 개요와 코드 예시 및 데모를 통해 소개합니다. 본 내용은 초심자뿐만 아니라 데이터베이스 전문가로서의 스킬이나 경력을 활용하여 AI 활용에 대한 접근을 고려하는 베테랑 엔지니어분들께도 도움이 될 수 있도록 목표하고 있습니다.

소개되는 코드나 환경 구축 절차는 GitHub 리포지토리에 공개되어 있습니다. 꼭 실제로 구동해 보시고 경험해 보시길 바랍니다.

"보수 등록 번호 DEV001의 랙 서버에서 관리 화면이 열리지 않습니다. 가장 먼저 무엇을 확인해야 할까요? 현장 보수를 요청할 수 있나요?"

이러한 문의에 답하려면 제품 매뉴얼뿐만 아니라 해당 서버의 보수 계약도 필요합니다.

일반적인 대처법을 아는 AI라도 사내 최신 매뉴얼이나 고객의 계약 정보를 참조하지 않으면 이 문의에 대한 답변을 내놓을 수 없습니다. 즉, AI를 본격적으로 업무 이용하기 위해서는 AI가 업무 데이터를 활용할 수 있도록 하는 것이 필요합니다.

한편, AI, 특히 사람을 대신하여 자율적으로 업무를 진행해 주는 AI 에이전트에게 중요한 업무 데이터에 대한 접근 권한을 허용하는 것에는 위험이 따릅니다.

그래서 업무 데이터를 관리하고 있는 곳에서 AI가 필요한 검색이나 처리를 실행한다는 개념이 등장하게 됩니다.

본 기사에서는 **"데이터가 있는 곳으로 AI를 가져간다"**는 관점을 서버 장비 제조사의 보수 문의 창구 고객 대응을 예로 들어 살펴보겠습니다. 의미적 유사성에 기반하여 문서를 찾는 것부터 시작해 근거가 제시된 답변, 계약 조회, 여러 처리를 사용하는 AI 에이전트로 나아갑니다.

본 기사의 독자 예상 대상은 SELECT, WHERE, JOIN 등 데이터베이스의 기초를 알고 있는 분입니다. AI에 대한 사전 지식은 필요하지 않습니다. 구현 예시에는 Autonomous AI Database 26ai를 사용하지만, 검색·생성·업무 처리의 역할 분담은 다른 구성에도 응용할 수 있을 것이라 생각합니다.

본 기사는 다음과 같은 구성을 가지고 있습니다.

장	내용	데모
제1장	문서의 의미 검색과, 업무 데이터의 질의를 결합하기	—
...
본문 중 실행용 코드는 동작 확인이 완료되었습니다. 손에서 재현하려면 먼저 말미의 Appendix에서 사용자 생성부터 환경을 준비해 주세요. 코드와 데이터 생성기는 여기입니다.

본 기사에서는 제조사의 보수 담당자가 랙 서버 문의에 대응하는 상황을 가정합니다.

고객은 보수 등록 번호 DEV001 서버에 대해 "관리 화면이 열리지 않습니다. 확인 절차를 알고 싶습니다. 현장 보수도 요청할 수 있나요?"라고 문의해 왔습니다.

등장 기업, 기종, 보수 절차는 모두 본 기사용 가상의 것입니다.

**"무엇을 확인해야 할까"**는 증상과 관련된 매뉴얼이나 보수 절차를 찾는 질문입니다. -
한편,

**"현장 보수를 요청할 수 있나"**는 해당 서버의 계약 상태·유효 기간·서비스 범위를 확인하는 질문입니다. 같은 제품 기종이라도 계약에 따라 대응 가능한 내용은 다르다고 가정합니다.

상단은, 매뉴얼이나 보수 절차서와 같은
**비정형 데이터의 의미 검색(Semantic Search)**이 적합한 질문 - 하단은, 계약표(테이블)와 같은
관계형 데이터베이스의 검색을 필요로 하는 질문

앞으로는 먼저 의미 검색, 다음으로 근거가 제시된 문서 생성, 계약 정보에 대한 자연어 질의, 마지막으로 이들을 사용하는 에이전트 순서로 살펴보겠습니다.

"관리 화면이 열리지 않는다"나 "관리 화면이 멈췄다", "관리 화면이 응답하지 않는다"는 같은 문자열은 아니지만 관련 증상입니다.

"관리 화면이 열리지 않는다"라는 증상 호소에 대해, "관리 화면이 멈췄다"나 "관리 화면이 응답하지 않는다"라는 증상에 대해 쓰여진 문서를 찾아야 하지만, 키워드 검색으로는 이러한 문서를 찾지 못할 가능성이 있습니다.

따라서 의미 검색(Semantic Search)이 필요합니다. 즉, 의미적으로 가까운 문서를 찾는 검색입니다. 이러한 검색을 구현하는 기술에 벡터 검색(Vector Search)이 있습니다.

임베딩 모델(Embedding Model)이라는 기계 학습 모델로, 텍스트나 이미지의 특징을 반영한 벡터(수치 배열)를 생성합니다.
벡터 간 거리가 가까운 것끼리는 원본 데이터의 특징이 비슷하고, 거리가 먼 것은 비슷하지 않다는 것을 의미합니다.
제품 매뉴얼 등의 문서를 벡터로 변환하여 데이터베이스에 저장합니다.
'관리 화면이 열리지 않는데, 어떻게 해야 하나요?'와 같은 질문문도 동일한 임베딩 모델로 벡터화합니다. - 데이터베이스의 문서/벡터 중에서 질문문의 벡터와 거리가 가까운 것을 찾습니다.

벡터 간 거리 지표(Distance Metric)

거리 지표에는 코사인(Cosine)이나 유클리드 거리(Euclidean Distance) 등 다양한 것이 있습니다.
거리 지표는 임베딩 모델의 학습 방법이나 공개된 권장 설정에 맞춰 선택합니다.
일반적으로 사용되는 임베딩 모델에서는 코사인이 사용되는 경우가 많은 것 같습니다.

청킹(Chunking)

텍스트를 임베딩 모델로 벡터화할 때는, 하나의 벡터로 변환할 수 있는 텍스트의 길이에 제한이 있습니다.
문서를 등의 이 제한 내에 포함하도록 분할하는 것을 **청킹(Chunking)**이라고 부르며, 세분화된 텍스트 조각을 **청크(Chunk)**라고 합니다. - 본 기사에서는 간략화를 위해 짧은 문서를 준비하여, 1문서 = 1청크로 처리했습니다.

증상이 비슷하더라도, 다른 기종의 절차나 다른 고객 전용 문서가 안내되어서는 안 됩니다. 의미적 근접성 외에도 '누구의 문의인지', '어떤 기종인지', '공개 여부'와 같은 조건이 필요합니다. 여기서 고객(Customer), 서버(Server), 계약(Contract) 등의 관계형 데이터(Relational Data)가 유용하게 사용됩니다.

일반적인 검색 애플리케이션에서는, 검색 화면에 '기종', '지역', '공개 구분' 등의 필터링 항목이 준비되어 있습니다. 이러한 필터링의 기준을 **패싯(Facet)**이라고 부릅니다. 값별 건수를 표시하고, 선택한 속성으로 후보를 좁히는 사용 방식이 전형적입니다.

벡터 DB에서도 문서에 붙인 메타데이터(Metadata)를 사용하여 필터링할 수 있습니다. 예를 들어 Qdrant는 payload라는 추가 정보 필터와, 속성 값별 건수를 반환하는 faceting을 제공합니다. [Qdrant의 payload와 faceting]

제품 관련 단순한 사양 질문이라면, 문서 메타데이터에 대한 model=AX-100과 같은 필터 조건만으로 충분합니다. 한편, 이번 시나리오와 같은 '처리 중인 티켓의 고객이 계약한 서버 기종', '현재 공개되어 있고, 그 고객이 열람할 수 있는 문서'와 같은 조건은 계약이나 권한 변경을 따라가야 합니다.

이러한 업무 데이터는 관계형 데이터베이스(RDB)에서 관리되는 경우가 많습니다. 벡터 DB의 메타데이터 필터링만으로는 이러한 조건을 판단하기 위해, 판단에 필요한 정보를 메타데이터나 태그로 복제하고 계약이나 권한 변경에 맞춰 업데이트해야 합니다.

업무 테이블과 벡터가 같은 관계형 데이터베이스에 있다면, 검색용으로 복제된 메타데이터나 태그의 업데이트를 기다릴 필요 없이, 원본 테이블을 JOIN이나 EXISTS로 참조하여 조건을 표현할 수 있습니다. [조건/운영상의 과제 | RDB 내 벡터 검색에서 사용 가능한 메커니즘]

이러한 장점은 Oracle만의 것은 아닙니다. PostgreSQL의 pgvector도 JOIN이나 트랜잭션과 결합될 수 있습니다. MySQL에도 SQL로 임베딩 생성 및 유사 검색을 제공하는 MySQL HeatWave가 있습니다. [pgvector, MySQL HeatWave의 벡터 생성 및 검색]

Oracle에서는 관계형 테이블과 벡터 외에도 JSON이나 전문 검색(Full-text Search), 지리 공간 정보(Geospatial Information), 그래프 등도 같은 데이터 기반에서 처리할 수 있습니다. 업무 데이터 종류별로 검색용 별도의 시스템을 늘리기 전에, 기존 DB의 데이터와 SQL을 어디까지 활용할 수 있을지 고려해 볼 수 있습니다.

AI 애플리케이션을 만들 때, 업무 DB에서 문서나 계약을 가져와 다른 검색 기반으로 복제하는 구성은 자주 사용됩니다.

이 구성에는, 검색 처리를 독립적으로 확장할 수 있다는 장점이 있습니다. 한편, 계약 갱신 시점을 언제 반영할지, 삭제된 문서를 어떻게 제거할지, 고객별 열람 범위를 어떻게 동기화할지 등 업무도 발생합니다.

예를 들어, 업무 DB에서 계약이 해지되었는데, 벡터 DB 등 AI로 활용하기 위해 복제된 데이터가 어제의 상태라면, 검색 자체는 정확하더라도 잘못된 안내로 이어질 수 있습니다. 고객이 계약을 해지하거나, 유지보수 창구 담당자가 이동하는 경우처럼 문서의 열람 권한이 변경된 경우도 마찬가지입니다. 필요한 것은 단순히 유사한 문서를 찾는 능력만이 아닙니다. 어떤 시점의 정보를, 누구의 권한으로 사용하고 있는지를 제어할 수 있는 구성입니다.

Oracle이 제시하는 '데이터가 있는 곳으로 AI를 가져간다'는 방향성은, 업무 데이터 근처에서 의미 검색이나 추론을 실행하고 기존의 데이터 관리와 결합하는 것입니다. Oracle AI Vector Search에서는 벡터를 업무 테이블과 같은 DB에 저장하여 SQL로부터 통합적으로 처리할 수 있습니다. (Oracle AI Vector Search)

다만, 같은 DB에 놓는다고 해서 신선도나 권한이 자동으로 정확해지는 것은 아닙니다. 본문을 업데이트했다면 대응하는 벡터도 업데이트해야 합니다. 검색에 사용할 뷰나 실행 사용자 권한도 설계해야 합니다. DB 경험자가 수행했던 데이터 정합성·권한·운용의 설계가 여기서도 필요합니다.

지난 장에서는 문서의 벡터와 업무 데이터를 같은 DB에서 다루는 의의를 살펴보았습니다. 다음으로는 그 벡터를 만드는 임베딩 모델을 배치할 위치에 대해 생각해 보겠습니다.

벡터 검색을 구성할 때 일반적인 구성 중 하나는 외부 클라우드 서비스에 임베딩 생성을 요청하는 방식입니다. 애플리케이션에서 문서나 질문을 API로 보내고, 반환된 벡터를 DB에 저장하거나 검색에 사용합니다. 예를 들어 OCI Generative AI도 문장을 벡터로 변환하는 API를 제공합니다. (외부 서비스에서의 임베딩 생성)

Oracle AI Database에서는 임베딩 모델을 데이터베이스에 가져와서(import) 데이터베이스 내에서 벡터화하는 구성도 가능합니다.

여기서 조금 앞서 나가자면, 벡터 검색 결과를 바탕으로 자연어로 답변을 생성하는 RAG(검색 증강 생성)에서의 임베딩 모델과 답변 생성용 LLM에 전달할 데이터 범위를 비교해 보겠습니다.

벡터 데이터베이스에 데이터를 투입할 때는 벡터화 대상에 선정한 문서의 모든 청크 즉, 문서 전체를 임베딩 모델에 순차적으로 입력합니다. 반면, RAG 답변 생성 시에는 검색으로 얻은 소수의 청크를 질문과 함께 LLM에 전달합니다. (RAG 준비 및 질문 시 흐름)

상황	임베딩 모델에 전달할 데이터	LLM에 전달할 데이터
최초 임베딩 생성	검색 대상 문서의 전체 청크	없음
...
즉, 외부 임베딩 API를 사용하면 검색 대상 문서를 모두 외부에 보내게 됩니다.

임베딩 모델을 데이터 근처에 배치하려는 동기는 여기에 있습니다. 문서 전체의 이동은 줄이면서도, 외부 LLM에는 답변에 필요한 부분만 골라 전달할 수 있기 때문입니다.

데이터베이스에 따라 대응하는 임베딩 모델을 내부로 가져와 SQL로부터 실행할 수 있는 경우가 있습니다.

Oracle AI Database에서는 대응하는 ONNX 형식의 모델을 DB 내 런타임에서 실행합니다. ONNX는 기계 학습 모델의 표준 포맷입니다. (DB 내에서의 임베딩 생성)

관점	외부 임베딩 서비스 이용	대응 모델을 DB 내부로 가져오기
데이터 이동	문서·질문을 외부 API로 전송	임베딩을 위한 외부 API 전송 생략 가능
...
DB 내 실행의 장점은 데이터 이동을 줄이고, SQL로부터 임베딩과 검색을 처리할 수 있다는 것입니다. 대신, 큰 모델의 메모리 소비나 동시 실행 횟수도 DB 운영 관점에서 고려해야 합니다.

또한, 일반적으로 클라우드 서비스의 임베딩 모델은 GPU 위에서 구동하지만, 데이터베이스에 가져오는 경우에는 CPU에서 구동하게 되므로 단순히 'DB 내라서 네트워크 지연이 최소로 빠르다' 또는 '외부 API라서 네트워크 지연이 있어서 느리다'라고 할 수 없습니다.

속도가 문제가 되는 경우라면, 데이터베이스 근처에서 작동하는 추론 환경으로 오프로드(offload)하는 것도 고려할 수 있습니다. Oracle AI Database의 경우에는 Private AI Services Container라는 메커니즘도 제공합니다.

답변 생성 시에도 외부 LLM에 데이터를 보내고 싶지 않다면, LLM을 온프레미스에서 셀프 호스팅하거나, 클라우드의 전용 클래스터 서비스 이용 또는 자체 테넌트(계정) 내에서 셀프 호스팅하는 것도 고려할 수 있습니다.

이번에는 인데이터베이스 AI의 실례로, OSS 기반 임베딩 모델 multilingual-e5-large를 DB 내에 가져옵니다. 문서와 질문 모두 이 임베딩 모델로 벡터화합니다. 문장 답변이나 SQL을 생성하는 LLM은 별도의 모델입니다. 여기서는 외부 OCI Enterprise AI(Generative AI)의 LLM을 이용합니다. 임베딩 모델은 DB 내, 생성용 LLM은 DB 외 라는 배치를 처리 흐름에 따라 확인해 봅시다.

처리 배치를 그림으로 보여드립니다. 왼쪽에서는 문서 벡터화, 의미 검색, 계약 조회 등을 DB 내에서 수행합니다. 오른쪽의 생성용 LLM은 DB 밖에 있습니다. 선에 적힌 정보가 외부로 전달되는 정보입니다.

처리	이번 실행 장소	사용하는 정보
문서・질문 임베딩	DB 내 multilingual-e5-large	문서 본문・질문
...
생성용 LLM은 OCI Enterprise AI(Generative AI) 서비스의 xai.grok-4.3을 시카고 리전에서 이용하고, DB는 도쿄의 Autonomous AI Database 26ai입니다. DB에서 API를 호출할 경우에도 전달되는 정보는 DB 외부로 나갑니다. '모든 AI 처리가 DB 내에서 완결된다'는 구성은 아닙니다. 무엇을 DB 내에서 처리하고, 무엇을 외부에 보낼지 선택하는 것이 설계의 요점입니다.

여기서는 임베딩 모델 가져오기와 DB 내에서 벡터를 생성 및 검색하는 작은 데모를 보겠습니다.

준비 과정은 대응하는 ONNX 형식으로 변환한 모델을 Object Storage에 두고, DB에서 DBMS_VECTOR.LOAD_ONNX_MODEL_CLOUD라는 PL/SQL 프로시저를 호출하는 것입니다. 이번 모델은 가중치(weight)가 외부 파일로 분리되어 있기 때문에, .onnx뿐만 아니라 첨부된 .json과 .data도 같은 배치 장소에 둡니다. DB에서 Object Storage로의 인증에는 리소스 프린시펄(Resource Principal)을 사용합니다.

사용자・권한・리소스 프린시펄 설정을 완료한 후, 다음 SQL을 실행하면 임베딩 모델을 데이터베이스에 가져올 수 있습니다. URI는 모델 배치 장소로 바꿔주세요.

BEGIN
DBMS_VECTOR.LOAD_ONNX_MODEL_CLOUD(
model_name => 'MULTILINGUAL_E5_LARGE',
...

이 임포트 처리가 완료된 후의 벡터 검색에서는, VECTOR_EMBEDDING라는 SQL 함수로 지금 등록한 임베딩 모델을 호출하여 DB 내에서 벡터화를 실행합니다.

참고로, 큰 모델의 경우 가중치 메모리 공유도 설정합니다. 변환과 배치 상세는 multilingual-e5-large의 임포트 절차, API 인수는 LOAD_ONNX_MODEL_CLOUD를 참조해 주세요. 이 데모에 사용할 준비 스크립트는 sql/setup/10_load_embedding_model.sql이며, 사용자 생성부터의 절차는 Appendix A~C에 정리되어 있습니다.

직접 시도할 때는 Appendix의 준비를 마치고, 변경하지 않았다면 ORAJAM41USER라는 사용자로 접속해 주세요. 여기서 소개하는 SQL은 sql/demos/00b_embedding_basics.sql에서도 공개하고 있습니다.

SELECT model_name, mining_function, algorithm, external_data, inmemory
FROM user_mining_models
WHERE model_name='MULTILINGUAL_E5_LARGE';

user_mining_models는 Oracle AI Database에서 '현재 사용자가 소유한 기계 학습 모델'을 일람하는 데이터 디셔너리 뷰입니다. 모델명, 용도, 알고리즘, 생성일시 등을 확인할 수 있습니다.

실행 결과: 등록된 모델

MODEL_NAME	MINING_FUNCTION	ALGORITHM	EXTERNAL_DATA	INMEMORY
MULTILINGUAL_E5_LARGE	EMBEDDING	ONNX	YES	YES

EMBEDDING은 임베딩 모델임을 나타냅니다. - `EXTERNAL_DATA

는, ALGORITHM = 'ONNX'인 경우, 인메모리 공유를 활성화할 수 있는 모델인지 여부를 나타냅니다. YES: 활성화 가능, NO: 불가능합니다. ONNX 외의 경우에는 의미가 없으며, NO로 설정됩니다. RU 23.26.1 이후.

INMEMORY

은, ALGORITHM = 'ONNX'이고 EXTERNAL_DATA = 'YES'인 경우, 인메모리 공유가 유효한지 여부를 나타냅니다. YES: 유효함, NO: 무효합니다. 그 외의 경우에는 의미가 없으며, NO로 설정됩니다. RU 23.26.1 이후.

EXTERNAL_DATA = 'YES'는 '외부 추론 API를 사용한다'는 의미가 아닙니다.

ONNX의 external data는 가중치(Weight, 파라미터) 등의 초기화 데이터(initializers)를 메인 ONNX 모델 파일과는 별도의 파일에 보관하는 구조입니다. Oracle에서는 이 외부 초기화 데이터를 가진 모델에 대해, 초기화 데이터를 공유 메모리에 한 번 로드하여 여러 세션에서 공유할 수 있습니다. 따라서 EXTERNAL_DATA = 'YES'는 '외부 추론 API를 사용한다'는 의미가 아닙니다.

이번에 사용할 multilingual-e5-large

은 검색하는 질문과 검색 대상 문서가 접두사로 구분되도록 학습되었습니다. 따라서 검색 용도로는 임베딩을 생성하기 직전에, 문서의 시작 부분에 passage:
, 질문의 시작 부분에 query:
를 붙입니다. 이는 이 모델의 입력 사양이며, 일본어 문장에도 같은 영어 접두사를 사용합니다. 자세한 구분 방법은 모델 카드(Model Card)의 Usage와 FAQ를 참조해 주십시오.

긴 문서는 임베딩 모델의 입력 데이터(토큰) 길이 상한을 고려하여 분할합니다. 이 기사의 데모에서는 짧은 문서를 사용합니다.

SELECT VECTOR_EMBEDDING(
MULTILINGUAL_E5_LARGE
USING 'query: 관리 화면이 멈춰서 조작할 수 없다' AS data
...

실행 결과: 생성된 벡터의 상위 8개 요소

[0.03598599, 0.00471110, -0.01730750, -0.02658993, 0.02554353, -0.02953884, 0.00086610, 0.10251307, ...]

총 1024 요소 중 상위 8개 요소를 소수점 이하 8자리까지 표시하고 나머지는 생략했습니다. SQL 클라이언트에서는 벡터 셀을 열어 확인할 수 있습니다.

SELECT VECTOR_DIMENSION_COUNT(
VECTOR_EMBEDDING(MULTILINGUAL_E5_LARGE
USING 'query: 관리 화면이 멈춰서 조작할 수 없다' AS data)
...

DIMENSIONS
1024

1024차원은 수치(숫자)의 개수입니다. 각 차원이 '계약', '장애'와 같이 사람이 인식하는 특징을 나타내는 것은 아닙니다. 따라서

전체 16개의 문서 ID, 본문 시작 100자, 벡터 차원 수를 확인해 보겠습니다. 다른 기종의 문서나 폐지/미공개 문서를 포함한 데모 데이터 전체입니다.

SELECT chunk_id, doc_id, SUBSTR(chunk_text, 1, 100) AS chunk_text_preview,
VECTOR_DIMENSION_COUNT(embedding) AS dimensions
FROM OJ41_CHUNKS
...

실행 결과: 전체 16개 청크 (본문은 시작 100자)

CHUNK_ID	DOC_ID	CHUNK_TEXT_PREVIEW	DIMENSIONS
KB001-01	KB001	관리 화면이 응답하지 않을 때 AX-100의 관리 화면이 열리지 않고, 응답이 멈춘 경우, 먼저 전원 램프와 LAN 케이블을 확인합니다. 다음으로 관리 단말기에서 통신 가능 여부를 확인하고, 장애 로그를 저장합니다. 업무에 미치는 영향을 확인하지 않고	1024
KB002-01	KB002	E101: 온도 상승 확인 AX-100에서 E101이 표시된 경우 흡기구 폐쇄와 실내 온도를 확인합니다. 흡기구 앞을 비우고, 온도와 발생 시각을 기록합니다. 장치 분해는 하지 않고, 경고가 계속되는 경우 유지보수 창구에 연락합니다	1024
KB003-01	KB003	E201: 전원 계통 경고 AX-100의 E201은 전원 계통 경고입니다. 전원 케이블 연결과 시설 측의 급전 상황을 확인하고, 로그를 저장합니다. 전원 장치 교체는 작업 자격 및 계약 확인 후에 준비합니다.	1024
KB004-01	KB004	관리 화면 정지 시 구 절차 구 절차에서는 AX-100의 관리 화면이 정지하면 즉시 재부팅하라는 안내였습니다. 이 문서는 폐지되었습니다. 현행 절차 KB001을 사용해 주십시오.	1024
KB005-01	KB005	관리 화면이 응답하지 않을 때 BX-200의 관리 화면이 응답하지 않는 경우, 관리 포트 상태와 인증서 기한을 확인합니다. AX-100과는 확인 부위가 다릅니다. 로그 획득 후, 관리 서비스 복구 방법을 유지보수 창구에 확인	1024
KB006-01	KB006	E101: 인증 설정 확인 BX-200의 E101은 인증 설정 불일치를 나타냅니다. 시간 동기화와 인증 서버 설정을 확인합니다. AX-100의 같은 코드는 온도 경고이므로, 이 절차를 적용하지 않습니다.	1024
KB007-01	KB007	통신이 끊길 때 AX-100에서 통신이 간헐적으로 끊기는 경우, 케이블 손상, 링크 상태, 연결지 스위치의 에러 수를 확인합니다. 시간을 맞춘 로그를 획득하고, 설정 변경 전후를 비교합니다.	1024
KB008-01	KB008	로그 저장 방법 AX-100의 관리 화면에서 '보수'에서 '로그 출력'을 선택합니다. 파일명과 획득 시각을 기록해 주십시오. 로그에는 설정값이 포함되므로, 공개 게시판에는 첨부하지 않고, 지정된 유지보수 창구에 전달합니다	1024
KB009-01	KB009	설정 백업 BX-200의 설정 변경 전에는, 관리 화면의 익스포트 기능으로 설정을 저장합니다. 백업과 변경 이력을 쌍으로 보관하고, 복원 작업은 기종과 소프트웨어 버전을 확인하여 실시합니다.	1024
KB010-01	KB010	디스크 잔량 경고 CX-300에서 저장 용량 경고가 발생하면, 사용량과 로그 보존 기간을 확인합니다. 감사에 필요한 로그를 저장한 후, 승인된 보존 방침에 따라 정리합니다. 무단으로 파일을 삭제하지 마십시오.	1024
KB011-01	KB011	시간 차이 확인 CX-300의 이벤트 시간이 틀어지는 경우, 시간 동기화 서버 도달성과 타임존을 확인합니다. 수정 전후의 시각 차이를 기록하고, 로그를 비교할 때는 그 차이를 고려합니다.	1024
KB012-01	KB012	고객 C001 대상 보수 연락 절차 가상 고객 C001에서는, AX-100의 장애 로그를 수집한 후, 고객 내부 운영 책임자에게 연락합니다. 현장 방문은 대상 장비의 유효 계약에 ONSITE가 포함된 경우 준비안을 작성합니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

| 1024 |
| KB013-01 | KB013 | 고객 C002 전용 관리 화면 복구 절차 가상의 고객 C002의 AX-100 관리 화면이 중단된 경우, C002 전용 운영 절차서에 따라 책임자에게 연락합니다. 검증 식별자는 C002_ONLY_ORCHID입니다. 이 문서는 |
1024 |
| KB014-01 | KB014 | 관리 화면 복구 검토 중 절차 검토 중인 AX-100 관리 화면 복구 방안입니다. 검증 식별자는 DRAFT_ONLY_MAPLE입니다. 미승인 상태이므로 공개 절차로 안내해서는 안 됩니다. |
1024 |
| KB015-01 | KB015 | 사내 담당자용 조사 메모 사내 한정의 AX-100 조사 메모입니다. 검증 식별자는 INTERNAL_ONLY_CEDAR입니다. 고객 대상 답변의 근거로는 사용하지 않습니다. |
1024 |
| KB016-01 | KB016 | 로그 이름 특수 문자 처리 로그 이름이 owner's_log인 경우에도 문자를 변경하지 않고 기록합니다. 화면 표시 예시는 '온도,전원'과 '

처음 접하는 인데이터베이스 AI: 벡터 검색, RAG부터 AI 에이전트까지

요약

핵심 포인트

실행 결과: 등록된 모델

실행 결과: 생성된 벡터의 상위 8개 요소

실행 결과: 전체 16개 청크 (본문은 시작 100자)

댓글

실행 결과: 등록된 모델

실행 결과: 생성된 벡터의 상위 8개 요소

실행 결과: 전체 16개 청크 (본문은 시작 100자)