LLM 없이 Azure AI Search를 구동하는 방법: 최소한의 노력으로 해결하기

결론부터 말씀드리자면

AI 에이전트가 사내 문서를 검색하도록 만들고 싶지만, 아직 LLM 배포는 준비되지 않은 상황입니다. 이런 상태에서 Azure AI Search의 '지식 기반(Knowledge Base)' (agentic retrieval)을 시도하면, 첫 번째 요청이 400 오류로 반환됩니다.

A Knowledge Base model must be specified to use any reasoning effort other than 'Minimal'

원인은 모델이 없는 지식 기반의 기본 설정이 'minimal' 외의 것으로 처리되었기 때문이었습니다. retrievalReasoningEffort를 minimal로 지정하면, LLM이나 임베딩 모델 없이도 여러 인덱스를 가로지르는 검색을 수행할 수 있습니다. 이번에 확인한 내용을 먼저 정리하겠습니다.

작업 (모델 없는 지식 기반)	결과
effort 미지정으로 retrieve	400
`minimal`를 지정하여 retrieve	200 (semantic ranker 점수 포함)
`auto` / `low`를 지정	400 (동일한 문구)
지식 기반의 기본값을 `auto`로 설정하고 저장	400 (저장하는 시점에서 거부됨)
`messages` 형식으로 질문	400 (`minimal`는 `intents` 형식만 지원)
`Accept: text/event-stream`으로 스트림 전송	200 (이벤트가 순차적으로 흐름)

어떤 기능이 가능한지

지식 기반은 여러 검색 출처(knowledge source)를 하나로 모아 한 번의 API 호출로 가져올 수 있는 진입점입니다. LLM을 연결하면, 질문을 분해하여 검색 계획을 세우고 답변까지 합성할 수 있습니다. 이 'LLM으로 생각하는 힘'이 retrievalReasoningEffort이고,

minimal는 그 바로 전 단계, 즉 LLM을 사용하지 않고 쿼리를 그대로 각 검색 출처에 던지는 단계에 해당합니다.

Learn에는 minimal의 예시가 있으며,

POST {endpoint}/knowledgebases/kb-nomodel/retrieve?api-version=2026-08-01-preview
{ "intents": [ { "type": "semantic", "search": "SSO provisioning fails" } ] }

돌아온 것은 상단의 400이었다. effort를 아무것도 쓰지 않았는데도 'minimal 외'라고 한다. 나레지베이스에 기본값을 저장하지 않은 경우, 서비스는 minimal 이외의 쪽으로 기울어지는 것 같다 (내 추측이며, 동작으로 그렇게 읽을 수 있을 뿐이다).

고치는 방법은 두 가지가 있었다. 요청마다 지정하는 방법과, 나레지베이스 쪽에 저장하는 방법이다.

{ "intents": [ ... ],
"retrievalReasoningEffort": { "kind": "minimal" } }

PUT {endpoint}/knowledgebases/kb-minimal?api-version=2026-08-01-preview
{ "name": "kb-minimal",
"knowledgeSources": [ { "name": "docs-ks" }, { "name": "trouble-ks" } ],
...

어느 쪽이든 200이 되었다. 저장해 두면, 이후 요청에서 effort를 쓸 필요가 없다.

minimal로 무엇이 돌아오는지

SSO provisioning fails

으로 검색하니, 두 개의 인덱스에서 각각 1건씩, 총 2건이 돌아왔다. 본문에는 LLM의 답변 문은 없고, 히트한 문서의 title과 content의 JSON 배열이 그대로 들어있다.

activity에는 검색원별 기록이 붙는다. searchIndexArguments에 실제로 던진 검색어와 semantic 구성명(sem)이 남아 있어, '어떤 검색원에 어떤 쿼리가 갔는지'를 나중에 추적할 수 있다. references의 각 요소에는 rerankerScore (이번에는 3.69와 1.21), docKey, citationUrl이 들어간다. LLM이 없어도 semantic ranker의 점수는 붙는다.

궁금한 점이 하나 있다. activity의 마지막에 agenticReasoning이 붙고, reasoningTokens: 73이라고 나왔다. 모델을 가지고 있지 않은데 토큰 수가 나오는 이유는 확인하지 못했다. Free로 청구는 보고 있지 않아서, 과금과의 관계도 불분명한 채, 본 대로 적어둔다.

citationUrl (Learn에서는 preview)
를 api-key와 함께 GET하면, 문서의 본문이 돌아왔다. 답변의 근거 문서를 다시 가져오는 용도로 쓸 수 있을 것 같다.

사용할 수 있는 지정과, 사용할 수 없는 지정

neverQuerySource. 요청 단위로 검색원을 1개 제외하는 지정이다. trouble-ks에 `

다른 요청으로 질문했을 때, 그것은 위의 400과 같았다. 추측컨대, 모델이 없는 지식 기반에 Learn의 예시를 붙여도 같은 벽에 부딪힐 것이다. intents

neverQuerySource를 intents로 바꾸면 통한다. 위에서 언급된 neverQuerySource는 intents로 확인한 것이다.

stream도 사용 가능 (preview)

Accept: text/event-stream을 추가하자, 동일한 retrieve가 SSE(Server-Sent Events)로 반환되었다. content-type은 text/event-stream; charset=utf-8이다. 관측된 이벤트 순서는 다음과 같다.

retrieval.started ← outputMode는 extractiveData
activity.started / activity.completed (검색원별, 마지막에 agenticReasoning)
references.completed
...

answer.completed은 나오지 않았다. 답변 합성(answerSynthesis)을 하지 않기 때문에 당연하다. 동일한 stream 요청을 api-version=2026-04-01로 보내자 406이 나왔다. 즉, stream은 2026-08-01-preview의 기능이라는 것이다.

효과적인 상황과 그렇지 않은 상황

효과적인 것은 LLM 배포를 기다리는 동안 지식 기반의 연결을 먼저 확정하고 싶을 때이다. knowledge source 정의, semantic 구성, citationUrl에서의 근거 추출까지는 모델 없이 확인할 수 있다. 무료 서비스만으로 시도할 수 있어 비용이 발생하지 않는다(이번 검증 비용은 0원).

효과적이지 않은 것은 질문 분해나 답변 합성을 기대할 때이다. minimal은 전달된 쿼리를 그대로 검색원에 던질 뿐이며, auto나 low에는 모델이 필요하다. 모델을 나중에 추가하면 effort를 auto로 변경하는 절차가 늘어난다.

다음에 깊이 파고들 수 있는 진입점

동일한 질문을 minimal과 auto (모델 있음)로 비교해 보면, auto가 어떤 조건에서 계획에 올라가는지 알 수 있다. 이번에는 모델을 세우지 않았기 때문에 미확인이며, 궁금한 것은 비용 증가 추이이다.
Learn에는 검색원별 기본 개수를 결정하는 retrieveDefaults도 있다. 이번에는 다루지 않았다.

참고 자료

Query a knowledge base using the retrieve action or MCP endpoint (minimal / stream / neverQuerySource)
What's new in Azure AI Search (2026-08-01-preview 추가 기능)
Create a knowledge base in Azure AI Search
Knowledge Retrieval - Retrieve (REST, 2026-08-01-preview)